linux-kernel - Re: [PATCH] spinlock: clarify doc for raw_spin_unlock

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: <55411609.90507@colorfullife.com>
Date:	Wed, 29 Apr 2015 19:34:01 +0200
From:	Manfred Spraul <manfred@...orfullife.com>
To:	Chris Metcalf <cmetcalf@...hip.com>,
	Peter Zijlstra <peterz@...radead.org>
CC:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Kirill Tkhai <ktkhai@...allels.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH] spinlock: clarify doc for raw_spin_unlock_wait()

On 04/28/2015 06:44 PM, Chris Metcalf wrote:
> The intent of the function is to wait for the current locker.
> Thus, we don't have to worry about potential later lockers,
> but we also have to ensure that the arch implementation
> doesn't return a false positive for the current locker.
>
> Signed-off-by: Chris Metcalf <cmetcalf@...hip.com>
sysvsem depends on this definition, i.e. a false early return can cause 
a corrupted semaphore state.

Acked-by: Manfred Spraul <manfred@...orfullife.com>
> ---
> On 04/28/2015 12:24 PM, Peter Zijlstra wrote:
>> I think it must not return before the lock holder that is current at the
>> time of calling releases. Anything thereafter is indeed fair game as per
>> your logic above.
> Great, that seems like a workable definition.  How does this modified
> language seem?  With this definition I can actually modify the
> implementation of tile's arch_raw_spin_unlock_wait() to just read
> current_ticket once and just wait until it changes (assuming the
> lock is, in fact, locked).
>
> Not sure whose tree this should go through; any takers?
>
>   include/linux/spinlock.h | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
> index 3e18379dfa6f..36de5fc86647 100644
> --- a/include/linux/spinlock.h
> +++ b/include/linux/spinlock.h
> @@ -141,7 +141,8 @@ do {								\
>   #endif
>   
>   /**
> - * raw_spin_unlock_wait - wait until the spinlock gets unlocked
> + * raw_spin_unlock_wait - wait until the lock holder that is current at the
> + * time of calling releases the lock (or return immediately if unlocked).
>    * @lock: the spinlock in question.
>    */
>   #define raw_spin_unlock_wait(lock)	arch_spin_unlock_wait(&(lock)->raw_lock)

--
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/