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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5151AFEC.1050304@surriel.com>
Date:	Tue, 26 Mar 2013 10:25:48 -0400
From:	Rik van Riel <riel@...riel.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Michel Lespinasse <walken@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	torvalds@...ux-foundation.org, davidlohr.bueso@...com,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	hhuang@...hat.com, jason.low2@...com, lwoodman@...hat.com,
	chegu_vinod@...com, Dave Jones <davej@...hat.com>,
	benisty.e@...il.com, Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH -mm -next] ipc,sem: fix lockdep false positive

On 03/26/2013 09:19 AM, Peter Zijlstra 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?

It is a user specified number, and we either lock only one
of the semaphore locks, or we lock all of them (in array
order, after taking the semaphore array lock).

-- 
All rights reversed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/