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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 8 Dec 2009 12:48:24 -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, Alan Stern wrote:
> 
> >   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.
> 
> No, that's not needed.  Unlike reads, writes can't move in front of
> data or control dependencies.  Or so I've been lead to believe...

Sure they can. Control dependencies are trivial - it's called "branch 
prediction", and everybody does it, and data dependencies don't exist on 
many CPU architectures (even to the point of reading through a pointer 
that you loaded).

But yes, on x86, stores only move down. But that's an x86-specific thing.

[ Not that it's also not very common - write buffering is easy and matters 
  for performance, so any in-order implementation will generally do it. In 
  contrast, writes moving up doesn't really help peformance and is harder 
  to do, but can happen with a weakly ordered memory subsystem especially 
  if you have multi-way caches where some ways are busy and end up being 
  congested.

  So the _common_ case is definitely about delaying writes and doing reads 
  early if possible. But it's not necessarily at all guaranteed in 
  general. ]

> > That "wait_for_lock()" is equivalent to a 'read_lock()+read_unlock()'.
> 
> Not really.  It also corresponds to a 'write_lock()+write_unlock()' (in
> the suspend routine).  Are you claiming these two compound operations
> are equivalent?

They have separate semantics, and you just want to pick the one that suits 
you. Your counting lock doesn't have the "read_lock+read_unlock" version, 
it only has the write_lock/unlock one (ie it requires totally unlocked 
thing).

The point being, rwsem's can do everything your counting lock does. And 
they already exist. And they already know about all the subtleties of 
architecture-specific memory ordering etc.

				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/