user/sven/linux.git/init/do_mounts_initrd.c, branch v3.8

make sure that /linuxrc has std{in,out,err}

2013-01-19T18:29:54Z

Signed-off-by: Al Viro

don't bother with kernel_thread/kernel_execve for launching linuxrc

2012-10-12T01:40:30Z

exec_usermodehelper_fns() will do just fine... Signed-off-by: Al Viro

init: disable sparse checking of the mount.o source files

2012-06-01T00:49:27Z

The init/mount.o source files produce a number of sparse warnings of the type: warning: incorrect type in argument 1 (different address spaces) expected char [noderef] *dev_name got char *name This is due to the syscalls expecting some of the arguments to be user pointers but they are being passed as kernel pointers. This is harmless but adds a lot of noise to a sparse build. To limit the noise just disable the sparse checking in the relevant source files, but still display a warning so that the user knows this has been done. Since the sparse checking has been disabled we can also remove the __user __force casts that are scattered thru the source. Signed-off-by: H Hartley Sweeten Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

get rid of pointless includes of ext2_fs.h

2012-03-31T20:03:15Z

Signed-off-by: Al Viro

Make do_execve() take a const filename pointer

2010-08-18T01:07:43Z

Make do_execve() take a const filename pointer so that kernel_execve() compiles correctly on ARM: arch/arm/kernel/sys_arm.c:88: warning: passing argument 1 of 'do_execve' discards qualifiers from pointer target type This also requires the argv and envp arguments to be consted twice, once for the pointer array and once for the strings the array points to. This is because do_execve() passes a pointer to the filename (now const) to copy_strings_kernel(). A simpler alternative would be to cast the filename pointer in do_execve() when it's passed to copy_strings_kernel(). do_execve() may not change any of the strings it is passed as part of the argv or envp lists as they are some of them in .rodata, so marking these strings as const should be fine. Further kernel_execve() and sys_execve() need to be changed to match. This has been test built on x86_64, frv, arm and mips. Signed-off-by: David Howells Tested-by: Ralf Baechle Acked-by: Russell King Signed-off-by: Linus Torvalds

init: Open /dev/console from rootfs

2010-03-03T19:56:07Z

To avoid potential problems with an empty /dev open /dev/console from rootfs instead of waiting to mount our root filesystem and mounting it there. This effectively guarantees that there will be a device node, and it won't be on a filesystem that we will ever unmount, so there are no issues with leaving /dev/console open and pinning the filesystem. This is actually more effective than automatically mounting devtmpfs on /dev because it removes removes the occasionally problematic assumption that /dev/console exists from the boot code. With this patch I was able to throw busybox on my /boot partition (which has no /dev directory) and boot into userspace without problems. The only possible negative consequence I can think of is that someone out there deliberately used did not use a character device that is major 5 minor 2 for /dev/console. Does anyone know of a situation in which that could make sense? Signed-off-by: Eric W. Biederman Signed-off-by: Al Viro

Freezer: Fix s2disk resume from initrd

2007-11-21T03:22:42Z

Add appropriate freezer annotations to handle_initrd(), so that it's possible to resume from disk from an initrd. http://bugzilla.kernel.org/show_bug.cgi?id=9345 Signed-off-by: Rafael J. Wysocki Cc: Pavel Machek Cc: Nigel Cunningham Cc: Ingo Molnar Cc: Chris Friedhoff Signed-off-by: Len Brown

Fix failure to resume from initrds

2007-09-19T18:24:17Z

Commit 831441862956fffa17b9801db37e6ea1650b0f69 (Freezer: make kernel threads nonfreezable by default) breaks freezing when attempting to resume from an initrd, because the init (which is freezeable) spins while waiting for another thread to run /linuxrc, but doesn't check whether it has been told to enter the refrigerator. The original patch replaced a call to try_to_freeze() with a call to yield(). I believe a simple reversion is wrong because if !CONFIG_PM_SLEEP, try_to_freeze() is a noop. It should still yield. Signed-off-by: Nigel Cunningham Acked-by: Rafael J. Wysocki Acked-by: Pavel Machek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Freezer: make kernel threads nonfreezable by default

2007-07-17T17:23:02Z

Currently, the freezer treats all tasks as freezable, except for the kernel threads that explicitly set the PF_NOFREEZE flag for themselves. This approach is problematic, since it requires every kernel thread to either set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't care for the freezing of tasks at all. It seems better to only require the kernel threads that want to or need to be frozen to use some freezer-related code and to remove any freezer-related code from the other (nonfreezable) kernel threads, which is done in this patch. The patch causes all kernel threads to be nonfreezable by default (ie. to have PF_NOFREEZE set by default) and introduces the set_freezable() function that should be called by the freezable kernel threads in order to unset PF_NOFREEZE. It also makes all of the currently freezable kernel threads call set_freezable(), so it shouldn't cause any (intentional) change of behaviour to appear. Additionally, it updates documentation to describe the freezing of tasks more accurately. [akpm@linux-foundation.org: build fixes] Signed-off-by: Rafael J. Wysocki Acked-by: Nigel Cunningham Cc: Pavel Machek Cc: Oleg Nesterov Cc: Gautham R Shenoy Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

freezer: remove PF_NOFREEZE from handle_initrd

2007-05-07T19:12:59Z

Make handle_initrd() call try_to_freeze() in a suitable place instead of setting PF_NOFREEZE for the current task. Signed-off-by: Rafael J. Wysocki Acked-by: Nigel Cunningham Acked-by: Pavel Machek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds