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: <877bta26kj.fsf@wotan.olymp>
Date: Wed, 21 Jan 2026 17:56:12 +0000
From: Luis Henriques <luis@...lia.com>
To: Horst Birthelmer <horst@...thelmer.de>
Cc: Bernd Schubert <bernd@...ernd.com>, Bernd Schubert <bschubert@....com>,
  Amir Goldstein <amir73il@...il.com>,  Miklos Szeredi <miklos@...redi.hu>,
  "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

Hi Horst!

On Fri, Jan 09 2026, Horst Birthelmer wrote:

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

So, I've been working on getting an implementation of LOOKUP_HANDLE+STATX.
And I would like to hear your opinion on a problem I found:

If the kernel is doing a LOOKUP, you'll send the parent directory nodeid
in the request args.  On the other hand, the nodeid for a STATX will be
the nodeid will be for the actual inode being statx'ed.

The problem is that when merging both requests into a compound request,
you don't have the nodeid for the STATX.  I've "fixed" this by passing in
FUSE_ROOT_ID and hacking user-space to work around it: if the lookup
succeeds, we have the correct nodeid for the STATX.  That seems to work
fine for my case, where the server handles the compound request itself.
But from what I understand libfuse can also handle it as individual
requests, and in this case the server wouldn't know the right nodeid for
the STATX.

Obviously, the same problem will need to be solved for other operations
(for example for FUSE_CREATE where we'll need to do a FUSE_MKOBJ_H +
FUSE_STATX + FUSE_OPEN).

I guess this can eventually be fixed in libfuse, by updating the nodeid in
this case.  Another solution is to not allow these sort of operations to
be handled individually.  But maybe I'm just being dense and there's a
better solution for this.

Cheers,
-- 
Luís