[PATCH] Fix /proc/fb oops after module removal - Kernel

This is a discussion on [PATCH] Fix /proc/fb oops after module removal - Kernel ; /proc/fb is not removed during rmmod. Steps to reproduce: modprobe fb rmmod fb ls /proc BUG: unable to handle kernel paging request at ffffffffa0094370 IP: [ ] proc_get_inode+0x101/0x130 PGD 203067 PUD 207063 PMD 17e758067 PTE 0 Oops: 0000 [1] SMP ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: [PATCH] Fix /proc/fb oops after module removal

  1. [PATCH] Fix /proc/fb oops after module removal

    /proc/fb is not removed during rmmod.

    Steps to reproduce:

    modprobe fb
    rmmod fb
    ls /proc

    BUG: unable to handle kernel paging request at ffffffffa0094370
    IP: [] proc_get_inode+0x101/0x130
    PGD 203067 PUD 207063 PMD 17e758067 PTE 0
    Oops: 0000 [1] SMP
    last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:05:02.0/resource
    CPU 1
    Modules linked in: nf_conntrack_irc xt_state iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables vfat fat usbhid ehci_hcd uhci_hcd usbcore sr_mod cdrom [last unloaded: fb]
    Pid: 21205, comm: ls Not tainted 2.6.25-rc8-mm2 #14
    RIP: 0010:[] [] proc_get_inode+0x101/0x130
    RSP: 0018:ffff81017c4bfc78 EFLAGS: 00010246
    RAX: 0000000000008000 RBX: ffff8101787f5470 RCX: 0000000048011ccc
    RDX: ffffffffa0094320 RSI: ffff810006ad43b0 RDI: ffff81017fc2cc00
    RBP: ffff81017e450300 R08: 0000000000000002 R09: ffff81017c5d1000
    R10: 0000000000000000 R11: 0000000000000246 R12: ffff81016b903a28
    R13: ffff81017f822020 R14: ffff81017c4bfd58 R15: ffff81017f822020
    FS: 00007f08e71696f0(0000) GS:ffff81017fc06480(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: ffffffffa0094370 CR3: 000000017e54a000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process ls (pid: 21205, threadinfo ffff81017c4be000, task ffff81017de48770)
    Stack: ffff81017c5d1000 00000000ffffffea ffff81017e450300 ffffffff802bdd1e
    ffff81017f802258 ffff81017c4bfe48 ffff81016b903a28 ffff81017f822020
    ffff81017c4bfd48 ffffffff802b9ba0 ffff81016b903a28 ffff81017f802258
    Call Trace:
    [] ? proc_lookup_de+0x8e/0x100
    [] ? proc_root_lookup+0x20/0x60
    [] ? do_lookup+0x1b7/0x210
    [] ? __link_path_walk+0x53d/0x7f0
    [] ? mntput_no_expire+0x28/0x130
    [] ? path_walk+0x5a/0xc0
    [] ? do_path_lookup+0x83/0x1c0
    [] ? getname+0xe5/0x210
    [] ? __user_walk_fd+0x4b/0x80
    [] ? vfs_lstat_fd+0x2c/0x70
    [] ? filldir+0xae/0xf0
    [] ? de_put+0x9/0x50
    [] ? mnt_want_write+0x2d/0x80
    [] ? touch_atime+0x1f/0x170
    [] ? proc_root_readdir+0x7d/0xa0
    [] ? sys_newlstat+0x27/0x50
    [] ? vfs_readdir+0x9b/0xd0
    [] ? sys_getdents+0xce/0xe0
    [] ? system_call_after_swapgs+0x7b/0x80

    Code: b7 83 b2 00 00 00 25 00 f0 00 00 3d 00 80 00 00 74 19 48 89 93 f0 00 00 00 48 89 df e8 39 9a fd ff 48 89 d8 48 83 c4 08 5b 5d c3 <48> 83 7a 50 00 48 c7 c0 60 16 45 80 48 c7 c2 40 17 45 80 48 0f
    RIP [] proc_get_inode+0x101/0x130
    RSP
    CR2: ffffffffa0094370
    ---[ end trace c71hiarjan8ab739 ]---

    Signed-off-by: Alexey Dobriyan
    ---

    drivers/video/fbmem.c | 1 +
    1 file changed, 1 insertion(+)

    --- a/drivers/video/fbmem.c
    +++ b/drivers/video/fbmem.c
    @@ -1551,6 +1576,7 @@ module_init(fbmem_init);
    static void __exit
    fbmem_exit(void)
    {
    + remove_proc_entry("fb", NULL);
    class_destroy(fb_class);
    unregister_chrdev(FB_MAJOR, "fb");
    }

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH] Fix /proc/fb oops after module removal

    On Sun, 13 Apr 2008 01:10:29 +0400 Alexey Dobriyan wrote:

    > /proc/fb is not removed during rmmod.
    >
    > Steps to reproduce:
    >
    > modprobe fb
    > rmmod fb
    > ls /proc
    >
    > BUG: unable to handle kernel paging request at ffffffffa0094370
    > IP: [] proc_get_inode+0x101/0x130
    > PGD 203067 PUD 207063 PMD 17e758067 PTE 0
    > Oops: 0000 [1] SMP
    > last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:05:02.0/resource
    > CPU 1
    > Modules linked in: nf_conntrack_irc xt_state iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables vfat fat usbhid ehci_hcd uhci_hcd usbcore sr_mod cdrom [last unloaded: fb]
    > Pid: 21205, comm: ls Not tainted 2.6.25-rc8-mm2 #14
    > RIP: 0010:[] [] proc_get_inode+0x101/0x130
    > RSP: 0018:ffff81017c4bfc78 EFLAGS: 00010246
    > RAX: 0000000000008000 RBX: ffff8101787f5470 RCX: 0000000048011ccc
    > RDX: ffffffffa0094320 RSI: ffff810006ad43b0 RDI: ffff81017fc2cc00
    > RBP: ffff81017e450300 R08: 0000000000000002 R09: ffff81017c5d1000
    > R10: 0000000000000000 R11: 0000000000000246 R12: ffff81016b903a28
    > R13: ffff81017f822020 R14: ffff81017c4bfd58 R15: ffff81017f822020
    > FS: 00007f08e71696f0(0000) GS:ffff81017fc06480(0000) knlGS:0000000000000000
    > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    > CR2: ffffffffa0094370 CR3: 000000017e54a000 CR4: 00000000000006e0
    > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    > Process ls (pid: 21205, threadinfo ffff81017c4be000, task ffff81017de48770)
    > Stack: ffff81017c5d1000 00000000ffffffea ffff81017e450300 ffffffff802bdd1e
    > ffff81017f802258 ffff81017c4bfe48 ffff81016b903a28 ffff81017f822020
    > ffff81017c4bfd48 ffffffff802b9ba0 ffff81016b903a28 ffff81017f802258
    > Call Trace:
    > [] ? proc_lookup_de+0x8e/0x100
    > [] ? proc_root_lookup+0x20/0x60
    > [] ? do_lookup+0x1b7/0x210
    > [] ? __link_path_walk+0x53d/0x7f0
    > [] ? mntput_no_expire+0x28/0x130
    > [] ? path_walk+0x5a/0xc0
    > [] ? do_path_lookup+0x83/0x1c0
    > [] ? getname+0xe5/0x210
    > [] ? __user_walk_fd+0x4b/0x80
    > [] ? vfs_lstat_fd+0x2c/0x70
    > [] ? filldir+0xae/0xf0
    > [] ? de_put+0x9/0x50
    > [] ? mnt_want_write+0x2d/0x80
    > [] ? touch_atime+0x1f/0x170
    > [] ? proc_root_readdir+0x7d/0xa0
    > [] ? sys_newlstat+0x27/0x50
    > [] ? vfs_readdir+0x9b/0xd0
    > [] ? sys_getdents+0xce/0xe0
    > [] ? system_call_after_swapgs+0x7b/0x80
    >
    > Code: b7 83 b2 00 00 00 25 00 f0 00 00 3d 00 80 00 00 74 19 48 89 93 f0 00 00 00 48 89 df e8 39 9a fd ff 48 89 d8 48 83 c4 08 5b 5d c3 <48> 83 7a 50 00 48 c7 c0 60 16 45 80 48 c7 c2 40 17 45 80 48 0f
    > RIP [] proc_get_inode+0x101/0x130
    > RSP
    > CR2: ffffffffa0094370
    > ---[ end trace c71hiarjan8ab739 ]---
    >
    > Signed-off-by: Alexey Dobriyan
    > ---
    >
    > drivers/video/fbmem.c | 1 +
    > 1 file changed, 1 insertion(+)
    >
    > --- a/drivers/video/fbmem.c
    > +++ b/drivers/video/fbmem.c
    > @@ -1551,6 +1576,7 @@ module_init(fbmem_init);
    > static void __exit
    > fbmem_exit(void)
    > {
    > + remove_proc_entry("fb", NULL);
    > class_destroy(fb_class);
    > unregister_chrdev(FB_MAJOR, "fb");
    > }


    hm, that's the sort of thing which one would expect people to notice fairly
    soon after we added the bug. Yet it appears that the bug is present in
    at least 2.6.20 and probably earlier.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH] Fix /proc/fb oops after module removal

    On Sat, 12 Apr 2008 15:20:06 -0700
    Andrew Morton wrote:

    > On Sun, 13 Apr 2008 01:10:29 +0400 Alexey Dobriyan
    > wrote:
    >
    > > /proc/fb is not removed during rmmod.
    > >
    > > Steps to reproduce:
    > >
    > > modprobe fb
    > > rmmod fb
    > > ls /proc
    > >


    >
    > hm, that's the sort of thing which one would expect people to notice
    > fairly soon after we added the bug. Yet it appears that the bug is
    > present in at least 2.6.20 and probably earlier.


    rmmod is generally a rare operation... esp for something like a framebuffer

    wonder if we need a scripted action that loads all modules and then tries to
    unload the ones it can

    --
    If you want to reach me at my work email, use arjan@linux.intel.com
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread