Hi!

As I mentioned in the v1 cover letter, I've been working on implementing the
FUSE_LOOKUP_HANDLE operation.  As I also mentioned, this is being done in
the scope of a wider project, which is to be able to restart FUSE servers
without the need to unmount the file systems.  For context, here are the
links again: [0] [1].

This v2 tries to address (most of) the comments from Amir to v1[2].  I don't
think I'm addressing them all, but since a few weeks have already passed, I
decided it's time to send a new version anyway.

Here's what changed since v1:

- Handle assertion gracefully in create_new_entry() (Amir)
- Don't truncate handle in fuse_iget() if size is too large (Amir)
- Move NFS-related changes to a different patch (Amir)
  In fact, I ended-up moving all the NFS-related code to a different file
- Handle compat (still WIP)
- Fix out_argvar handling: variable length arguments are not always the last
  arg now, so a new patch is handling this
- Re-implemented NFS-related changes
  Still only lightly tested, and as Amir hinted, it should probably include
  an extra init flag to select between old vs new NFS handles format
- The usual bug fixes found during more testing

[0] https://lore.kernel.org/all/8734afp0ct.fsf@igalia.com
[1] https://lore.kernel.org/all/CAJfpegvNZ6Z7uhuTdQ6quBaTOYNkAP8W_4yUY4L2JRAEKxEwOQ@mail.gmail.com
[2] https://lore.kernel.org/all/20251120105535.13374-1-luis@igalia.com

Cheers,
--
Luis

Luis Henriques (6):
  fuse: store index of the variable length argument
  fuse: move fuse_entry_out structs out of the stack
  fuse: initial infrastructure for FUSE_LOOKUP_HANDLE support
  fuse: implementation of the FUSE_LOOKUP_HANDLE operation
  fuse: factor out NFS export related code
  fuse: implementation of export_operations with FUSE_LOOKUP_HANDLE

 fs/fuse/Makefile          |   2 +-
 fs/fuse/cuse.c            |   1 +
 fs/fuse/dev.c             |  20 ++-
 fs/fuse/dir.c             | 216 ++++++++++++++++++--------
 fs/fuse/export.c          | 318 ++++++++++++++++++++++++++++++++++++++
 fs/fuse/file.c            |   1 +
 fs/fuse/fuse_i.h          |  53 ++++++-
 fs/fuse/inode.c           | 230 +++++++++------------------
 fs/fuse/ioctl.c           |   1 +
 fs/fuse/readdir.c         |  10 +-
 fs/fuse/virtio_fs.c       |   6 +-
 fs/fuse/xattr.c           |   2 +
 include/linux/exportfs.h  |   7 +
 include/uapi/linux/fuse.h |  16 +-
 14 files changed, 645 insertions(+), 238 deletions(-)
 create mode 100644 fs/fuse/export.c

Luis Henriques <luis@igalia.com>:
> As I mentioned in the v1 cover letter, I've been working on implementing the
> FUSE_LOOKUP_HANDLE operation.  As I also mentioned, this is being done in
> the scope of a wider project, which is to be able to restart FUSE servers
> without the need to unmount the file systems.  For context, here are the
> links again: [0] [1].

Will this fix long-standing fuse+suspend problem, described here
https://lore.kernel.org/all/20250720205839.2919-1-safinaskar@zohomail.com/ ?

-- 
Askar Safin

On Sun, Dec 14 2025, Askar Safin wrote:

> Luis Henriques <luis@igalia.com>:
>> As I mentioned in the v1 cover letter, I've been working on implementing the
>> FUSE_LOOKUP_HANDLE operation.  As I also mentioned, this is being done in
>> the scope of a wider project, which is to be able to restart FUSE servers
>> without the need to unmount the file systems.  For context, here are the
>> links again: [0] [1].
>
> Will this fix long-standing fuse+suspend problem, described here
> https://lore.kernel.org/all/20250720205839.2919-1-safinaskar@zohomail.com/ ?

No, this won't fix that.  This patchset is just an attempt to be a step
closer to be able to restart a FUSE server.  But other things will be
needed (including changes in the user-space server).

Cheers,
-- 
Luís

On Mon, Dec 15, 2025 at 3:08 PM Luis Henriques <luis@igalia.com> wrote:
> No, this won't fix that.  This patchset is just an attempt to be a step
> closer to be able to restart a FUSE server.  But other things will be
> needed (including changes in the user-space server).

So, fix for fuse+suspend is planned?

--
Askar Safin

On 12/16/25 01:33, Askar Safin wrote:
> On Mon, Dec 15, 2025 at 3:08 PM Luis Henriques <luis@igalia.com> wrote:
>> No, this won't fix that.  This patchset is just an attempt to be a step
>> closer to be able to restart a FUSE server.  But other things will be
>> needed (including changes in the user-space server).
> 
> So, fix for fuse+suspend is planned?

I have an idea about this, but this is not a one-liner and might not
work either. The hard part is wait_event() in request_wait_answer().
Probably also needs libfuse support, because libraries might complain
when they eventually reply, but the request is not there anymore. We can
work on this during my x-mas holidays (feel free to ping from next week
on), but please avoid posting about this in unrelated threads.


Thanks,
Bernd

Bernd Schubert <bernd@bsbernd.com>:
> work on this during my x-mas holidays (feel free to ping from next week
> on), but please avoid posting about this in unrelated threads.

Here is another ping.

-- 
Askar Safin

Bernd Schubert <bernd@bsbernd.com>:
> work on this during my x-mas holidays (feel free to ping from next week
> on), but please avoid posting about this in unrelated threads.

Here is ping.

-- 
Askar Safin

On Tue, Dec 16, 2025 at 9:49 PM Bernd Schubert <bernd@bsbernd.com> wrote:
> I have an idea about this, but this is not a one-liner and might not
> work either. The hard part is wait_event() in request_wait_answer().
> Probably also needs libfuse support, because libraries might complain
> when they eventually reply, but the request is not there anymore. We can
> work on this during my x-mas holidays (feel free to ping from next week
> on), but please avoid posting about this in unrelated threads.

Thank you!!! Please, CC me when you have some patches. I will test them.



-- 
Askar Safin

On Tue, Dec 16 2025, Askar Safin wrote:

> On Mon, Dec 15, 2025 at 3:08 PM Luis Henriques <luis@igalia.com> wrote:
>> No, this won't fix that.  This patchset is just an attempt to be a step
>> closer to be able to restart a FUSE server.  But other things will be
>> needed (including changes in the user-space server).
>
> So, fix for fuse+suspend is planned?

To be honest, I really don't know.  I haven't looked closely into that
issue (time is scarce) but I'm not sure if the real problem you're
reporting in your link is a kernel issue or a problem in the user-space
implementation.  Have you tried to report it upstream (to the sshfs
maintainers)?

Cheers,
-- 
Luís