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: <CAJfpegsLPJ5B_A34qP-3nXrXc7v2d-QpL3rkGS5rMfGq0g+FCw@mail.gmail.com>
Date: Fri, 9 Jan 2026 20:01:28 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: Amir Goldstein <amir73il@...il.com>
Cc: Bernd Schubert <bschubert@....com>, 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, 9 Jan 2026 at 19:29, Amir Goldstein <amir73il@...il.com> wrote:

> 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?

This won't change anything wrt atomicity, since the request and the
reply are still a single blob.  The reason to do this is that the
interface itself is cleaner and we can swap out one part (like we want
now with the file handle stuff) and reuse the other parts.

So I mostly look on this as a trick to make the interface more
modular, not something that the servers will care about.

> 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?

I was thinking of detaching the lookup + getattr from the directory data.

Now I realize that doing it with a FUSE_NOTIFY is not really useful,
we can just attach the array of entries at the end of the readdir
reply as a separate blob.

> 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.

Yeah, that would be nice.  What about fadvise flag?

Thanks,
Miklos