[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ldi64sh4.fsf@wotan.olymp>
Date: Fri, 09 Jan 2026 17:16:07 +0000
From: Luis Henriques <luis@...lia.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: Bernd Schubert <bschubert@....com>, Amir Goldstein
<amir73il@...il.com>, "Darrick J. Wong" <djwong@...nel.org>, Kevin Chen
<kchen@....com>, Horst Birthelmer <hbirthelmer@....com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, Matt
Harvey <mharvey@...ptrading.com>, kernel-dev@...lia.com
Subject: Re: [RFC PATCH v2 4/6] fuse: implementation of the
FUSE_LOOKUP_HANDLE operation
On Fri, Jan 09 2026, Miklos Szeredi wrote:
> On Fri, 9 Jan 2026 at 16:56, Bernd Schubert <bschubert@....com> wrote:
>
>> Feasible, but we should extend io-uring to FUSE_NOTIFY first, otherwise
>> this will have a painful overhead.
>
> We don't want to do the lock/add/unlock for individual dentries
> anyway, so might as well make this FUSE_NOTIFY_ENTRIES. That would
> lock the directory, add a bunch of dentries, then unlock.
>
> The fun part is that locking the directory must not be done from the
> READDIR context, as rwsem read locks are apparently not nestable.
> This would make the interface a pain to use. We could work around
> that by checking if a READDIR is currently in progress and then
> synchronizing the two such that the entries are added with the
> directory lock held. It's a bit of complexity, but maybe worth it as
> it's going to be the common usage.
Yikes! Things are not getting any simpler :-(
OK, looks like there's a lot of things I'll need to figure out before
proceeding.
/me schedules some time to learn and play a bit with all this.
Cheers,
--
Luís
Powered by blists - more mailing lists