linux-kernel - Re: [linux-pm] [RFC][PATCH][1/8] PM: Rework handling of interrupts during suspend-resume (rev. 5)

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: <Pine.LNX.4.44L0.0903081629010.9313-100000@netrider.rowland.org>
Date:	Sun, 8 Mar 2009 16:40:16 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Ingo Molnar <mingo@...e.hu>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Arve  Hjønnevåg <arve@...roid.com>
Subject: Re: [linux-pm] [RFC][PATCH][1/8] PM: Rework handling of interrupts
 during suspend-resume (rev. 5)

On Sun, 8 Mar 2009, Linus Torvalds wrote:

> On Sat, 7 Mar 2009, Alan Stern wrote:
> > 
> > You didn't answer my question.  Why bother to distinguish between 
> > "wake-up" interrupts and non-"wake-up" interrupts?
> > 
> > In other words, why not simply abort the suspend if IRQ_PENDING is set
> > for _any_ interrupt during sysdev_suspend()?
> 
> .. because some drivers might not actually shut down the hardware until 
> they get to "suspend_late"? If even then, for that matter - a driver may 
> simply not care, knowing that the hardware will be powered off, and will 
> be re-initialized at resume.
> 
> The thinking that you have to shut your hardware down at "->suspend()" 
> time is a _disease_. There are literally classes of hardware out there 
> where that would be an outright _bug_, like for a PCI bridge device. For 
> many devices, "suspend()" has to be the phase where you shut down the 
> _external_ stuff (eg for a disk controller, it's when you'd flush and stop 
> your disks), but the controller itself may well be alive until later.

Yes, certainly.  I agree completely.

But there is a difference between shutting down the hardware and merely
preventing it from generating interrupt requests.  If a device remains
capable of generating IRQs after its driver's suspend method has run,
the driver runs the risk of having its handler called at a time when it
isn't prepared to cope correctly.  Of course, this will depend on the
details of how the driver is written.

There have been examples in the past of devices that, for one reason or
another, _did_ generate IRQs at inconvenient times.  The hardware or
the BIOS may have done improper initialization, for example.  On a
shared IRQ this led to interrupt storms.  IIRC, the solution was to add
a PCI quirk routine to disable IRQ generation at an early stage.  
Didn't e100 have this problem?

Alan Stern

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