linux-kernel - Re: [linux-pm] s2ram: warn when interrupts should be disabled but are not

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: <200804132224.27792.david-b@pacbell.net>
Date:	Sun, 13 Apr 2008 22:24:27 -0700
From:	David Brownell <david-b@...bell.net>
To:	linux-pm@...ts.linux-foundation.org
Cc:	Pavel Machek <pavel@....cz>,
	kernel list <linux-kernel@...r.kernel.org>,
	Linux-pm mailing list <linux-pm@...ts.osdl.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Andrew Morton <akpm@...l.org>
Subject: Re: [linux-pm] s2ram: warn when interrupts should be disabled but are not

On Saturday 12 April 2008, Pavel Machek wrote:
> +                                       WARN_ON(!irqs_disabled());
>                                         ret = drv->suspend(sysdev, state);

Wouldn't it be better to assert the warning AFTER the
driver had a chance to screw it up?  (On the resume
side of things too.)

We know IRQs were disabled on entry to the loop.
If something went wrong it was some goofy driver.
Best warn about it ASAP instead of *maybe* getting
a warning before the next driver (if there is one).

And if you're concerned about such issues, I'd think
similar warnings would be done in suspend_late() and
resume_early() support...

- Dave

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