linux-kernel - [PATCH 0/4] hard_smp_processor

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-next>] [day] [month] [year] [list]

Date:	Wed, 04 Apr 2007 17:51:07 +0900
From:	Fernando Luis Vázquez Cao 
	<fernando@....ntt.co.jp>
To:	akpm@...ux-foundation.org
Cc:	linux-kernel@...r.kernel.org, ak@...e.de, benh@...nel.crashing.org,
	davem@...emloft.net, ebiederm@...ssion.com,
	heiko.carstens@...ibm.com, horms@...ge.net.au,
	ink@...assic.park.msu.ru, jdike@...toit.com, paulus@...ba.org,
	rth@...ddle.net, schwidefsky@...ibm.com, takata@...ux-m32r.org,
	tony.luck@...el.com, vgoyal@...ibm.com
Subject: [PATCH 0/4] hard_smp_processor_id overhaul (v.2)

This new version (v.2) fixes generic arch i386 up build, has (hopefully)
clearer explanations, and does not break git bisect searches.
---
With the advent of kdump, the assumption that the boot CPU when running
an UP kernel is always the CPU with a particular hardware ID (often 0)
(usually referred to as BSP on some architectures) is not valid anymore.
The reason being that the dump capture kernel boots on the crashed CPU
(the CPU that invoked crash_kexec), which may be or may not be that
particular CPU.

As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
systems (see "linux/smp.h") is not correct.

This patch-set does the following:

1- Remove hardcoding of hard_smp_processor_id on UP systems (patch 1).

2- Move definition of hard_smp_processor_id for the UP case to
architecture specific code ("asm/smp.h") where it belongs, so that each
architecture can provide its own implementation (patch 1).

3- Ask the hardware when possible to obtain the hardware processor id on
i386 (patch 2), x86_64 (patch 3), and ia64 (patch 4), independently of
whether CONFIG_SMP is set or not.

I guess that something similar could be done for the rest of the
architectures, but since I am not an expert in all of them I am just
moving the definition of hard_smp_processor_id to "asm/smp.h" for those.
Of course, help from the respective maintainers to fill this gap would
be greatly appreciated.

The patches have been tested on i386, x86_64, and ia64.

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