Re: [PATCH 2/2] test: exercise FUSE_NOTIFY_RESEND

[Luis Henriques <luis@igalia.com>]

On Sat, Oct 10 2026, Baokun Li wrote:

> Hi Luís,
>
> On 2026/10/9 21:51, Luis Henriques wrote:
>> Hi!
>>
>> On Fri, Oct 09 2026, Baokun Li wrote:
>>
>>> Hi Bernd,
>>>
>>> On 2026/10/9 16:19, Bernd Schubert wrote:
>>>> Hi Baokun,
>>>>
>>>> On 10/9/26 09:54, Baokun Li wrote:
>>>>> test_notify_resend drops the first GETATTR of a file and asks the
>>>>> kernel to resend pending requests via fuse_lowlevel_notify_resend().
>>>>> The kernel redelivers the request with the FUSE_UNIQUE_RESEND bit set;
>>>>> the daemon detects it with fuse_req_is_resend(), answers it, and the
>>>>> client's stat() completes.
>>>> to be honest, this is one the features that I have no clue about what it
>>>> exists for. Why would a daemon drop requests? 
>>> The daemon does not drop them on purpose - they are lost because it
>>> dies with the requests in flight.  This is the failover scenario the
>>> feature was added for: the old daemon has already read a request from
>>> /dev/fuse, but panics before replying to it.
>>>
>>> Meanwhile the file descriptor of the connection is preserved - by
>>> another daemon, or simply by the service manager: systemd's file
>>> descriptor store keeps the /dev/fuse fd across a daemon restart
>>> (FDSTORE=1, retrieved again with sd_listen_fds()).
>>>
>>> A newly started daemon then takes the fd over and keeps serving
>>> new requests; the requests the old daemon had already read can be
>>> recovered with FUSE_NOTIFY_RESEND (760eac73f9f6, "fuse: Introduce a
>>> new notification type for resend pending requests").
>>>
>>>> The use-case I have in my mind is a daemon upgrade, 
>>> Yes, a daemon upgrade is indeed one of the scenarios.  It is the same
>>> flow as the failover case above, only planned: the old daemon hands
>>> the fd over to the new daemon instead of dying with it.
>>>
>>>> but that would mean that either kernel needs
>>>> to send a re-lookup of all inodes or that daemon needs to store lookup
>>>> objects (I personally see these as counter part of kernel inodes). Now,
>>>> besides not being implemented at all, kernel will have a hard time to
>>>> send re-lookup requests, unless fuse-server supports lookup by 64 bit
>>>> node-id.
>>> You're right that the new daemon can only answer the resent
>>> requests if it can still map their node IDs (and other state) to
>>> its own objects - that is the "daemon stores lookup objects" side
>>> you mention, and it is deliberately left to the daemon.
>>>
>>> FUSE_NOTIFY_RESEND does not attempt to solve state preservation -
>>> it only guarantees delivery of the requests that would otherwise
>>> be unreachable forever, no matter how much state the daemon kept.
>>>
>>>> I.e. in my personal opinion the prerequisite of FUSE_NOTIFY_RESEND is
>>>> missing (which could be LOOKUP_HANDLE and then using that to re-lookup
>>>> inodes after a daemon termination).
>>> Something like LOOKUP_HANDLE, where the kernel and the daemon pass
>>> file handles directly so no node ID mapping is needed, would be
>>> ideal.  However, I think a persistent node ID mapping on the daemon
>>> side would also work.
>>>
>>>> The example below also just does a simple exercise of
>>>> FUSE_NOTIFY_RESEND, without revealing what it would be useful for - that
>>>> is the part I would like to see fulfilled by an example.
>>>>
>>> Yes, it only checks that the API works.  It has no fd preservation
>>> mechanism and no persistent node ID mapping either.
>>>
>>> A full takeover setup needs the fd and state handover, which is daemon
>>> specific and not something a libfuse test can realistically contain,
>>> so I think explaining the model in the test and the commit message is
>>> the right scope.  Let me know if you would prefer something different.
>> Thank you, Baokun, for the above description (and Bernd for explicitly
>> CC'ing me to a patchset that I could have missed!).
>>
>> I had a PR [1] created long time ago that included something similar to
>> your first patch in this set.  
>
> Sorry for missing your PR #1219.  We had been using resend through
> the early sysfs based scheme all along; only recently, when moving
> to a newer kernel and preparing the switch to the notify based one,
> did we find that libfuse had no API for it - hence this patch.

Sure, no problem.  That PR has been stale, and I'm fine with your patch.
Feel free to add my 'Acked-by:'.

>> The difference was that I also tried to
>> solve yet another problem: setting the fd back into libfuse-specific data
>> structures (i.e. re-initialise libfuse itself).
>
> The RFC looks good to me.  I did not implement
> fuse_session_reinitialize, because our daemon restores the session in
> a hacky way, so we had no need for the interface - but adding it would
> clearly be better.
>
>> This was an RFC, which later made me start looking into the LOOKUP_HANDLE.
>> Which is currently stale, but hopefully to resume soon.
>>
>> [1] https://github.com/libfuse/libfuse/pull/1219
>>
>> Cheers,
>
> Note that resend is not strongly tied to LOOKUP_HANDLE: we have been
> using it without LOOKUP_HANDLE for several years, with the daemon
> keeping its own state across restarts.

Yes, absolutely.  If you keep the state on user-space and if nodeids are
always unique and not reused, then LOOKUP_HANDLE is not really required.

> That said, LOOKUP_HANDLE is indeed valuable - we have a similar
> mechanism on our side as well.

Yeah, this will make it easier for new servers to support a restart
without extra complexities.

Cheers,
-- 
Luís