Re: [PATCH -mm -next] ipc,sem: fix lockdep false positive

[Michel Lespinasse <walken@google.com>]

On Tue, Mar 26, 2013 at 6:19 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, 2013-03-25 at 14:42 -0700, Michel Lespinasse wrote:
>> depth nesting here...
>> Adding Peter & Ingo for advice about how to proceed
>
>> > +++ b/ipc/sem.c
>> > @@ -357,7 +357,7 @@ static inline int sem_lock(struct sem_array
>> *sma, struct sembuf *sops,
>> >                 spin_lock(&sma->sem_perm.lock);
>> >                 for (i = 0; i < sma->sem_nsems; i++) {
>> >                         struct sem *sem = sma->sem_base + i;
>> > -                       spin_lock(&sem->lock);
>> > +                       spin_lock_nested(&sem->lock,
>> SINGLE_DEPTH_NESTING);
>> >                 }
>> >                 locknum = -1;
>> >         }
>
> Right, so as walken said, this isn't going to work right.
>
> I need a little more information as I've not really paid much attention
> to this stuff. Firstly, is there a limit to sem_nsems or is this a
> random user specified number? Secondly do we care about lock order at
> all, or is array order the only order that counts?

sem_nsems is user provided as the array size in some semget system
call. It's the size of an ipc semaphore array.

complex semop operations take the array's lock plus every semaphore
locks; simple semop operations (operating on a single semaphore) only
take that one semaphore's lock.

AFAIK no operations take more than one semaphore lock except for the
case where they are all taken (in which case the array's lock is also
taken). Ideally it'd be best to have lockdep verify that this usage
pattern is respected, though.

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.