Bug 407931 - NULL pointer dereference: hotplug before vdso initialization during initrd
Summary: NULL pointer dereference: hotplug before vdso initialization during initrd
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-12-02 17:10 UTC by Warren Togami
Modified: 2009-01-09 05:23 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-01-09 05:23:48 UTC
Type: ---

Attachments (Terms of Use)

Description Warren Togami 2007-12-02 17:10:28 UTC
checking if image is initramfs... it is
Freeing initrd memory: 5693k freed
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 #1
RIP: 0010:[<ffffffff810838e9>]  [<ffffffff810838e9>]
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

Code: 48 8b 08 48 85 c9 74 1b 48 8b 01 48 89 ca 25 00 40 02 00 48 
RIP  [<ffffffff810838e9>] special_mapping_nopage+0x3c/0x63
 RSP <ffff810037f41d50>
CR2: 0000000000000000

I see many of these oops errors during bootup with my experimental mkinitrd.  I
probably introduced a bug in nash that is triggering this, but according to hpa
I am likely hitting an actual kernel bug.  The system *does* successfully boot
after many of these oopses.

What I don't understand is how it happens only after "Freeing initrd memory"?


Comment 1 Warren Togami 2007-12-03 01:58:16 UTC
SRPM and x86_64 build of mkinitrd that exposes this kernel bug.  If you are
running a different arch, simply rebuild the SRPM.  So far I only know it
happens on my x86_64 laptop, I haven't tested it on i386 yet.

You can follow instructions from here in order to safely use the above
experimental mkinitrd to expose this bug.  Note that the system DOES boot even
with the kernel oopses.  It *is* a bug in this experimental mkinitrd, but
according to hpa and riel this is a genuine kernel bug.

Here are more debug tips:
1) yum install busybox
Then mkinitrd will pull in busybox into the initrd so you have more utilities to
use while debugging from the initrd shell.
2) Remove "quiet" and add "verbose shell" to your kernel args.
This will display everything that is run as it happens, and drop to a shell
before it boots the system.  "busybox dmesg"

Comment 2 Warren Togami 2007-12-03 02:05:16 UTC
Another thing...
It isn't clear exactly where the kernel oops occurs or what initrd or nash is
doing at the time of the oops.  Because if you let it boot into the OS, then
subsequently use dmesg, then you see the oopses after "Freeing initrd memory". 
But if you use "shell" arg and drop into the shell before it boots your system,
you see the kernel oopses earlier during the initrd.  I am a bit confused by this.

Comment 3 Chuck Ebbert 2007-12-04 19:17:28 UTC
pages is NULL here, implying vma->vm_private_data was NULL:

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;
                return page;

        return NOPAGE_SIGBUS;

Comment 4 Chuck Ebbert 2007-12-05 23:46:53 UTC
Does booting with kernel option 'vdso=0' make any difference?

Comment 5 Warren Togami 2007-12-06 00:22:28 UTC
vdso=0 avoids this kernel oops!

Comment 6 Chuck Ebbert 2007-12-06 19:48:48 UTC
hotplug is apparently being run before the vdso is initialized.

Comment 7 Chuck Ebbert 2007-12-07 20:51:02 UTC
Workaround: don't put an executable called /sbin/hotplug in the initrd.

Comment 8 Bug Zapper 2008-11-26 08:47:09 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 9 Bug Zapper 2009-01-09 05:23:48 UTC
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.