user/sven/linux.git/init/main.c, branch v3.2.41

efi: Make 'efi_enabled' a function to query EFI facilities

2013-02-06T04:33:50Z

commit 83e68189745ad931c2afd45d8ee3303929233e7f upstream. Originally 'efi_enabled' indicated whether a kernel was booted from EFI firmware. Over time its semantics have changed, and it now indicates whether or not we are booted on an EFI machine with bit-native firmware, e.g. 64-bit kernel with 64-bit firmware. The immediate motivation for this patch is the bug report at, https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557 which details how running a platform driver on an EFI machine that is designed to run under BIOS can cause the machine to become bricked. Also, the following report, https://bugzilla.kernel.org/show_bug.cgi?id=47121 details how running said driver can also cause Machine Check Exceptions. Drivers need a new means of detecting whether they're running on an EFI machine, as sadly the expression, if (!efi_enabled) hasn't been a sufficient condition for quite some time. Users actually want to query 'efi_enabled' for different reasons - what they really want access to is the list of available EFI facilities. For instance, the x86 reboot code needs to know whether it can invoke the ResetSystem() function provided by the EFI runtime services, while the ACPI OSL code wants to know whether the EFI config tables were mapped successfully. There are also checks in some of the platform driver code to simply see if they're running on an EFI machine (which would make it a bad idea to do BIOS-y things). This patch is a prereq for the samsung-laptop fix patch. Cc: David Airlie Cc: Corentin Chary Cc: Matthew Garrett Cc: Dave Jiang Cc: Olof Johansson Cc: Peter Jones Cc: Colin Ian King Cc: Steve Langasek Cc: Tony Luck Cc: Konrad Rzeszutek Wilk Cc: Rafael J. Wysocki Signed-off-by: Matt Fleming Signed-off-by: H. Peter Anvin [bwh: Backported to 3.2: - Adjust context (a lot) - Add efi_is_native() function from commit 5189c2a7c776 ('x86: efi: Turn off efi_enabled after setup on mixed fw/kernel') - Make efi_init() bail out when booted non-native, as it would previously not be called in this case - Drop inapplicable changes to start_kernel()] Signed-off-by: Ben Hutchings

Fix blocking allocations called very early during bootup

2012-05-30T23:43:29Z

commit 31a67102f4762df5544bc2dfb34a931233d2a5b2 upstream. During early boot, when the scheduler hasn't really been fully set up, we really can't do blocking allocations because with certain (dubious) configurations the "might_resched()" calls can actually result in scheduling events. We could just make such users always use GFP_ATOMIC, but quite often the code that does the allocation isn't really aware of the fact that the scheduler isn't up yet, and forcing that kind of random knowledge on the initialization code is just annoying and not good for anybody. And we actually have a the 'gfp_allowed_mask' exactly for this reason: it's just that the kernel init sequence happens to set it to allow blocking allocations much too early. So move the 'gfp_allowed_mask' initialization from 'start_kernel()' (which is some of the earliest init code, and runs with preemption disabled for good reasons) into 'kernel_init()'. kernel_init() is run in the newly created thread that will become the 'init' process, as opposed to the early startup code that runs within the context of what will be the first idle thread. So by the time we reach 'kernel_init()', we know that the scheduler must be at least limping along, because we've already scheduled from the idle thread into the init thread. Reported-by: Steven Rostedt Cc: David Rientjes Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings

Merge branch 'upstream/jump-label-noearly' of git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen

2011-11-07T04:20:46Z

* 'upstream/jump-label-noearly' of git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen: jump-label: initialize jump-label subsystem much earlier x86/jump_label: add arch_jump_label_transform_static() s390/jump-label: add arch_jump_label_transform_static() jump_label: add arch_jump_label_transform_static() to optimise non-live code updates sparc/jump_label: drop arch_jump_label_text_poke_early() x86/jump_label: drop arch_jump_label_text_poke_early() jump_label: if a key has already been initialized, don't nop it out stop_machine: make stop_machine safe and efficient to call early jump_label: use proper atomic_t initializer Conflicts: - arch/x86/kernel/jump_label.c Added __init_or_module to arch_jump_label_text_poke_early vs removal of that function entirely - kernel/stop_machine.c same patch ("stop_machine: make stop_machine safe and efficient to call early") merged twice, with whitespace fix in one version

params: make dashes and underscores in parameter names truly equal

2011-10-26T02:40:39Z

The user may use "foo-bar" for a kernel parameter defined as "foo_bar". Make sure it works the other way around too. Apply the equality of dashes and underscores on early_params and __setup params as well. The example given in Documentation/kernel-parameters.txt indicates that this is the intended behaviour. With the patch the kernel accepts "log-buf-len=1M" as expected. https://bugzilla.redhat.com/show_bug.cgi?id=744545 Signed-off-by: Michal Schmidt Signed-off-by: Rusty Russell (neatened implementations)

jump-label: initialize jump-label subsystem much earlier

2011-10-25T18:55:15Z

Initialize jump_labels much, much earlier, so they're available for use during system setup. Signed-off-by: Jeremy Fitzhardinge Acked-by: Peter Zijlstra

bootup: move 'usermodehelper_enable()' a little earlier

2011-09-30T02:21:01Z

Commit d5767c53535a ("bootup: move 'usermodehelper_enable()' to the end of do_basic_setup()") moved 'usermodehelper_enable()' to end of do_basic_setup() to after the initcalls. But then I get failed to let uvesafb work on my computer, and lose the splash boot. So maybe we could start usermodehelper_enable a little early to make some task work that need eary init with the help of user mode. [ I would *really* prefer that initcalls not call into user space - even the real 'init' hasn't been execve'd yet, after all! But for uvesafb it really does look like we don't have much choice. I considered doing this when we mount the root filesystem, but depending on config options that is in multiple places. We could do the usermode helper enable as a rootfs_initcall().. So I'm just using wang yanqing's trivial patch. It's not wonderful, but it's simple and should work. We should revisit this some day, though. - Linus ] Signed-off-by: Linus Torvalds

bootup: move 'usermodehelper_enable()' to the end of do_basic_setup()

2011-09-28T17:23:44Z

Doing it just before starting to call into cpu_idle() made a sick kind of sense only because the original bug we fixed (see commit 288d5abec831: "Boot up with usermodehelper disabled") was about problems with some scheduler data structures not being initialized, and they had better be initialized at that point. But it really didn't make any other conceptual sense, and doing it after the initial "schedule()" call for the idle thread actually opened up a race: what if the main initialization thread did everything without needing to sleep, and got all the way into user land too? Without actually having scheduled back to the idle thread? Now, in normal circumstances that doesn't ever happen, but it looks like Richard Cochran triggered exactly that on his ARM IXP4xx machines: "I have some ARM IXP4xx based machines that use the two on chip MAC ports (aka NPEs). The NPE needs a firmware in order to function. Ever since the following commit [that 288d5abec831 one], it is no longer possible to bring up the interfaces during the init scripts." with a call trace showing an ioctl coming from user space. Richard says: "The init is busybox, and the startup script does mount, syslogd, and then ifup, so that all can go by quickly." The fix is to move the usermodehelper_enable() into the main 'init' thread, and just put it after we've done all our initcalls. By then, everything really should be up, but we've obviously not actually started the user-mode portion of init yet. Reported-and-tested-by: Richard Cochran Signed-off-by: Linus Torvalds

init: carefully handle loglevel option on kernel cmdline.

2011-09-21T20:18:52Z

When a malformed loglevel value (for example "${abc}") is passed on the kernel cmdline, the loglevel itself is being set to 0. That then suppresses all following messages, including all the errors and crashes caused by other malformed cmdline options. This could make debugging process quite tricky. This patch leaves the previous value of loglevel if the new value is incorrect and reports an error code in this case. Signed-off-by: Alexander Sverdlin Signed-off-by: Linus Torvalds

Boot up with usermodehelper disabled

2011-08-04T08:03:29Z

The core device layer sends tons of uevent notifications for each device it finds, and if the kernel has been built with a non-empty CONFIG_UEVENT_HELPER_PATH that will make us try to execute the usermode helper binary for all these events very early in the boot. Not only won't the root filesystem even be mounted at that point, we literally won't have necessarily even initialized all the process handling data structures at that point, which causes no end of silly problems even when the usermode helper doesn't actually succeed in executing. So just use our existing infrastructure to disable the usermodehelpers to make the kernel start out with them disabled. We enable them when we've at least initialized stuff a bit. Problems related to an uninitialized init_ipc_ns.ids[IPC_SHM_IDS].rw_mutex reported by various people. Reported-by: Manuel Lauss Reported-by: Richard Weinberger Reported-by: Marc Zyngier Acked-by: Kay Sievers Cc: Andrew Morton Cc: Vasiliy Kulikov Cc: Greg KH Signed-off-by: Linus Torvalds

tmpfs: miscellaneous trivial cleanups

2011-08-04T00:25:23Z

While it's at its least, make a number of boring nitpicky cleanups to shmem.c, mostly for consistency of variable naming. Things like "swap" instead of "entry", "pgoff_t index" instead of "unsigned long idx". And since everything else here is prefixed "shmem_", better change init_tmpfs() to shmem_init(). Signed-off-by: Hugh Dickins Acked-by: Rik van Riel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds