From: Dominique Martinet <[email protected]>
To: Christian Brauner <[email protected]>
Cc: Alexander Viro <[email protected]>,
Jens Axboe <[email protected]>,
Pavel Begunkov <[email protected]>,
Stefan Roesch <[email protected]>, Clay Harris <[email protected]>,
Dave Chinner <[email protected]>,
[email protected], [email protected],
[email protected]
Subject: Re: [PATCH v2 6/6] RFC: io_uring getdents: test returning an EOF flag in CQE
Date: Wed, 24 May 2023 06:05:06 +0900 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <20230523-abgleichen-rotieren-37fdb6fb9ef3@brauner>
Christian Brauner wrote on Tue, May 23, 2023 at 04:30:14PM +0200:
> > index b15ec81c1ed2..f6222b0148ef 100644
> > --- a/io_uring/fs.c
> > +++ b/io_uring/fs.c
> > @@ -322,6 +322,7 @@ int io_getdents(struct io_kiocb *req, unsigned int issue_flags)
> > {
> > struct io_getdents *gd = io_kiocb_to_cmd(req, struct io_getdents);
> > unsigned long getdents_flags = 0;
> > + u32 cqe_flags = 0;
> > int ret;
> >
> > if (issue_flags & IO_URING_F_NONBLOCK) {
> > @@ -338,13 +339,16 @@ int io_getdents(struct io_kiocb *req, unsigned int issue_flags)
> > goto out;
> > }
> >
> > - ret = vfs_getdents(req->file, gd->dirent, gd->count, getdents_flags);
> > + ret = vfs_getdents(req->file, gd->dirent, gd->count, &getdents_flags);
>
> I don't understand how synchronization and updating of f_pos works here.
> For example, what happens if a concurrent seek happens on the fd while
> io_uring is using vfs_getdents which calls into iterate_dir() and
> updates f_pos?
I don't see how different that is from a user spawning two threads and
calling getdents64 + lseek or two getdents64 in parallel?
(or any two other users of iterate_dir)
As far as I understand you'll either get the old or new pos as
obtained/updated by iterate_dir()?
That iterate_dir probably ought to be using READ_ONCE/WRITE_ONCE or some
atomic read/update wrappers as the shared case only has a read lock
around these, but that's not a new problem; and for all I care
about I'm happy to let users shoot themselves in the foot.
(although I guess that with filesystems not validating the offset as
was pointed out in a previous version comment having non-atomic update
might be a security issue at some point on architectures that don't
guarantee atomic 64bit updates, but if someone manages to abuse it
it's already possible to abuse it with the good old syscalls, so I'd
rather leave that up to someone who understand how atomicity in the
kernel works better than me...)
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2023-05-23 21:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 10:52 [PATCH v2 0/6] io_uring: add getdents support, take 2 Dominique Martinet
2023-05-10 10:52 ` [PATCH v2 1/6] fs: split off vfs_getdents function of getdents64 syscall Dominique Martinet
2023-05-23 15:39 ` Christian Brauner
2023-05-23 21:13 ` Dominique Martinet
2023-05-10 10:52 ` [PATCH v2 2/6] vfs_getdents/struct dir_context: add flags field Dominique Martinet
2023-05-10 10:52 ` [PATCH v2 3/6] io_uring: add support for getdents Dominique Martinet
2023-05-10 10:52 ` [PATCH v2 4/6] kernfs: implement readdir FMODE_NOWAIT Dominique Martinet
2023-05-11 10:55 ` Dan Carpenter
2023-05-11 11:03 ` Dominique Martinet
2023-05-10 10:52 ` [PATCH v2 5/6] libfs: set FMODE_NOWAIT on dir open Dominique Martinet
2023-05-10 10:52 ` [PATCH v2 6/6] RFC: io_uring getdents: test returning an EOF flag in CQE Dominique Martinet
2023-05-23 14:30 ` Christian Brauner
2023-05-23 21:05 ` Dominique Martinet [this message]
2023-05-24 13:52 ` [PATCH v2 1/6] fs: split off vfs_getdents function of getdents64 syscall Christian Brauner
2023-05-24 21:36 ` Dominique Martinet
2023-05-25 9:22 ` Christian Brauner
2023-05-25 11:00 ` Dominique Martinet
2023-05-25 12:33 ` Christian Brauner
2023-07-11 8:17 ` Hao Xu
2023-07-11 8:24 ` Dominique Martinet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox