After upgrading to vanilla kernel 2.6.31-rc8, my Ubuntu Karmic userspace cannot complete the boot sequence.
It gets to about this point in the sequence:
* Starting kernel event manager...
[ 17.416876] udev: starting version 146
* Loading hardware drivers...
[ 18.635354] i2c-adapter i2c-0: nForce2 SMBus adapter at 0x600
[ 18.635475] i2c-adapter i2c-1: nForce2 SMBus adapter at 0x700
[ 18.981817] sky2 eth0: enabling interface
[ 18.983599] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 19.393425] ACPI: PCI Interrupt Link [LACI] enabled at IRQ 22
[ 19.393502] Intel ICH 0000:00:0d.0: PCI INT A -> Link[LACI] -> GSI 22 (level, low) -> IRQ 22
[ 19.393627] Intel ICH 0000:00:0d.0: setting latency timer to 64
[ 19.706038] intel8x0_measure_ac97_clock: measured 50143 usecs (2464 samples)
[ 19.706103] intel8x0: clocking to 46887
[ 21.450250] sky2 eth0: Link is up at 1000 Mbps, full duplex, flow control both
[ 21.452066] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
At which point the boot process halts. I am not sure if it is a userspace bug or a kernel bug.
Bisected to this commit:
Author: Eric W. Biederman <email@example.com>
Date: Thu Aug 27 03:20:04 2009 -0700
inotify: Ensure we alwasy write the terminating NULL.
Before the rewrite copy_event_to_user always wrote a terqminating '\0'
byte to user space after the filename. Since the rewrite that
terminating byte was skipped if your filename is exactly a multiple of
So add one byte to name_size before we round up and use clear_user to
set userspace to zero like /dev/zero does instead of copying the
strange nul_inotify_event. I can't quite convince myself len_to_zero
will never exceed 16 and even if it doesn't clear_user should be more
efficient and a more accurate reflection of what the code is trying to
Signed-off-by: Eric W. Biederman <firstname.lastname@example.org>
Signed-off-by: Eric Paris <email@example.com>
Fixed by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=83cb10f0ef3c96162be92339ccf8c0c9c9f2d13e .