[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250127090200.lEQ2Igag@linutronix.de>
Date: Mon, 27 Jan 2025 10:02:00 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Tejun Heo <tj@...nel.org>
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 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.
> > Don't re-acquire kernfs_root::kernfs_rwsem while copying the name to the
> > userpace buffer.
> >
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
>
> Acked-by: Tejun Heo <tj@...nel.org>
>
> Thanks.
Sebastian
Powered by blists - more mailing lists