Re: Question: io_uring SQPOLL fdinfo prints host PID across pid_ns?

From: Jens Axboe

Date: Sat May 09 2026 - 10:00:42 EST


On 5/8/26 2:34 AM, Xie Maoyi wrote:
> Hi Jens, Pavel,
>
> While testing io_uring with the SQPOLL setup flag from inside an
> unprivileged user_ns + pid_ns, I noticed that
> /proc/<pid>/fdinfo/<ring> prints the SQPOLL kthread's host
> (init_pid_ns) PID rather than the kthread's PID as seen from the
> caller's pid_ns. I'm not sure whether this is intended behaviour
> or a bug worth fixing, and would appreciate your view before
> sending a patch.
>
> Reproduction (KASAN, mainline 7.0): a process unshares CLONE_NEWUSER
> | CLONE_NEWPID | CLONE_NEWNS, mounts a private /proc, and a
> grandchild (PID 1 in the new pid_ns) opens an io_uring ring with
> IORING_SETUP_SQPOLL. Inside the new pid_ns:
>
> /proc/self/task contains {1, 2} # SQPOLL kthread is PID 2
> /proc/self/fdinfo/<ring>:
> SqThread: 356 # init_pid_ns view (host PID)
>
> After applying a candidate fix that translates sq->task_pid
> through task_pid_nr_ns() against the inode's pid_ns (mirroring
> pidfd_show_fdinfo() in kernel/pid.c), the same PoC prints:
>
> SqThread: 2 # caller's pid_ns view
>
> Is this expected behaviour, or worth fixing? If a fix would be
> welcome, I have a 2+/1- patch in io_uring/fdinfo.c that's
> checkpatch-clean and verified pre/post on a KASAN VM. Happy to
> send the patch and the full PoC if that's useful.

Please send the patch, I do think we should change that.

--
Jens Axboe