ipc/shm: Fix shmctl(..., IPC_STAT, ...) between pid namespaces.
authorEric W. Biederman <ebiederm@xmission.com>
Fri, 23 Mar 2018 05:29:57 +0000 (00:29 -0500)
committerEric W. Biederman <ebiederm@xmission.com>
Tue, 27 Mar 2018 20:53:09 +0000 (15:53 -0500)
commit98f929b1bd4d0b7c7a77d0d9776d1b924db2e454
tree9cfeab6782aea7b92f858b5e3e595b75fe22bfa3
parent03f1fc09180b345582889a344b012d069b3a6dbe
ipc/shm: Fix shmctl(..., IPC_STAT, ...) between pid namespaces.

Today shm_cpid and shm_lpid are remembered in the pid namespace of the
creator and the processes that last touched a sysvipc shared memory
segment.   If you have processes in multiple pid namespaces that
is just wrong, and I don't know how this has been over-looked for
so long.

As only creation and shared memory attach and shared memory detach
update the pids I do not expect there to be a repeat of the issues
when struct pid was attached to each af_unix skb, which in some
notable cases cut the performance in half.  The problem was threads of
the same process updating same struct pid from different cpus causing
the cache line to be highly contended and bounce between cpus.

As creation, attach, and detach are expected to be rare operations for
sysvipc shared memory segments I do not expect that kind of cache line
ping pong to cause probems.  In addition because the pid is at a fixed
location in the structure instead of being dynamic on a skb, the
reference count of the pid does not need to be updated on each
operation if the pid is the same.  This ability to simply skip the pid
reference count changes if the pid is unchanging further reduces the
likelihood of the a cache line holding a pid reference count
ping-ponging between cpus.

Fixes: b488893a390e ("pid namespaces: changes to show virtual ids to user")
Reviewed-by: Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
ipc/shm.c