2.6.23: x86_64 oops caused by hotplug running before vdso initialized

2.6.23: x86_64 oops caused by hotplug running before vdso initialized

[Chuck Ebbert]

pages is NULL here, implying vma->vm_private_data was NULL. This is apparently
because init_vdso_vars() is __initcall and runs after the rootfs gets populated.
An experimental initrd containing an /sbin/hotplug binary caused this. Normally
we don't have that file in the initrd. Should vdso init be done earlier to prevent
this problem?


static struct page *special_mapping_nopage(struct vm_area_struct *vma,
                                           unsigned long address, int *type)
{
        struct page **pages;

        BUG_ON(address < vma->vm_start || address >= vma->vm_end);

        address -= vma->vm_start;
        for (pages = vma->vm_private_data; address > 0 && *pages; ++pages)
                address -= PAGE_SIZE;

===>    if (*pages) {
                struct page *page = *pages;
                get_page(page);
                return page;
        }

        return NOPAGE_SIGBUS;
}


Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: 
 [<ffffffff810838e9>] special_mapping_nopage+0x3c/0x63
PGD 7f568067 PUD 7f571067 PMD 0 
Oops: 0000 [1] SMP 
CPU 1 
Modules linked in:
Pid: 219, comm: hotplug Not tainted 2.6.23.9-77.fc8 #1
RIP: 0010:[<ffffffff810838e9>]  [<ffffffff810838e9>]
special_mapping_nopage+0x3c/0x63
RSP: 0000:ffff810037f41d50  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff81007f4faff8 RCX: ffffffff8137e240
RDX: 0000000000000000 RSI: 00007fffeebfe000 RDI: ffff81007f4d8420
RBP: ffff81007f4d8420 R08: 00000007fffeebfe R09: 0000000000000000
R10: 000000006ffffdff R11: 000000006ffffe34 R12: 0000000000000000
R13: ffff81007f4da000 R14: 00007fffeebfe020 R15: ffff81007f4d8420
FS:  0000000000000000(0000) GS:ffff810002c3f300(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 000000007f4ae000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process hotplug (pid: 219, threadinfo ffff810037f40000, task ffff81007f4bc820)
Stack:  ffffffff8107e42c 00000010000284d0 ffff81007f569ba8 00ff81000000f2a8
 0000000000000000 ffff810000000000 00000007fffeebfe 00007fffeebfe000
 0000000000000000 0000000000000004 0000000000400040 ffff81007f4d80b0
Call Trace:
 [<ffffffff8107e42c>] __do_fault+0x89/0x489
 [<ffffffff81081bd7>] handle_mm_fault+0x4ed/0x976
 [<ffffffff81084a46>] vma_link+0x70/0xfd
 [<ffffffff8125f037>] do_page_fault+0x45b/0x7e4
 [<ffffffff810115ef>] arch_get_unmapped_area+0x184/0x1f9
 [<ffffffff8108598c>] do_mmap_pgoff+0x2eb/0x350
 [<ffffffff81120cec>] __up_write+0x27/0xf3
 [<ffffffff8125d51d>] error_exit+0x0/0x84

Re: 2.6.23: x86_64 oops caused by hotplug running before vdso initialized

[Andi Kleen]

On Thursday 06 December 2007 20:44:46 Chuck Ebbert wrote:
> pages is NULL here, implying vma->vm_private_data was NULL. This is apparently
> because init_vdso_vars() is __initcall and runs after the rootfs gets populated.
> An experimental initrd containing an /sbin/hotplug binary caused this. Normally
> we don't have that file in the initrd. Should vdso init be done earlier to prevent
> this problem?

We've often had bugs like this. Sure it could be fixed here, but then
the next bug would crop up again later I bet.

It would be better to move the first user  space code execution later I think. 
I guess the hotplug events could be delayed or initrd just mounted later.

Running any user space before __initcall() has finished is just wrong.

-Andi

Re: 2.6.23: x86_64 oops caused by hotplug running before vdso initialized

[Chuck Ebbert]

On 12/06/2007 03:51 PM, Andi Kleen wrote:
> On Thursday 06 December 2007 20:44:46 Chuck Ebbert wrote:
>> pages is NULL here, implying vma->vm_private_data was NULL. This is apparently
>> because init_vdso_vars() is __initcall and runs after the rootfs gets populated.
>> An experimental initrd containing an /sbin/hotplug binary caused this. Normally
>> we don't have that file in the initrd. Should vdso init be done earlier to prevent
>> this problem?
> 
> We've often had bugs like this. Sure it could be fixed here, but then
> the next bug would crop up again later I bet.
> 
> It would be better to move the first user  space code execution later I think. 
> I guess the hotplug events could be delayed or initrd just mounted later.

It was suggested that I just make the uevent_helper an empty string,
since that's what our (Fedora) initrd does anyway when it starts.
 
> Running any user space before __initcall() has finished is just wrong.

I thought that was a feature, so some early userspace code could help bring
up devices.