sched/numa: Ngid is reported as a global pid inside a pid namespace

[Maoyi Xie]

Hi all,

I think Ngid in /proc/<pid>/status is not translated into the pid
namespace of the procfs instance it is read from. I would appreciate it
if you could take a look.

task_state() translates the other pids it prints (fs/proc/array.c).

	ppid = task_ppid_nr_ns(p, ns);
	tgid = task_tgid_nr_ns(p, ns);
	ngid = task_numa_group_id(p);

task_numa_group_id() returns the gid of the task's NUMA group.
task_numa_group() sets it from p->pid when it creates the group. A task
in a group therefore shows the pid, in the initial pid namespace, of the
task that created the group.

A CodeQL check for pids printed without a namespace translation reported
sched_show_numa(), which prints the same value in /proc/<pid>/sched. I
reproduced the Ngid case on mainline 5e0f8396d480 in qemu with two NUMA
nodes and numa_balancing enabled. It needed no kernel changes. An
unprivileged workload under "unshare -Urpf --propagation private
--mount-proc" has tasks 1 to 17 in its new namespace and reads
"Ngid: 421" from /proc/self/task/<tid>/status.

I sent these three fixes for the same kind of gap this year.

  keys      https://git.kernel.org/linus/0d6a4268b060
  io_uring  https://git.kernel.org/linus/3799c2570982
  netdev    https://git.kernel.org/linus/1f24c0d01db2

I am not sure which fix is right. One is to keep a struct pid in the
group and print it with pid_nr_ns(). Another is to print 0 unless the
procfs instance belongs to the initial pid namespace. I tested the
second one for Ngid, but proc.rst documents 0 as no group.

Does this look worth fixing? If it does, I am happy to send a patch, or
to leave the fix to you.

Thanks,
Maoyi