[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wibs_xBP2BGG4UHKhiP2B=7KJnx_LL18O0bGK8QkULLHg@mail.gmail.com>
Date: Wed, 27 Sep 2023 13:27:51 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: Christian Brauner <brauner@...nel.org>, viro@...iv.linux.org.uk,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v2] vfs: shave work on failed file open
On Wed, 27 Sept 2023 at 11:32, Mateusz Guzik <mjguzik@...il.com> wrote:
>
> put_cred showed up in file_free_rcu in d76b0d9b2d87 ("CRED: Use creds in
> file structs"). Commit message does not claim any dependency on this
> being in an rcu callback already and it looks like it was done this way
> because this was the ony spot with kmem_cache_free(filp_cachep, f)
Yes, that looks about right. So the rcu-freeing is almost an accident.
Btw, I think we could get rid of the RCU freeing of 'struct file *' entirely.
The way to fix it is
(a) make sure all f_count accesses are atomic ops (the one special
case is the "0 -> X" initialization, which is ok)
(b) make filp_cachep be SLAB_TYPESAFE_BY_RCU
because then get_file_rcu() can do the atomic_long_inc_not_zero()
knowing it's still a 'struct file *' while holding the RCU read lock
even if it was just free'd.
And __fget_files_rcu() will then re-check that it's the *right*
'struct file *' and do a fput() on it and re-try if it isn't. End
result: no need for any RCU freeing.
But the difference is that a *new* 'struct file *' might see a
temporary atomic increment / decrement of the file pointer because
another CPU is going through that __fget_files_rcu() dance.
Which is why "0 -> X" is ok to do as a "atomic_long_set()", but
everything else would need to be done as "atomic_long_inc()" etc.
Which all seems to be the case already, so with the put_cred() not
needing the RCU delay, I thing we really could do this patch (note:
independent of other issues, but makes your patch require that
"atomic_long_cmpxchg()" and the WARN_ON() should probably go away,
because it can actually happen).
That should help the normal file open/close case a bit, in that it
doesn't cause that extra RCU work.
Of course, on some loads it might be advantageous to do a delayed
de-allocation in some other RCU context, so ..
What do you think?
Linus
PS. And as always: ENTIRELY UNTESTED.
View attachment "patch.diff" of type "text/x-patch" (1364 bytes)
Powered by blists - more mailing lists