linux-kernel - Re: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)

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: <alpine.LFD.2.00.0912081043280.3560@localhost.localdomain>
Date:	Tue, 8 Dec 2009 10:52:08 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alan Stern <stern@...land.harvard.edu>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Zhang Rui <rui.zhang@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	pm list <linux-pm@...ts.linux-foundation.org>
Subject: Re: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)

On Tue, 8 Dec 2009, Linus Torvalds wrote:
> 
> [ Hint: you need a smp_mb() *before* the atomic_dec() in wait-unlock, so 
>   that anybody else who sees the new value will be guaranteed to have seen 
>   anything else the unlocker did.
> 
>   You also need a smp_mb() in the wait_for_lock(), not a smp_rmb(). Can't 
>   allow writes to migrate up either.  'atomic_read()' does not imply any
>   barriers.
> 
>   But most architectures can optimize these things for their particular 
>   memory ordering model, and do so in their rwsem implementation. ]

Side note: if this was a real lock, you'd also needed an smp_wmb() in the 
'wait_lock()' path after the atomic_inc(), to make sure that others see 
the atomic lock was seen by other people before the suspend started. 

In your usage scenario, I don't think it would ever be noticeable, since 
the other users are always going to start running from the same thread 
that did the wait_lock(), so even if they run on other CPU's, we'll have 
scheduled _to_ those other CPU's and done enough memory ordering to 
guarantee that they will see the thing.

So it would be ok in this situation, simply because it acts as an 
initializer and never sees any real SMP issues.

But it's an example of how you now don't just depend on the locking 
primitives themselves doing the right thing, you end up depending very 
subtly on exactly how the lock is used.  The standard locks do have the 
same kind of issue for initializers, but we avoid it elsewhere because 
it's so risky.

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