Re: [PATCH 23/32] fuse: split out filesystem part of request sending

Re: [PATCH 23/32] fuse: split out filesystem part of request sending

[David CARLIER]

Hi Miklos,

This change alters the pid sent on force && nocreds requests — intended?

Previously these allocated a zeroed request and skipped fuse_force_creds(),
so they went out with in.h.pid == 0. In fuse_fill_creds(), args->pid is
now set before the nocreds early return, and fuse_args_to_req() copies it
unconditionally — so writeback, release, and DESTROY requests now report the
triggering (often kernel-worker) pid instead of 0. uid/gid sit below the
return and are still left at 0.

Looks like the args->pid assignment was hoisted above the nocreds check by
accident. If keeping these requests credential-free is intended, setting pid
only where uid/gid are filled would restore it. If unconditional pid is
deliberate, disregard.
Cheers

Re: [PATCH 23/32] fuse: split out filesystem part of request sending

[Miklos Szeredi]

On Sat, 27 Jun 2026 at 22:16, David CARLIER <devnexen@gmail.com> wrote:
>
> Hi Miklos,
>
> This change alters the pid sent on force && nocreds requests — intended?
>
> Previously these allocated a zeroed request and skipped fuse_force_creds(),
> so they went out with in.h.pid == 0. In fuse_fill_creds(), args->pid is
> now set before the nocreds early return, and fuse_args_to_req() copies it
> unconditionally — so writeback, release, and DESTROY requests now report the
> triggering (often kernel-worker) pid instead of 0. uid/gid sit below the
> return and are still left at 0.
>
> Looks like the args->pid assignment was hoisted above the nocreds check by
> accident. If keeping these requests credential-free is intended, setting pid
> only where uid/gid are filled would restore it. If unconditional pid is
> deliberate, disregard.

Your are right, this was accidental.

Do you want to send a patch?

Thanks,
Miklos