[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <fab63d7c-89e2-4c30-a685-0d623a05546e@maowtm.org>
Date: Wed, 4 Jun 2025 01:58:03 +0100
From: Tingmao Wang <m@...wtm.org>
To: Song Liu <song@...nel.org>, Al Viro <viro@...iv.linux.org.uk>
Cc: Jan Kara <jack@...e.cz>, bpf@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org, kernel-team@...a.com,
andrii@...nel.org, eddyz87@...il.com, ast@...nel.org, daniel@...earbox.net,
martin.lau@...ux.dev, brauner@...nel.org, kpsingh@...nel.org,
mattbobrowski@...gle.com, amir73il@...il.com, repnop@...gle.com,
jlayton@...nel.org, josef@...icpanda.com, mic@...ikod.net, gnoack@...gle.com
Subject: Re: [PATCH bpf-next 3/4] bpf: Introduce path iterator
On 5/30/25 01:42, Song Liu wrote:
> [...]
> On Thu, May 29, 2025 at 4:10 PM Al Viro <viro@...iv.linux.org.uk> wrote:
>>
>> Note, BTW, that it might be better off by doing that similar to
>> d_path.c - without arseloads of dget_parent/dput et.al.; not sure
>> how feasible it is, but if everything in it can be done under
>> rcu_read_lock(), that's something to look into.
>
> I don't think we can do everything here inside rcu_read_lock().
> But d_path.c does have some code we can probably reuse or
> learn from.
Note that I've made an RFC patch for this as I've also been looking into
this a bit earlier:
https://lore.kernel.org/all/cover.1748997840.git.m@maowtm.org/
I've CC'd some people here but not all, in the interest of not spamming
like 20 people, but feedback from all is welcome. Mine is also its own
separate patch that shouldn't block Song's patch here, and I can rebase it
on top of (v2 or a later version of) this series once this is merged.
Powered by blists - more mailing lists