linux-kernel - Re: [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOQ4uxhMtz6WqLKPegRy+Do2UU6uJvDOqb8YU6=-jAy98E5Vfw@mail.gmail.com>
Date: Fri, 9 Jan 2026 19:29:00 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Bernd Schubert <bschubert@....com>
Cc: Miklos Szeredi <miklos@...redi.hu>, Luis Henriques <luis@...lia.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 9, 2026 at 4:56 PM Bernd Schubert <bschubert@....com> wrote:
>
>
>
> On 1/9/26 16:37, Miklos Szeredi wrote:
> > On Fri, 9 Jan 2026 at 16:03, Amir Goldstein <amir73il@...il.com> wrote:
> >
> >> What about FUSE_CREATE? FUSE_TMPFILE?
> >
> > FUSE_CREATE could be decomposed to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN.
> >
> > FUSE_TMPFILE is special, the create and open needs to be atomic.   So
> > the best we can do is FUSE_TMPFILE_H + FUSE_STATX.
> >

I thought that the idea of FUSE_CREATE is that it is atomic_open()
is it not?
If we decompose that to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN
it won't be atomic on the server, would it?

> >> and more importantly READDIRPLUS dirents?
> >
> > I was never satisfied with FUSE_READDIRPLUS, I'd prefer something more
> > flexible, where policy is moved from the kernel to the fuse server.
> >
> > How about a push style interface with FUSE_NOTIFY_ENTRY setting up the
> > dentry and the inode?
>
> Feasible, but we should extend io-uring to FUSE_NOTIFY first, otherwise
> this will have a painful overhead.
>
>

I admit that the guesswork with readdirplus auto is not always
what serves users the best, but why change to push?
If the server had actually written the dirents with some header
it could just as well decide per dirent if it wants to return
dirent or direntplus or direntplus_handle.

What is the expected benefit of using push in this scenario?

My own take on READDIRPLUS is that it cries for a user API
so that "ls" could opt-out and "ls -l" could opt-in to readdirplus.

I hacked my own server to use open(O_SYNC) indication for
directories as a signal to choose between readdirplus and
kernel readdir passthrough (not plus) and I have applications
that opt-out of readdirplus.

Thanks,
Amir.