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.0912071249390.3560@localhost.localdomain>
Date:	Mon, 7 Dec 2009 12:56:00 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Zhang Rui <rui.zhang@...el.com>,
	Alan Stern <stern@...land.harvard.edu>,
	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: [GIT PULL] PM updates for 2.6.33



On Mon, 7 Dec 2009, Rafael J. Wysocki wrote:
> 
> So I guess the only thing we need at the core level is to call
> async_synchronize_full() after every stage of suspend/resume, right?

Yes and no.

Yes in the sense that _if_ everybody always uses "async_schedule()" (or 
whatever the call is named - I've really only written pseudo-code and 
haven't even tried to look up the details), then the only thing you need 
to do is async_synchronize_full().

But one of the nice things about using just the trivial rwlock model and 
letting any async users just depend on that is that we could easily just 
depend entirely on those device locks, and allow drivers to do async 
shutdowns other ways too.

For example, I could imagine some driver just doing an async suspend (or 
resume) that gets completed in an interrupt context, rather than being 
done by 'async_schedule()' at all. 

So in many ways it's nicer to serialize by just doing

	serialize_all_PM_events()
	{
		for_each_device() {
			down_write(dev->lock);
			up_write(dev->lock);
		}
	}

rather than depend on something like async_synchronize_full() that 
obviously waits for all async events, but doesn't have the capability to 
wait for any other event that some random driver might be using.

[ That "down+up" is kind of stupid, but I don't think we have a "wait for 
  unlocked" rwsem operation. We could add one, and it would be cheaper for 
  the case where the device never did anything async at all, and didn't 
  really need to dirty that cacheline by doing that write lock/unlock 
  pair. ]

But that really isn't a big deal. I think it would be perfectly ok to also 
just say "if you do any async PM, you need to use 'async_schedule()' 
because that's all we're going to wait for". It's probably perfectly fine.

			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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ