| Message ID | 20210603051836.2614535-10-dkadashev@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | io_uring: add mkdir, [sym]linkat and mknodat support | expand |
On 6/3/21 6:18 AM, Dmitry Kadashev wrote: > IORING_OP_LINKAT behaves like linkat(2) and takes the same flags and > arguments. > > In some internal places 'hardlink' is used instead of 'link' to avoid > confusion with the SQE links. Name 'link' conflicts with the existing > 'link' member of io_kiocb. > > Suggested-by: Christian Brauner <christian.brauner@ubuntu.com> > Link: https://lore.kernel.org/io-uring/20210514145259.wtl4xcsp52woi6ab@wittgenstein/ > Signed-off-by: Dmitry Kadashev <dkadashev@gmail.com> > --- > fs/internal.h | 2 ++ > fs/io_uring.c | 67 +++++++++++++++++++++++++++++++++++ > fs/namei.c | 2 +- > include/uapi/linux/io_uring.h | 2 ++ > 4 files changed, 72 insertions(+), 1 deletion(-) > > diff --git a/fs/internal.h b/fs/internal.h > index 3b3954214385..15a7d210cc67 100644 > --- a/fs/internal.h > +++ b/fs/internal.h [...] > + > +static int io_linkat(struct io_kiocb *req, int issue_flags) > +{ > + struct io_hardlink *lnk = &req->hardlink; > + int ret; > + > + if (issue_flags & IO_URING_F_NONBLOCK) > + return -EAGAIN; > + > + ret = do_linkat(lnk->old_dfd, lnk->oldpath, lnk->new_dfd, > + lnk->newpath, lnk->flags); I'm curious, what's difference b/w SYMLINK and just LINK that one doesn't use old_dfd and another does? Can it be supported/wished by someone in the future? In that case I'd rather reserve and verify a field for old_dfd for both, even if one won't really support it for now. > + > + req->flags &= ~REQ_F_NEED_CLEANUP; > + if (ret < 0) > + req_set_fail(req); > + io_req_complete(req, ret); > + return 0; > +} > +
On Tue, Jun 22, 2021 at 6:48 PM Pavel Begunkov <asml.silence@gmail.com> wrote: > > On 6/3/21 6:18 AM, Dmitry Kadashev wrote: > > IORING_OP_LINKAT behaves like linkat(2) and takes the same flags and > > arguments. > > > > In some internal places 'hardlink' is used instead of 'link' to avoid > > confusion with the SQE links. Name 'link' conflicts with the existing > > 'link' member of io_kiocb. > > > > Suggested-by: Christian Brauner <christian.brauner@ubuntu.com> > > Link: https://lore.kernel.org/io-uring/20210514145259.wtl4xcsp52woi6ab@wittgenstein/ > > Signed-off-by: Dmitry Kadashev <dkadashev@gmail.com> > > --- > > fs/internal.h | 2 ++ > > fs/io_uring.c | 67 +++++++++++++++++++++++++++++++++++ > > fs/namei.c | 2 +- > > include/uapi/linux/io_uring.h | 2 ++ > > 4 files changed, 72 insertions(+), 1 deletion(-) > > > > diff --git a/fs/internal.h b/fs/internal.h > > index 3b3954214385..15a7d210cc67 100644 > > --- a/fs/internal.h > > +++ b/fs/internal.h > > [...] > > + > > +static int io_linkat(struct io_kiocb *req, int issue_flags) > > +{ > > + struct io_hardlink *lnk = &req->hardlink; > > + int ret; > > + > > + if (issue_flags & IO_URING_F_NONBLOCK) > > + return -EAGAIN; > > + > > + ret = do_linkat(lnk->old_dfd, lnk->oldpath, lnk->new_dfd, > > + lnk->newpath, lnk->flags); > > I'm curious, what's difference b/w SYMLINK and just LINK that > one doesn't use old_dfd and another does? Symlink's content does not have to exist, it's pretty much an arbitrary string. E.g. try `ln -s http://example.com/ foo` :) > Can it be supported/wished by someone in the future? I don't really know. I guess it could be imagined that someone wants to try and resolve the full target name against some dfd. But to me the whole idea looks inherently problematic. Accepting the old dfd feels like the path is going to be resolved, and historically it is not the case, and we'd need a special dfd value to mean "do not resolve", and AT_FDCWD won't work for this (since it means "resolve against the CWD", not "do not resolve"). > In that case I'd rather reserve and verify a field for old_dfd for both, even > if one won't really support it for now. If I understand you correctly, at this point you mean just checking that old_dfd is not set (i.e. == -1)? I'll add a check.
On 6/23/21 7:09 AM, Dmitry Kadashev wrote: > On Tue, Jun 22, 2021 at 6:48 PM Pavel Begunkov <asml.silence@gmail.com> wrote: >> >> On 6/3/21 6:18 AM, Dmitry Kadashev wrote: >>> IORING_OP_LINKAT behaves like linkat(2) and takes the same flags and >>> arguments. >>> >>> In some internal places 'hardlink' is used instead of 'link' to avoid >>> confusion with the SQE links. Name 'link' conflicts with the existing >>> 'link' member of io_kiocb. >>> >>> Suggested-by: Christian Brauner <christian.brauner@ubuntu.com> >>> Link: https://lore.kernel.org/io-uring/20210514145259.wtl4xcsp52woi6ab@wittgenstein/ >>> Signed-off-by: Dmitry Kadashev <dkadashev@gmail.com> >>> --- >>> fs/internal.h | 2 ++ >>> fs/io_uring.c | 67 +++++++++++++++++++++++++++++++++++ >>> fs/namei.c | 2 +- >>> include/uapi/linux/io_uring.h | 2 ++ >>> 4 files changed, 72 insertions(+), 1 deletion(-) >>> >>> diff --git a/fs/internal.h b/fs/internal.h >>> index 3b3954214385..15a7d210cc67 100644 >>> --- a/fs/internal.h >>> +++ b/fs/internal.h >> >> [...] >>> + >>> +static int io_linkat(struct io_kiocb *req, int issue_flags) >>> +{ >>> + struct io_hardlink *lnk = &req->hardlink; >>> + int ret; >>> + >>> + if (issue_flags & IO_URING_F_NONBLOCK) >>> + return -EAGAIN; >>> + >>> + ret = do_linkat(lnk->old_dfd, lnk->oldpath, lnk->new_dfd, >>> + lnk->newpath, lnk->flags); >> >> I'm curious, what's difference b/w SYMLINK and just LINK that >> one doesn't use old_dfd and another does? > > Symlink's content does not have to exist, it's pretty much an arbitrary string. > E.g. try `ln -s http://example.com/ foo` :) > >> Can it be supported/wished by someone in the future? > > I don't really know. I guess it could be imagined that someone wants to try and > resolve the full target name against some dfd. But to me the whole idea looks > inherently problematic. Accepting the old dfd feels like the path is going to > be resolved, and historically it is not the case, and we'd need a special dfd > value to mean "do not resolve", and AT_FDCWD won't work for this (since it > means "resolve against the CWD", not "do not resolve"). I see, I don't know it good enough to reason, but have to throw the question into the air, ... >> In that case I'd rather reserve and verify a field for old_dfd for both, even >> if one won't really support it for now. > > If I understand you correctly, at this point you mean just checking that > old_dfd is not set (i.e. == -1)? I'll add a check. ... and we have all 5.14 to fix it and other parts if needed, so let's leave it as is
diff --git a/fs/internal.h b/fs/internal.h index 3b3954214385..15a7d210cc67 100644 --- a/fs/internal.h +++ b/fs/internal.h @@ -79,6 +79,8 @@ int do_renameat2(int olddfd, struct filename *oldname, int newdfd, struct filename *newname, unsigned int flags); int do_mkdirat(int dfd, struct filename *name, umode_t mode); int do_symlinkat(struct filename *from, int newdfd, struct filename *to); +int do_linkat(int olddfd, struct filename *old, int newdfd, + struct filename *new, int flags); /* * namespace.c diff --git a/fs/io_uring.c b/fs/io_uring.c index 5fdba9b381e5..31e1aa7dd90b 100644 --- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -679,6 +679,15 @@ struct io_symlink { struct filename *newpath; }; +struct io_hardlink { + struct file *file; + int old_dfd; + int new_dfd; + struct filename *oldpath; + struct filename *newpath; + int flags; +}; + struct io_completion { struct file *file; struct list_head list; @@ -825,6 +834,7 @@ struct io_kiocb { struct io_unlink unlink; struct io_mkdir mkdir; struct io_symlink symlink; + struct io_hardlink hardlink; /* use only after cleaning per-op data, see io_clean_op() */ struct io_completion compl; }; @@ -1039,6 +1049,7 @@ static const struct io_op_def io_op_defs[] = { [IORING_OP_UNLINKAT] = {}, [IORING_OP_MKDIRAT] = {}, [IORING_OP_SYMLINKAT] = {}, + [IORING_OP_LINKAT] = {}, }; static bool io_disarm_next(struct io_kiocb *req); @@ -3630,6 +3641,53 @@ static int io_symlinkat(struct io_kiocb *req, int issue_flags) return 0; } +static int io_linkat_prep(struct io_kiocb *req, + const struct io_uring_sqe *sqe) +{ + struct io_hardlink *lnk = &req->hardlink; + const char __user *oldf, *newf; + + if (unlikely(req->flags & REQ_F_FIXED_FILE)) + return -EBADF; + + lnk->old_dfd = READ_ONCE(sqe->fd); + lnk->new_dfd = READ_ONCE(sqe->len); + oldf = u64_to_user_ptr(READ_ONCE(sqe->addr)); + newf = u64_to_user_ptr(READ_ONCE(sqe->addr2)); + lnk->flags = READ_ONCE(sqe->hardlink_flags); + + lnk->oldpath = getname(oldf); + if (IS_ERR(lnk->oldpath)) + return PTR_ERR(lnk->oldpath); + + lnk->newpath = getname(newf); + if (IS_ERR(lnk->newpath)) { + putname(lnk->oldpath); + return PTR_ERR(lnk->newpath); + } + + req->flags |= REQ_F_NEED_CLEANUP; + return 0; +} + +static int io_linkat(struct io_kiocb *req, int issue_flags) +{ + struct io_hardlink *lnk = &req->hardlink; + int ret; + + if (issue_flags & IO_URING_F_NONBLOCK) + return -EAGAIN; + + ret = do_linkat(lnk->old_dfd, lnk->oldpath, lnk->new_dfd, + lnk->newpath, lnk->flags); + + req->flags &= ~REQ_F_NEED_CLEANUP; + if (ret < 0) + req_set_fail(req); + io_req_complete(req, ret); + return 0; +} + static int io_shutdown_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe) { @@ -6040,6 +6098,8 @@ static int io_req_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe) return io_mkdirat_prep(req, sqe); case IORING_OP_SYMLINKAT: return io_symlinkat_prep(req, sqe); + case IORING_OP_LINKAT: + return io_linkat_prep(req, sqe); } printk_once(KERN_WARNING "io_uring: unhandled opcode %d\n", @@ -6188,6 +6248,10 @@ static void io_clean_op(struct io_kiocb *req) putname(req->symlink.oldpath); putname(req->symlink.newpath); break; + case IORING_OP_LINKAT: + putname(req->hardlink.oldpath); + putname(req->hardlink.newpath); + break; } req->flags &= ~REQ_F_NEED_CLEANUP; } @@ -6320,6 +6384,9 @@ static int io_issue_sqe(struct io_kiocb *req, unsigned int issue_flags) case IORING_OP_SYMLINKAT: ret = io_symlinkat(req, issue_flags); break; + case IORING_OP_LINKAT: + ret = io_linkat(req, issue_flags); + break; default: ret = -EINVAL; break; diff --git a/fs/namei.c b/fs/namei.c index f5b0379d2f8c..b85e457c43b7 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -4356,7 +4356,7 @@ EXPORT_SYMBOL(vfs_link); * with linux 2.0, and to avoid hard-linking to directories * and other special files. --ADM */ -static int do_linkat(int olddfd, struct filename *old, int newdfd, +int do_linkat(int olddfd, struct filename *old, int newdfd, struct filename *new, int flags) { struct user_namespace *mnt_userns; diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h index 7b8a78d9c947..510e64a0a9c3 100644 --- a/include/uapi/linux/io_uring.h +++ b/include/uapi/linux/io_uring.h @@ -44,6 +44,7 @@ struct io_uring_sqe { __u32 splice_flags; __u32 rename_flags; __u32 unlink_flags; + __u32 hardlink_flags; }; __u64 user_data; /* data to be passed back at completion time */ union { @@ -139,6 +140,7 @@ enum { IORING_OP_UNLINKAT, IORING_OP_MKDIRAT, IORING_OP_SYMLINKAT, + IORING_OP_LINKAT, /* this goes last, obviously */ IORING_OP_LAST,
IORING_OP_LINKAT behaves like linkat(2) and takes the same flags and arguments. In some internal places 'hardlink' is used instead of 'link' to avoid confusion with the SQE links. Name 'link' conflicts with the existing 'link' member of io_kiocb. Suggested-by: Christian Brauner <christian.brauner@ubuntu.com> Link: https://lore.kernel.org/io-uring/20210514145259.wtl4xcsp52woi6ab@wittgenstein/ Signed-off-by: Dmitry Kadashev <dkadashev@gmail.com> --- fs/internal.h | 2 ++ fs/io_uring.c | 67 +++++++++++++++++++++++++++++++++++ fs/namei.c | 2 +- include/uapi/linux/io_uring.h | 2 ++ 4 files changed, 72 insertions(+), 1 deletion(-)