ipc/sem: Fix semctl(..., GETPID, ...) between pid namespaces
authorEric W. Biederman <ebiederm@xmission.com>
Fri, 23 Mar 2018 06:11:29 +0000 (01:11 -0500)
committerEric W. Biederman <ebiederm@xmission.com>
Tue, 27 Mar 2018 20:53:55 +0000 (15:53 -0500)
commit51d6f2635b39709ee5e62479be23d423b760292c
treedab790cf23f3ab3ed923effcb1f7d4f6e5526702
parent39a4940eaa185910bb802ca9829c12268fd2c855
ipc/sem: Fix semctl(..., GETPID, ...) between pid namespaces

Today the last process to update a semaphore is remembered and
reported in the pid namespace of that process.  If there are processes
in any other pid namespace querying that process id with GETPID the
result will be unusable nonsense as it does not make any
sense in your own pid namespace.

Due to ipc_update_pid I don't think you will be able to get System V
ipc semaphores into a troublesome cache line ping-pong.  Using struct
pids from separate process are not a problem because they do not share
a cache line.  Using struct pid from different threads of the same
process are unlikely to be a problem as the reference count update
can be avoided.

Further linux futexes are a much better tool for the job of mutual
exclusion between processes than System V semaphores.  So I expect
programs that  are performance limited by their interprocess mutual
exclusion primitive will be using futexes.

So while it is possible that enhancing the storage of the last
rocess of a System V semaphore from an integer to a struct pid
will cause a performance regression because of the effect
of frequently updating the pid reference count.  I don't expect
that to happen in practice.

This change updates semctl(..., GETPID, ...) to return the
process id of the last process to update a semphore inthe
pid namespace of the calling process.

Fixes: b488893a390e ("pid namespaces: changes to show virtual ids to user")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
ipc/sem.c