kernel/linux.git/ipc, branch linux-2.6.28.y

mqueue: fix si_pid value in mqueue do_notify()

2009-02-20T22:40:17+00:00

commit a6684999f7c6bddd75cf9755ad7ff44435f72fff upstream. If a process registers for asynchronous notification on a POSIX message queue, it gets a signal and a siginfo_t structure when a message arrives on the message queue. The si_pid in the siginfo_t structure is set to the PID of the process that sent the message to the message queue. The principle is the following: . when mq_notify(SIGEV_SIGNAL) is called, the caller registers for notification when a msg arrives. The associated pid structure is stroed into inode_info->notify_owner. Let's call this process P1. . when mq_send() is called by say P2, P2 sends a signal to P1 to notify him about msg arrival. The way .si_pid is set today is not correct, since it doesn't take into account the fact that the process that is sending the message might not be in the same namespace as the notified one. This patch proposes to set si_pid to the sender's pid into the notify_owner namespace. Signed-off-by: Nadia Derbey Signed-off-by: Sukadev Bhattiprolu Acked-by: Oleg Nesterov Cc: Roland McGrath Cc: Bastian Blank Cc: Pavel Emelyanov Cc: Eric W. Biederman Acked-by: Serge Hallyn Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

shm: fix shmctl(SHM_INFO) lockup with !CONFIG_SHMEM

2009-02-12T17:50:23+00:00

commit a68e61e8ff2d46327a37b69056998b47745db6fa upstream. shm_get_stat() assumes that the inode is a "struct shmem_inode_info", which is incorrect for !CONFIG_SHMEM (see fs/ramfs/inode.c: ramfs_get_inode() vs. mm/shmem.c: shmem_get_inode()). This bad assumption can cause shmctl(SHM_INFO) to lockup when shm_get_stat() tries to spin_lock(&info->lock). Users of !CONFIG_SHMEM may encounter this lockup simply by invoking the 'ipcs' command. Reported by Jiri Olsa back in February 2008: http://lkml.org/lkml/2008/2/29/74 Signed-off-by: Tony Battersby Cc: Jiri Kosina Reported-by: Jiri Olsa Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

System call wrappers part 26

2009-01-18T18:44:00+00:00

commit c4ea37c26a691ad0b7e86aa5884aab27830e95c9 upstream. Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

System call wrappers part 25

2009-01-18T18:44:00+00:00

commit d5460c9974a321a194aded4a8c4daaac68ea8171 upstream. Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

System call wrappers part 24

2009-01-18T18:44:00+00:00

commit e48fbb699f82ef1e80bd7126046394d2dc9ca7e6 upstream. Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

System call wrapper special cases

2009-01-18T18:43:52+00:00

commit 6673e0c3fbeaed2cd08e2fd4a4aa97382d6fedb0 upstream. System calls with an unsigned long long argument can't be converted with the standard wrappers since that would include a cast to long, which in turn means that we would lose the upper 32 bit on 32 bit architectures. Also semctl can't use the standard wrapper since it has a 'union' parameter. So we handle them as special case and add some extra wrappers instead. Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

Convert all system calls to return a long

2009-01-18T18:43:50+00:00

commit 2ed7c03ec17779afb4fcfa3b8c61df61bd4879ba upstream. Convert all system calls to return a long. This should be a NOP since all converted types should have the same size anyway. With the exception of sys_exit_group which returned void. But that doesn't matter since the system call doesn't return. Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

sysvipc: fix the ipc structures initialization

2008-11-20T02:49:57+00:00

A problem was found while reviewing the code after Bugzilla bug http://bugzilla.kernel.org/show_bug.cgi?id=11796. In ipc_addid(), the newly allocated ipc structure is inserted into the ipcs tree (i.e made visible to readers) without locking it. This is not correct since its initialization continues after it has been inserted in the tree. This patch moves the ipc structure lock initialization + locking before the actual insertion. Signed-off-by: Nadia Derbey Reported-by: Clement Calmels Cc: Manfred Spraul Cc: [2.6.27.x] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] introduce fmode_t, do annotations

2008-10-21T11:47:06+00:00

Signed-off-by: Al Viro

message queues: increase range limits

2008-10-20T15:52:40+00:00

Increase the range of various posix message queue limits. Posix gives the message queue user the ability to 'trade off' the maximum size of messages with the number of possible messages that can be 'in flight'. Linux currently makes this trade off more restrictive than it needs to be. In particular, the maximum message size today can be made no smaller than 8192. This greatly restricts those applications that would like to have the ability to post large numbers of very small messages. So this task lowers the limit that the maximum message size can be set to, from 8192 to 128. It also lowers the limit that the maximum #number of messages in flight can be set to, from 10 to 1. With these changes the message queue user can make better trade offs between #messages and message size, in order to get everything to fit within the setrlimit(RLIMIT_MSGQUEUE) limit for that particular user. This patch also applies the values in /proc/sys/fs/mqueue/msg_max /proc/sys/fs/mqueue/msgsize_max as the defaults for the max #messages allowed and the max message size allowed, respectively, for those applications that do not supply these. Previously, the defaults were hardwired to 10 and 8192, respectively. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Joe Korty Cc: Al Viro Cc: Manfred Spraul Cc: Nadia Derbey Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds