From: Christian Brauner <brauner@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
Aleksa Sarai <cyphar@cyphar.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Seth Forshee <sforshee@kernel.org>,
linux-fsdevel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] file: always lock position
Date: Mon, 24 Jul 2023 20:48:43 +0200 [thread overview]
Message-ID: <20230724-geadelt-nachrangig-07e431a2f3a4@brauner> (raw)
In-Reply-To: <CAHk-=wgqLGdTs5hBDskY4HjizPVYJ0cA6=-dwRR3TpJY7GZG3A@mail.gmail.com>
On Mon, Jul 24, 2023 at 11:27:29AM -0700, Linus Torvalds wrote:
> On Mon, 24 Jul 2023 at 11:05, Jens Axboe <axboe@kernel.dk> wrote:
> >
> > io_uring never does that isn't the original user space creator task, or
> > from the io-wq workers that it may create. Those are _always_ normal
> > threads. There's no workqueue/kthread usage for IO or file
> > getting/putting/installing/removing etc.
>
> That's what I thought. But Christian's comments about the io_uring
> getdents work made me worry.
Sorry, my point was that an earlier version of the patchset _would_ have
introduced a locking scheme that would've violated locking assumptions
because it didn't get the subtle refcount difference right. But that was
caught during review.
It's really just keeping in mind that refcount rules change depending on
whether fds or fixed files are used.
>
> If io_uring does everything right, then the old "file_count(file) > 1"
> test in __fdget_pos() - now sadly removed - should work just fine for
> any io_uring directory handling.
Yes, but only if you disallow getdents with fixed files when the
reference count rules are different.
>
> It may not be obvious when you look at just that test in a vacuum, but
> it happens after __fdget_pos() has done the
>
> unsigned long v = __fdget(fd);
> struct file *file = (struct file *)(v & ~3);
>
> and if it's a threaded app - where io_uring threads count the same -
> then the __fdget() in that sequence will have incremented the file
> count.
>
> So when it then used to do that
>
> if (file_count(file) > 1) {
>
> that "> 1" included not just all the references from dup() etc, but
> for any threaded use where we have multiple references to the file
> table it also that reference we get from __fdget() -> __fget() ->
> __fget_files() -> __fget_files_rcu() -> get_file_rcu() ->
> atomic_long_inc_not_zero(&(x)->f_count)).
Yes, for the regular system call path it's all well and dandy and I said
as much on the getdents thread as well.
next prev parent reply other threads:[~2023-07-24 18:48 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-24 15:00 [PATCH] file: always lock position Christian Brauner
2023-07-24 15:53 ` Linus Torvalds
2023-07-24 16:19 ` Christian Brauner
2023-07-24 16:36 ` Linus Torvalds
2023-07-24 16:51 ` Linus Torvalds
2023-09-02 4:44 ` Al Viro
2023-07-24 17:23 ` Christian Brauner
2023-07-24 17:34 ` Linus Torvalds
2023-07-24 17:46 ` Christian Brauner
2023-07-24 18:01 ` Linus Torvalds
2023-07-24 18:05 ` Jens Axboe
2023-07-24 18:27 ` Linus Torvalds
2023-07-24 18:48 ` Christian Brauner [this message]
2023-07-24 22:25 ` Linus Torvalds
2023-07-24 22:56 ` Jens Axboe
2023-07-25 18:30 ` Linus Torvalds
2023-07-25 20:41 ` Jens Axboe
2023-07-25 20:51 ` Linus Torvalds
2023-07-25 20:58 ` Jens Axboe
2023-07-26 8:36 ` Christian Brauner
2023-07-26 10:31 ` David Laight
2023-07-26 12:53 ` Christian Brauner
2023-07-26 8:07 ` Christian Brauner
2023-07-24 16:46 ` Christian Brauner
2023-07-24 16:59 ` Linus Torvalds
2023-07-24 17:18 ` Linus Torvalds
2023-08-03 9:53 ` Mateusz Guzik
2023-08-03 14:15 ` Christian Brauner
2023-08-03 15:17 ` Mateusz Guzik
2023-08-03 15:18 ` Mateusz Guzik
2023-08-03 15:45 ` Linus Torvalds
2023-08-03 17:54 ` Mateusz Guzik
2023-08-03 18:02 ` Christian Brauner
2023-08-03 18:35 ` Linus Torvalds
2023-08-04 13:43 ` Christian Brauner
2023-08-04 13:59 ` Christoph Hellwig
2023-09-02 3:43 ` Al Viro
[not found] <20230804-turnverein-helfer-ef07a4d7bbec@brauner>
2023-08-05 11:46 ` Christian Brauner
2023-08-05 18:47 ` Linus Torvalds
2023-08-05 19:46 ` Linus Torvalds
2023-08-06 6:10 ` Christian Brauner
2023-08-06 13:25 ` Christian Brauner
2023-08-06 17:48 ` Linus Torvalds
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=20230724-geadelt-nachrangig-07e431a2f3a4@brauner \
--to=brauner@kernel.org \
--cc=axboe@kernel.dk \
--cc=cyphar@cyphar.com \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sforshee@kernel.org \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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