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

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

Message-ID: <20100601073548.5ed65352@schatten.dmk.lab>
Date:	Tue, 1 Jun 2010 07:35:48 +0200
From:	Florian Mickler <florian@...kler.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Neil Brown <neilb@...e.de>, "Rafael J. Wysocki" <rjw@...k.pl>,
	Alan Stern <stern@...land.harvard.edu>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	Arve Hjønnevåg <arve@...roid.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>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Tue, 1 Jun 2010 12:20:12 +1000
Neil Brown <neilb@...e.de> wrote:

> On Tue, 1 Jun 2010 03:49:37 +0200 (CEST)
> Thomas Gleixner <tglx@...utronix.de> wrote:

> > If "suspend" is another deep idle state and the hardware is sane,
> > there is no race at all - assumed that the driver/platform developer
> > got it right. It's not rocket science to transition from "normal" irq
> > delivery to wakeup based delivery raceless (except for PC style x86
> > hardware of today)

> > If "suspend" is the thing we are used to via /sys/power/state then the
> > race will persist forever except for the suspend blocker workaround,
> > which we can express in QoS terms as well w/o adding another suspend
> > related user space API.

Can you explain the difference between the /sys/power/state thing? Is
it the reprogramming of wake-sources as mentioned by Raffael?

In an idle based suspend I assume there would be no new wake-sources
on suspending.

> I'm not interested in adding another user-space API if it can possibly be
> avoided, and I think it can.  But that is a later step in the process.
> 
> I think you have acknowledged that there is a race with suspend - thanks.
> Next step was "can it be closed".
> You seem to suggest that it can, but you describe it as a "work around"
> rather than a "bug fix"...

Well as far as I get it, the workaround is to not suspend in sitations
where a race is likely to occur. (I.e. block suspend)

> 
> Do you agree that the race is a "bug", and therefore it is appropriate to
> "fix" it assuming an acceptable fix can be found (which I think it can)?
> 
> If you agree that it is appropriate for try to fix this bug, then the next
> step would be to get the Android devs to agree that a fix could - in
> principle - address the need for which they created suspend-blockers.
> Arve: can you confirm that?
> 
> Then, with a clear and agreed goal, we can look at possible fixes.
> 
> Thanks,
> NeilBrown
> 
> > 
> > Thanks,
> > 
> > 	tglx

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/