[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z5fKD1AsqkgDLjox@slm.duckdns.org>
Date: Mon, 27 Jan 2025 08:01:51 -1000
From: Tejun Heo <tj@...nel.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
Michal Koutný <mkoutny@...e.com>,
"Paul E. McKenney" <paulmck@...nel.org>,
Boqun Feng <boqun.feng@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Hillf Danton <hdanton@...a.com>,
Johannes Weiner <hannes@...xchg.org>,
Marco Elver <elver@...gle.com>, Zefan Li <lizefan.x@...edance.com>,
tglx@...utronix.de
Subject: Re: [PATCH v4 4/6] kernfs: Don't re-lock kernfs_root::kernfs_rwsem
in kernfs_fop_readdir().
On Mon, Jan 27, 2025 at 10:02:00AM +0100, Sebastian Andrzej Siewior wrote:
> On 2025-01-24 13:15:32 [-1000], Tejun Heo wrote:
> > Hello,
> >
> > On Fri, Jan 24, 2025 at 06:46:12PM +0100, Sebastian Andrzej Siewior wrote:
> > ...
> > > to avoid holding a global lock during a page fault. The lock drop is
> > > wrong since the support of renames and not a big burden since the lock
> > > is no longer global.
> >
> > It's still a pretty big lock. Hopefully, at least name accesses can be
> > converted to rcu protected ones later?
>
> Not sure what you mean by "rcu protected ones". The name is already RCU
> protected which is part of the problem :P
> Assuming an upper length of name to be around 255 and
> kernfs_fop_readdir() to be very early on the chain then we could copy
> the name on stack within the RCU section and do this without
> ::kernfs_rwsem.
Please ignore me on this one. I'll take a better look next round.
Thanks.
--
tejun
Powered by blists - more mailing lists