linux-kernel - Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)

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: <200707280330.26991.lenb@kernel.org>
Date:	Sat, 28 Jul 2007 03:30:26 -0400
From:	Len Brown <lenb@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, david@...g.hm,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	Pavel Machek <pavel@....cz>
Subject: Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)

On Thursday 26 July 2007 16:55, Linus Torvalds wrote:

> Anyway, I think the ACPI problem really is as trivial as the following 
> three-liner removal fix. If the user doesn't want suspend, ACPI shouldn't 
> force it on him.
...
> -	# for sleep
> -	select HOTPLUG_CPU if X86 && SMP
> -	select SUSPEND_SMP if X86 && SMP

That three-liner will crash ACPI+SMP-HOTPLUG_CPU kernels on resume.
While cpu0 is in a known state when the power goes out,
without HOTPLUG_CPU the other cpus (and the memory they touch)
are in an indeterminate state.

Yes, we could invent a new mechanism to offline the other CPUS
before suspend and online them upon resume,
but that is what the more general HOTPLUG_CPU code does for us already.
Indeed, that is pretty much _all_ that HOTPLUG_CPU code does on X86 --
as we don't have any physical hotplug support today beneath
this the logical hotplug support -- you could call it CONFIG_CPU_OFFLINE_ONLINE...

> A nicer fix might be to also make some of the ACPI helper routines depend 
> on whether they are needed or not (which in turn will depend on whether 
> suspend support has been compiled into the kernel), but quite frankly, 
> that's secondary at least for me.
> 
> So if we have a few ACPI routines that will never get called (because we 
> don't even enable the interfaces that would *cause* them to be called), I 
> don't think that's a huge problem. It's a beauty wart, but nobody really 
> cares (and it's even something that we could get the compiler to optimize 
> away for us if we really cared).

Re: warts, I agree.
My question is why the HOTPLUG_CPU=y code is any different.
When I compile HOTPLUG_CPU out of an x86_64 kernel, the kernel shrinks
by only 18KB, which on a kernel that has ACPI+SMP doesn't seem
like such a big wart.

Yes, now that you brought it up, I think it would be just dandy if
HOTPLUG_CPU simply got folded into SMP -- for I see little to no benefit
to having it as its own config option.

But on the assumption that you are not swayed (when was the last time you were?)
and you still feel strongly we should be able to exclude ACPI_SLEEP and HOTPLUG_CPU
from ACPI+SMP kernels, I'll send you a patch do to that properly.
It will largely restores things to how we had them in 2.6.22.
It looks like a step backwards to me, but you may see it differently.

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