linux-kernel - Re: [RFC][PATCH 2/2] PM: Rework handling of interrupts during suspend-resume

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: <m17i3ha4nk.fsf@fess.ebiederm.org>
Date:	Mon, 23 Feb 2009 01:22:55 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Len Brown <lenb@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC][PATCH 2/2] PM: Rework handling of interrupts during suspend-resume

Ingo Molnar <mingo@...e.hu> writes:

> I think this aspect has been well-understood during the 
> discussion of this topic and it's just a slightly misleading 
> changelog.

As I was a member of that discussion I did not see that.

It took me several passes through the patches to realize
the goal is to allow drivers to be able to sleep while they
are in their late pm shutdown routines.

Why we want this I don't know.  But it seems simple enough
to implement, and it makes it harder to get the late pm
suspend routines wrong, which is always good.

> The new suspend code does not rely on truly disabling IRQs on 
> the low level. The purpose is to not get IRQs to drivers - which 
> might crash/hang/race/misbehave.

Reasonable.  I expect one of the problems with drivers getting it
wrong is that the interface is too complex for mortal humans to
understand.

> Still, it might make sense to not just use the ->disable 
> sequence but primarily the ->shutdown irqchip method (when it's 
> available in the irqchip).

Disable seems fine to me.  This is interesting in the context
of all of the irqs that will when masked show up somewhere
else (think boot interrupts).

> While we obviously cannot turn off the PIC that delivers timer 
> IRQs at this stage - there's no theoretical reason why the 
> suspend sequence couldnt power down some secondary PICs as well 
> - in some arch code, or maybe even in the generic driver suspend 
> sequence if the device tree is structured carefully enough so 
> that the PIC gets turned off last.

If the point is simply to prevent deliver of irqs to the drivers
I don't see the point of anything more than what the patch does
now.

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