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: <CAOQ4uxiVwrane=X+fwPrgyVYMRox6DgCpbZJvi_DeMNF8NvTCA@mail.gmail.com>
Date: Fri, 9 Jan 2026 20:28:09 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Miklos Szeredi <miklos@...redi.hu>
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, Jan 9, 2026 at 8:01 PM Miklos Szeredi <miklos@...redi.hu> wrote:
>
> 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.
>

Sure, that works, as long as there is some header to the array,
it could contain the new entry_handle and statx payloads.

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

Definitely, like readahead we would need to support
NO (RANDOM), YES (SEQUENTIAL) and AUTO (NORMAL).

Honestly, I got discouraged from completing readdir passthrough
because of the complexity involved wrt readdirplus, but
maybe I will just post the patches I have for readdir(not plus)
passthrough with the fadvise to facilitate it.

Thanks,
Amir.