linux-kernel - [PATCH RFC 0/5] hard_smp_processor

lists.openwall.net		lists / announce john-users owl-users popa3d-users / xvendor oss-security / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4
Open Source and information security mailing list archives

This website is powered by Openwall GNU/*/Linux security-enhanced OS

[<prev] [next>] [thread-next>] [month] [year] [list]

Date:	Thu, 01 Mar 2007 16:16:13 +0900
From:	Fernando Luis Vázquez Cao 
	<fernando@....ntt.co.jp>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: [PATCH RFC 0/5] hard_smp_processor_id overhaul

With the advent of kdump, the assumption that the boot CPU when running
an UP kernel is always the CPU with a hardware ID of 0 (usually referred
to as BSP on some architectures) does not hold true anymore. The reason
being that the dump capture kernel boots on the crashed CPU (the CPU
that invoked crash_kexec).

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.

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

3- Move definition of hard_smp_processor_id for the UP case to asm/smp.h
on alpha, m32r, powerpc, s390, sparc, sparc64, and um architectures. I
guess that hardware features could be used to implement
hard_smp_processor_id even in the UP case, but since I am not an expert
in this architectures I just move the definition.

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/