summaryrefslogtreecommitdiff
path: root/ipc/msg.c
diff options
context:
space:
mode:
authorEric W. Biederman <ebiederm@xmission.com>2018-03-23 00:29:57 -0500
committerEric W. Biederman <ebiederm@xmission.com>2018-03-27 15:53:09 -0500
commit98f929b1bd4d0b7c7a77d0d9776d1b924db2e454 (patch)
tree9cfeab6782aea7b92f858b5e3e595b75fe22bfa3 /ipc/msg.c
parent03f1fc09180b345582889a344b012d069b3a6dbe (diff)
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>
Diffstat (limited to 'ipc/msg.c')
0 files changed, 0 insertions, 0 deletions