Re: [PATCH] net/9p: fix infinite loop in p9_client_rpc on fatal signal

On 4/17/26 01:52, Dominique Martinet wrote>
> So if I understand this right, with a sane server, the tag will be used
> until umount or a reply (to either the flush or the original request)?

 From what I tested — until a reply. Tested on latest master.

Added virtio-9p to QEMU cmdline:

   -virtfs 
local,path=/tmp/shared,mount_tag=p9host,security_model=none,id=p9host

Mounted in VM:

   mount -t 9p -o trans=virtio,version=9p2000.L,access=any p9host 
/mnt/p9real

Tested with and without patch:

   # SIGKILL
   dd if=/dev/zero of=/mnt/p9real/bigfile bs=1M count=500 &
   PID=$!; sleep 1 && kill -KILL $PID; wait $PID

   # SIGINT
   dd if=/dev/zero of=/mnt/p9real/bigfile bs=1M count=500 &
   PID=$!; sleep 1 && kill -INT $PID

SIGKILL — transport cleanup picks up the remaining ref:

   p9_req_put req ff11000108aa8... tag 0 refcount before=2
   p9_req_put req ff11000108aa8... tag 0 refcount before=2
   tag 0 removed from IDR
   [1]+  Killed  dd ...

SIGINT — server replies and drops the last ref:

   p9_req_put req ff1100010e073... tag 0 refcount before=2
   p9_req_put req ff1100010e073... tag 0 refcount before=1
   tag 0 removed from IDR
   1+0 records in
   [1]+  Interrupt  dd ...

No hangs, no leaks, no regressions with or without patch in either case.

Syzkaller reproducer (trans=fd, no peer): without patch — permanent
D-state, process never exits. With patch, each iteration completes
cleanly and both tags are properly removed from IDR:

   p9_req_put tag 65535 refcount 3->2->1, removed from IDR
   p9_req_put tag 0     refcount 3->2->1, removed from IDR

Also verified forced kill of the reproducer — tags cleaned up correctly.

Severity is low and likely unreachable in production, but it slows
down syzkaller — the hung process ties up a worker slot until the
harness kills it by timeout (143s on our setup).

-- 
Thanks,
Vasiliy