linux-kernel - Re: 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: <aWFcmSNLq9XM8KjW@fedora>
Date: Fri, 9 Jan 2026 20:55:06 +0100
From: Horst Birthelmer <horst@...thelmer.de>
To: Bernd Schubert <bschubert@....com>
Cc: Amir Goldstein <amir73il@...il.com>, 
	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-fsdevel@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Matt Harvey <mharvey@...ptrading.com>, 
	"kernel-dev@...lia.com" <kernel-dev@...lia.com>
Subject: Re: Re: [RFC PATCH v2 4/6] fuse: implementation of the
 FUSE_LOOKUP_HANDLE operation

On Fri, Jan 09, 2026 at 07:12:41PM +0000, Bernd Schubert wrote:
> On 1/9/26 19:29, Amir Goldstein wrote:
> > 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?
> 
> Horst just posted the libfuse PR for compounds
> https://github.com/libfuse/libfuse/pull/1418
> 
> You can make it atomic on the libfuse side with the compound
> implementation. I.e. you have the option leave it to libfuse to handle
> compound by compound as individual requests, or you handle the compound
> yourself as one request.
> 
> I think we need to create an example with self handling of the compound,
> even if it is just to ensure that we didn't miss anything in design.

I actually do have an example that would be suitable.
I could implement the LOOKUP+CREATE as a pseudo atomic operation in passthrough_hp.

> 
> 
> Thanks,
> Bernd

Cheers,
Horst