linux-kernel - Re: [PATCH 11/14] x86: Populate cpu_enabled

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]

Date:	Fri, 18 Jul 2008 17:06:42 -0600
From:	Alex Chiang <achiang@...com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-acpi@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 11/14] x86: Populate cpu_enabled_map

* H. Peter Anvin <hpa@...or.com>:
> Alex Chiang wrote:
>> Populate the cpu_enabled_map correctly.
>>
>> Note that this patch does not actually make any decisions based
>> on the contents of the map.
>>
>> However, as the map is presented via sysfs in:
>>
>> 	/sys/devices/system/cpu/
>>
>> It should be populated correctly.
>>
>> There will be a user-visible change under the above directory.
>> cpuN/ entries for firmware-disabled CPUs will now appear, whereas
>> before, they did not due to a check against ACPI_MADT_ENABLED.
>>
>> The cpuN/ entries will be empty, and the online file in the
>> above directory will reflect which CPUs are actually schedulable.
>>
>> Signed-off-by: Alex Chiang <achiang@...com>
>> Cc: Ingo Molnar <mingo@...hat.com>
>> Cc: Thomas Gleixner <tglx@...utronix.de>
>> Cc: H. Peter Anvin <hpa@...or.com>
>
> From an x86 standpoint this patchset seems reasonable to me.
>
> Acked-by: H. Peter Anvin <hpa@...or.com>

Thanks Peter. Let me try and rework the patchset according to
Russell's suggestion here:

	http://lkml.org/lkml/2008/7/18/467

That approach seems cleaner to me.

> Obviously, if the sematics of the operations don't make sense
> for other  architectures -- which I will leave up to the
> affected maintainers --  then that should be carefully
> considered if the generic operations can  be done better.

Russell's solution avoids the issue with the ability to #define
the check away for archs that don't care.

cheers,

/ac

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