linux-toradex.git/ipc/sem.c, branch v3.10.2

ipc/sem.c: Fix missing wakeups in do_smart_update_queue()

2013-05-26T22:14:51+00:00

do_smart_update_queue() is called when an operation (semop,
semctl(SETVAL), semctl(SETALL), ...) modified the array.  It must check
which of the sleeping tasks can proceed.

do_smart_update_queue() missed a few wakeups:
 - if a sleeping complex op was completed, then all per-semaphore queues
   must be scanned - not only those that were modified by *sops
 - if a sleeping simple op proceeded, then the global queue must be
   scanned again

And:
 - the test for "|sops == NULL) before scanning the global queue is not
   required: If the global queue is empty, then it doesn't need to be
   scanned - regardless of the reason for calling do_smart_update_queue()

The patch is not optimized, i.e.  even completing a wait-for-zero
operation causes a rescan.  This is done to keep the patch as simple as
possible.

Signed-off-by: Manfred Spraul 
Acked-by: Davidlohr Bueso 
Cc: Rik van Riel 
Cc: Andrew Morton 
Signed-off-by: Linus Torvalds

ipc,sem: fix semctl(..., GETNCNT)

2013-05-09T21:17:47+00:00

The semctl GETNCNT returns the number of semops waiting for the
specified semaphore to become nonzero.  After commit 9f1bc2c9022c
("ipc,sem: have only one list in struct sem_queue"), the semops waiting
on just one semaphore are waiting on that semaphore's list.

In order to return the correct count, we have to walk that list too, in
addition to the sem_array's list for complex operations.

Signed-off-by: Rik van Riel 
Signed-off-by: Linus Torvalds

ipc,sem: fix semctl(..., GETZCNT)

2013-05-09T21:17:47+00:00

The semctl GETZCNT returns the number of semops waiting for the
specified semaphore to become zero.  After commit 9f1bc2c9022c
("ipc,sem: have only one list in struct sem_queue"), the semops waiting
on just one semaphore are waiting on that semaphore's list.

In order to return the correct count, we have to walk that list too, in
addition to the sem_array's list for complex operations.

This bug broke dbench; it works again with this patch applied.

Signed-off-by: Rik van Riel 
Reported-by: Kent Overstreet 
Tested-by: Kent Overstreet 
Signed-off-by: Linus Torvalds

ipc: simplify rcu_read_lock() in semctl_nolock()

2013-05-05T00:24:59+00:00

This trivially combines two rcu_read_lock() calls in both sides of a
if-statement into one single one in front of the if-statement.

Split out as an independent cleanup from the previous commit.

Acked-by: Davidlohr Bueso 
Cc: Rik van Riel 
Cc: Al Viro 
Signed-off-by: Linus Torvalds

ipc: simplify semtimedop/semctl_main() common error path handling

2013-05-05T00:21:58+00:00

With various straight RCU lock/unlock movements, one common exit path
pattern had become

	rcu_read_unlock();
	goto out_wakeup;

and in fact there were no cases where we wanted to exit to out_wakeup
_without_ releasing the RCU read lock.

So replace that pattern with "goto out_rcu_wakeup", and remove the old
out_wakeup.

Acked-by: Davidlohr Bueso 
Cc: Rik van Riel 
Cc: Al Viro 
Signed-off-by: Linus Torvalds

ipc: move sem_obtain_lock() rcu locking into the only caller

2013-05-05T00:20:14+00:00

sem_obtain_lock() was another of those functions that returned with the
RCU lock held for reading in the success case.  Move the RCU locking to
the caller (semtimedop()), making it more obvious.  We already did RCU
locking elsewhere in that function.

Side note: why does semtimedop() re-do the semphore lookup after the
sleep, rather than just getting a reference to the semaphore it already
looked up originally?

Acked-by: Davidlohr Bueso 
Cc: Rik van Riel 
Cc: Al Viro 
Signed-off-by: Linus Torvalds

ipc: fix double sem unlock in semctl error path

2013-05-05T00:19:59+00:00

Fix another ipc locking buglet introduced by the scalability patches:
when semctl_down() was changed to delay the semaphore locking, one error
path for security_sem_semctl() went through the semaphore unlock logic
even though the semaphore had never been locked.

Introduced by commit 16df3674efe3 ("ipc,sem: do not hold ipc lock more
than necessary")

Acked-by: Davidlohr Bueso 
Cc: Rik van Riel 
Cc: Al Viro 
Signed-off-by: Linus Torvalds

ipc: move the rcu_read_lock() from sem_lock_and_putref() into callers

2013-05-05T00:19:39+00:00

This is another ipc semaphore locking cleanup, trying to make the
locking more straightforward.  We move the rcu read locking into the
callers of sem_lock_and_putref(), which in general means that we now
mostly do the rcu_read_lock() and rcu_read_unlock() in the same
function.

Mostly.  We still have the ipc_addid/newary/freeary mess, and things
like ipcctl_pre_down_nolock().

Acked-by: Davidlohr Bueso 
Cc: Rik van Riel 
Cc: Al Viro 
Signed-off-by: Linus Torvalds

ipc: sem_putref() does not need the semaphore lock any more

2013-05-04T18:24:21+00:00

ipc_rcu_putref() uses atomics for the refcount, and the games to lock
and unlock the semaphore just to try to keep the reference counting
working are no longer useful.

Acked-by: Davidlohr Bueso 
Cc: Rik van Riel 
Cc: Al Viro 
Signed-off-by: Linus Torvalds

ipc: move rcu_read_unlock() out of sem_unlock() and into callers

2013-05-04T18:24:00+00:00

The IPC locking is a mess, and sem_unlock() unlocks not only the
semaphore spinlock, it also drops the rcu read lock.  Unlike sem_lock(),
which just gets the spin-lock, and expects the caller to get the rcu
read lock.

This all makes things very hard to follow, and it's very confusing when
you take the rcu read lock in one function, and then release it in
another.  And it has caused actual bugs: the sem_obtain_lock() function
ended up dropping the RCU read lock twice in one error path, because it
first did the sem_unlock(), and then did a rcu_read_unlock() to match
the rcu_read_lock() it had done.

This is just a totally mindless "remove rcu_read_unlock() from
sem_unlock() and add it immediately after each caller" (except for the
aforementioned bug where we did too many rcu_read_unlock(), and in
find_alloc_undo() where we just got the rcu_read_lock() to correct for
the fact that sem_unlock would immediately drop it again).

We can (and should) clean things up further, but this fixes the bug with
the minimal amount of subtlety.

Reviewed-by: Davidlohr Bueso 
Cc: Rik van Riel 
Cc: Al Viro 
Signed-off-by: Linus Torvalds