linux-kernel - Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

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: <20100602210521.54b9cd9b@schatten.dmk.lab>
Date:	Wed, 2 Jun 2010 21:05:21 +0200
From:	Florian Mickler <florian@...kler.org>
To:	Neil Brown <neilb@...e.de>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alan Stern <stern@...land.harvard.edu>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"Paul@...p1.linux-foundation.org" <Paul@...p1.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	James Bottomley <James.Bottomley@...e.de>
Subject: Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] 
 Suspend block api (version 8)

On Wed, 2 Jun 2010 21:02:24 +1000
Neil Brown <neilb@...e.de> wrote:
> 
> And this decision (to block suspend) really needs to be made in the driver,
> not in userspace?

Well, it fits. The requirement is a direct consequence of the intimate
knowledge the driver has about the driven devices. 
Or if you get in an upper layer, the knowledge that the subsystem has
about it's requirements to function properly. Why would you separate it out?

If all your drivers specify their needed requirements, the pm-core (or
idle) has the maximum flexibility to implement any strategy and is
guaranteed a stable system as long as it honours the given requirements.
(That's the theory, of course.)

> 
> You could get those drivers to return EBUSY from PM_SUSPEND_PREPARE (which
> would need to be a configurable option), but then I guess you have no way to
> wait for the device to become non-busy.
> 
> If user-space really cannot tell if the driver is busy or not, then I would
> suggest that the driver is fairly poorly designed.

In general, userspace has no business knowing if the driver is busy or
not. It would need intimate knowledge about the driver to determine if
it is busy or not. That is what the kernel is all about, to hide that
knowledge from userspace and masking it with a one-fits-all-API.

> 
> It would seem then that a user-space requested suspend is not sufficient for
> your needs even if we remove the race window, as you have drivers that want
> to avoid suspend indefinitely, and that "need to avoid suspend" status is not
> visible from user-space.

Well, but the kernel-solution and the userspace solution should be
pretty independent. The tricky part here seems to be to have a
kernel-userspace-boundary that doesn't require a specific kernel
implementation and works. 

Could someone perhaps make a recap on what are the problems with the
API? I have no clear eye (experience?) for that (or so it seems).

> It is a pity that this extra requirement was not clear from your introduction
> to the "Opportunistic suspend support" patch.

I think that the main problem was that _all_ the requirements were
not communicated well.  That caused everybody to think that their
solution would be a better fit. You are not alone.

> If that be the case, I'll stop bothering you with suggestions that can never
> work.
> Thanks for your time,
> NeilBrown

Don't be frustrated. What should Arve be?  :)

Cheers,
Flo
--
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/