From: Dominique Martinet <asmadeus@codewreck.org>
To: Hao Xu <hao.xu@linux.dev>
Cc: io-uring@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
Pavel Begunkov <asml.silence@gmail.com>,
Christian Brauner <brauner@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Stefan Roesch <shr@fb.com>, Clay Harris <bugs@claycon.org>,
Dave Chinner <david@fromorbit.com>,
linux-fsdevel@vger.kernel.org, Wanpeng Li <wanpengli@tencent.com>
Subject: Re: [PATCH 3/3] io_uring: add support for getdents
Date: Thu, 13 Jul 2023 01:10:41 +0900 [thread overview]
Message-ID: <ZK7QgRyUIHNC8Nk6@codewreck.org> (raw)
In-Reply-To: <858c3f16-ffb3-217e-b5d6-fcc63ef9c401@linux.dev>
Hao Xu wrote on Wed, Jul 12, 2023 at 03:53:24PM +0800:
> > > + if (file_count(file) > 1)
> >
> > I was curious about this so I found it's basically what __fdget_pos does
> > before deciding it should take the f_pos_lock, and as such this is
> > probably correct... But if someone can chime in here: what guarantees
> > someone else won't __fdget_pos (or equivalent through this) the file
> > again between this and the vfs_getdents call?
> > That second get would make file_count > 1 and it would lock, but lock
> > hadn't been taken here so the other call could get the lock without
> > waiting and both would process getdents or seek or whatever in
> > parallel.
> >
>
> This file_count(file) is atomic_read, so I believe no race condition here.
I don't see how that helps in the presence of another thread getting the
lock after we possibly issued a getdents without the lock, e.g.
t1 call io_uring getdents here
t1 sees file_count(file) == 1 and skips getting lock
t1 starts issuing vfs_getdents [... processing]
t2 calls either io_uring getdents or getdents64 syscall
t2 gets the lock, since it wasn't taken by t1 it can be obtained
t2 issues another vfs_getdents
Christian raised the same issue so I'll leave this to his part of the
thread for reply, but I hope that clarified my concern.
-----
BTW I forgot to point out: this dropped the REWIND bit from my patch; I
believe some form of "seek" is necessary for real applications to make
use of this (for example, a web server could keep the fd open in a LRU
and keep issuing readdir over and over again everytime it gets an
indexing request); not having rewind means it'd need to close and
re-open the fd everytime which doesn't seem optimal.
A previous iteration discussed that real seek is difficult and not
necessarily needed to I settled for rewind, but was there a reason you
decided to stop handling that?
My very egoistical personal use case won't require it, so I can just say
I don't care here, but it would be nice to have a reason explained at
some point
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2023-07-12 16:11 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 11:40 [PATCH v3 0/3] io_uring getdents Hao Xu
2023-07-11 11:40 ` [PATCH 1/3] fs: split off vfs_getdents function of getdents64 syscall Hao Xu
2023-07-11 13:02 ` Ammar Faizi
2023-07-12 8:03 ` Hao Xu
2023-07-12 13:55 ` Ammar Faizi
2023-07-13 4:17 ` Hao Xu
2023-07-11 23:41 ` Dave Chinner
2023-07-11 23:50 ` Jens Axboe
2023-07-12 11:14 ` Christian Brauner
2023-07-11 11:40 ` [PATCH 2/3] vfs_getdents/struct dir_context: add flags field Hao Xu
2023-07-12 11:31 ` Christian Brauner
2023-07-12 16:02 ` Dominique Martinet
2023-07-13 4:12 ` Hao Xu
2023-07-11 11:40 ` [PATCH 3/3] io_uring: add support for getdents Hao Xu
2023-07-11 12:15 ` Dominique Martinet
2023-07-12 7:53 ` Hao Xu
2023-07-12 16:10 ` Dominique Martinet [this message]
2023-07-13 4:05 ` Hao Xu
2023-07-13 4:40 ` Hao Xu
2023-07-13 4:50 ` Dominique Martinet
2023-07-12 8:01 ` Hao Xu
2023-07-12 15:27 ` Christian Brauner
2023-07-13 4:35 ` Hao Xu
2023-07-13 7:10 ` Christian Brauner
2023-07-13 9:06 ` Hao Xu
2023-07-13 15:14 ` Christian Brauner
2023-07-16 11:57 ` Hao Xu
2023-07-18 6:55 ` Hao Xu
2023-07-11 23:47 ` [PATCH v3 0/3] io_uring getdents Dave Chinner
2023-07-11 23:51 ` Jens Axboe
2023-07-12 0:53 ` Dominique Martinet
2023-07-12 0:56 ` Jens Axboe
2023-07-12 3:16 ` Hao Xu
2023-07-12 3:12 ` Hao Xu
2023-07-12 3:19 ` Hao Xu
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 \
--in-reply-to=ZK7QgRyUIHNC8Nk6@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=bugs@claycon.org \
--cc=david@fromorbit.com \
--cc=hao.xu@linux.dev \
--cc=io-uring@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=shr@fb.com \
--cc=viro@zeniv.linux.org.uk \
--cc=wanpengli@tencent.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.