summaryrefslogtreecommitdiffstats
path: root/include/linux
diff options
context:
space:
mode:
authorEric W. Biederman <ebiederm@xmission.com>2018-03-23 00:42:21 -0500
committerBen Hutchings <ben@decadent.org.uk>2018-10-21 08:45:03 +0100
commit95d16ca7c1af98059f39ca43c17aa2f02d652a0c (patch)
tree809bd55761fd2446e6c2c8729ca5adc109866d09 /include/linux
parent2b62f4850d9f1572f7e199993f0fee64fe760d43 (diff)
downloadlinux-stable-95d16ca7c1af98059f39ca43c17aa2f02d652a0c.tar.gz
linux-stable-95d16ca7c1af98059f39ca43c17aa2f02d652a0c.tar.bz2
linux-stable-95d16ca7c1af98059f39ca43c17aa2f02d652a0c.zip
ipc/msg: Fix msgctl(..., IPC_STAT, ...) between pid namespaces
commit 39a4940eaa185910bb802ca9829c12268fd2c855 upstream. Today msg_lspid and msg_lrpid are remembered in the pid namespace of the creator and the processes that last send or received a sysvipc message. If you have processes in multiple pid namespaces that is just wrong. The process ids reported will not make the least bit of sense. This fix is slightly more susceptible to a performance problem than the related fix for System V shared memory. By definition the pids are updated by msgsnd and msgrcv, the fast path of System V message queues. The only concern over the previous implementation is the incrementing and decrementing of the pid reference count. As that is the only difference and multiple updates by of the task_tgid by threads in the same process have been shown in af_unix sockets to create a cache line ping-pong between cpus of the same processor. In this case I don't expect cache lines holding pid reference counts to ping pong between cpus. As senders and receivers update different pids there is a natural separation there. Further if multiple threads of the same process either send or receive messages the pid will be updated to the same value and ipc_update_pid will avoid the reference count update. Which means in the common case I expect msg_lspid and msg_lrpid to remain constant, and reference counts not to be updated when messages are sent. In rare cases it may be possible to trigger the issue which was observed for af_unix sockets, but it will require multiple processes with multiple threads to be either sending or receiving messages. It just does not feel likely that anyone would do that in practice. This change updates msgctl(..., IPC_STAT, ...) to return msg_lspid and msg_lrpid in the pid namespace of the process calling stat. This change also updates cat /proc/sysvipc/msg to return print msg_lspid and msg_lrpid in the pid namespace of the process that opened the proc file. 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> [bwh: Backported to 3.16: adjust filename, context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Diffstat (limited to 'include/linux')
-rw-r--r--include/linux/msg.h4
1 files changed, 2 insertions, 2 deletions
diff --git a/include/linux/msg.h b/include/linux/msg.h
index f3f302f9c197..7f9ea9104535 100644
--- a/include/linux/msg.h
+++ b/include/linux/msg.h
@@ -23,8 +23,8 @@ struct msg_queue {
unsigned long q_cbytes; /* current number of bytes on queue */
unsigned long q_qnum; /* number of messages in queue */
unsigned long q_qbytes; /* max number of bytes on queue */
- pid_t q_lspid; /* pid of last msgsnd */
- pid_t q_lrpid; /* last receive pid */
+ struct pid *q_lspid; /* pid of last msgsnd */
+ struct pid *q_lrpid; /* last receive pid */
struct list_head q_messages;
struct list_head q_receivers;