Re: 4.10rc1 ipc locking bug.

[Mike Galbraith <umgwanakikbuti@gmail.com>]

On Thu, 2016-12-29 at 21:47 -0500, Dave Jones wrote:
> This is a new one for me..
> 
> =====================================
> [ BUG: bad unlock balance detected! ]
> 4.10.0-rc1-think+ #8 Not tainted
> -------------------------------------
> trinity-c47/31138 is trying to release lock (
> [CONT START] &(&new->lock)->rlock
> [CONT START] ) at:
> [<ffffffff8136627f>] SYSC_semtimedop+0x97f/0x11d0
> but there are no more locks to release!

This?

From:   Manfred Spraul <manfred@colorfullife.com>
Subject: [PATCH] ipc/sem.c: fix semop()/semop() locking failure
Date:   Sun, 18 Dec 2016 19:38:45 +0100

Based on the syzcaller test case from dvyukov:
https://gist.githubusercontent.com/dvyukov/d0e5efefe4d7d6daed829f5c3ca26a40/raw/08d0a261fe3c987bed04fbf267e08ba04bd533ea/gistfile1.txt

The slow (i.e.: failure to acquire) syscall exit from semtimedop()
incorrectly assumed that the the same lock is acquired as it was
at the initial syscall entry.

This is wrong:
- thread A: single semop semop(), sleeps
- thread B: multi semop semop(), sleeps
- thread A: woken up by signal/timeout

With this sequence, the initial sem_lock() call locks the
per-semaphore spinlock, the call at the syscall return locks
the global spinlock.

The fix is trivial: Use the return value from sem_lock.

Reported-by: dvyukov@google.com
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Fixes: 370b262c896e ("ipc/sem: avoid idr tree lookup for interrupted semop")
Cc: dave@stgolabs.net
---
 ipc/sem.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1977,7 +1977,7 @@ SYSCALL_DEFINE4(semtimedop, int, semid,
 		}
 
 		rcu_read_lock();
-		sem_lock(sma, sops, nsops);
+		locknum = sem_lock(sma, sops, nsops);
 
 		if (!ipc_valid_object(&sma->sem_perm))
 			goto out_unlock_free;