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: <645edb96-e747-4f24-9770-8f7902c95456@ddn.com>
Date: Fri, 9 Jan 2026 19:12:41 +0000
From: Bernd Schubert <bschubert@....com>
To: Amir Goldstein <amir73il@...il.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-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: [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP_HANDLE
 operation

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.


Thanks,
Bernd