linux-kernel - Re: PCI PM: Restore standard config registers of all devices early

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: <alpine.LFD.2.00.0902021635240.3247@localhost.localdomain>
Date:	Mon, 2 Feb 2009 16:44:22 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jesse.barnes@...el.com>,
	Andreas Schwab <schwab@...e.de>, Len Brown <lenb@...nel.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: PCI PM: Restore standard config registers of all devices early

On Tue, 3 Feb 2009, Benjamin Herrenschmidt wrote:
> 
> IE, you should have something to ensure, before you turn interrupts off,
> that nobody else is inside the AML interpreter. You already know there
> are no other CPUs, so it's just a matter of making sure no other process
> has scheduled while holding that mutex.
> 
> The easy way to do that is to do something like taking the mutex
> yourself and then setting a flag so that the intepreter stops trying to
> take it or release it itself, maybe just using the global system state.
> 
> Then release the mutex on resume.

Why do you think this improves on anything?

Basically, it turns the mutex into a non-entity - but if your whole 
argument is that it might as well be a non-entity because nobody else can 
take it anyway, then why not just leave it around?

IOW, if your argument boils down to "there can be no contention", then you 
might as well say "just use the mutex, it will never block".

So the only thing you really need is to just disable the _debugging_ code 
that mutexes have (if they get built with debugging in the first place). 

I can't find the bothersome code anyway: I do find

	DEBUG_LOCKS_WARN_ON(in_interrupt());

but that's just saying that you shouldn't be using mutexes from 
interrupts, not from irq-off segments. There's probably something I'm 
missing, like the preempt_check_resched() causing a schedule event with 
irq's disabled, and the "might_sleep()" thing. But the latter should 
already be disabled by the "system_state != SYSTEM_RUNNING" thing.

Oh, except we don't seem to have a SYSTEM_SUSPEND thing. Is that what 
people are complaining about?

Just do

	system_state = SYSTEM_SUSPEND;
	..
	system_state = SYSTEM_RUNNING;

around the irqs-off section in suspending if so.

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