Bug 9216
Summary: | Kernel NULL pointer dereference at :usbhid:hiddev_ioctl+0x2f/0xabc | ||
---|---|---|---|
Product: | Other | Reporter: | Tim Kosse (tim.kosse) |
Component: | Modules | Assignee: | Jiri Kosina (jikos) |
Status: | REJECTED INSUFFICIENT_DATA | ||
Severity: | high | CC: | albcamus |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.32.1 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: | My .config |
Description
Tim Kosse
2007-10-24 05:03:33 UTC
Created attachment 13259 [details]
My .config
Reply-To: akpm@linux-foundation.org On Wed, 24 Oct 2007 05:03:35 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9216 > > Summary: Kernel NULL pointer dereference at > :usbhid:hiddev_ioctl+0x2f/0xabc > Product: Other > Version: 2.5 > KernelVersion: 2.6.32.1 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Modules > AssignedTo: other_modules@kernel-bugs.osdl.org > ReportedBy: tim.kosse@gmx.de > > > I'm using vanilla 2.6.32.1 patched with UnionFS 2.1.7 > > (http://download.filesystems.org/unionfs/unionfs-2.1/unionfs-2.1.7_for_2.6.23.1.diff.gz) > No other patches are applied. > > Sometimes after waking up from suspend-to-ram, I get the following message in > the kernel log: > > Unable to handle kernel NULL pointer dereference at 00000000000000c9 RIP: > [<ffffffff880599f3>] :usbhid:hiddev_ioctl+0x2f/0xabc > PGD 1a2ed067 PUD 1a2ee067 PMD 0 > Oops: 0000 [1] > CPU 0 > Modules linked in: ipv6 pcspkr iptable_filter ip_tables x_tables i2c_viapro > i2c_ core > via_agp dm_mirror scsi_wait_scan sl811_hcd usbhid ohci_hcd uhci_hcd usb_sto > rage ehci_hcd > usbcore > Pid: 6018, comm: apcupsd Tainted: G M 2.6.23.1 #1 > RIP: 0010:[<ffffffff880599f3>] [<ffffffff880599f3>] > :usbhid:hiddev_ioctl+0x2f/0 > xabc > RSP: 0018:ffff8100181f7e28 EFLAGS: 00010296 > RAX: 0000000000000001 RBX: 00000000400c4807 RCX: 00007fffa76f5dc0 > RDX: ffff810017192bc0 RSI: ffff810019981000 RDI: ffff81001afd7d18 > RBP: ffff81001a4e6000 R08: ffff810019a73a00 R09: ffffffff880599c4 > R10: 00000000471e0c96 R11: 0000000000000246 R12: 00007fffa76f5dc0 > R13: 00007fffa76f5dc0 R14: 00000000400c4807 R15: 00007fffa76f60d8 > FS: 00002b56040add20(0000) GS:ffffffff805d6000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000000000c9 CR3: 000000001a2ec000 CR4: 00000000000006e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process apcupsd (pid: 6018, threadinfo ffff8100181f6000, task > ffff81001ec9a000) > Stack: ffff8100181f7e98 0000000000000086 ffffffff805a2c00 ffff81001ec9a000 > ffffffff805983a0 ffff81001cd50e40 ffff8100181f7ed8 0000000000000292 > 0000000000000000 ffff8100181f7ed8 ffff8100181f7ed8 0000000000000292 > Call Trace: > [<ffffffff8023feee>] hrtimer_cancel+0x10/0x16 > [<ffffffff804a61e1>] do_nanosleep+0x64/0x7c > [<ffffffff80228fbf>] default_wake_function+0x0/0xe > [<ffffffff8024021a>] hrtimer_nanosleep+0x7c/0x13b > [<ffffffff8027eeb0>] do_ioctl+0x50/0x61 > [<ffffffff8027ef1c>] vfs_ioctl+0x5b/0x244 > [<ffffffff8027f178>] sys_ioctl+0x73/0x8b > [<ffffffff8020bd3e>] system_call+0x7e/0x83 > > > Code: 48 8b 88 c8 00 00 00 48 8b bd c8 19 00 00 b8 fb ff ff ff 44 > RIP [<ffffffff880599f3>] :usbhid:hiddev_ioctl+0x2f/0xabc > RSP <ffff8100181f7e28> > CR2: 00000000000000c9 > I bumped the severity on this to "high". I assume thisis a regression? That earlier kernels did not have this bug? Iirc it didn't happen with 2.6.22 I don't immediately see any change between 2.6.22 and 2.6.23 that could cause this (in fact hiddev code hasn't been touched at all). Could you please try git-bisect to find the offending bug, assuming that you can easily reproduce it? Do you have userspace program using hiddev running (acpupsd, nuts, etc.)? Yes, I'm using apcupsd. I've updated to 2.6.24-rc2-git3 a day ago and this problem has disappeared. I do hover see a couple of "drivers/hid/usbhid/hid-core.c: usb_submit_urb(ctrl) failed" messages in the log if waking up from suspend. After a few seconds the USB connections to the APC gets reinitialized however. Restarting tasks ... <3>drivers/hid/usbhid/hid-core.c: usb_submit_urb(ctrl) failed done. drivers/hid/usbhid/hid-core.c: usb_submit_urb(ctrl) failed drivers/hid/usbhid/hid-core.c: usb_submit_urb(ctrl) failed drivers/hid/usbhid/hid-core.c: usb_submit_urb(ctrl) failed drivers/hid/usbhid/hid-core.c: usb_submit_urb(ctrl) failed drivers/hid/usbhid/hid-core.c: usb_submit_urb(ctrl) failed drivers/hid/usbhid/hid-core.c: usb_submit_urb(ctrl) failed usb 3-1: USB disconnect, address 7 usb 3-1: new low speed USB device using uhci_hcd and address 8 usb 3-1: configuration #1 chosen from 1 choice hiddev96: USB HID v1.10 Device [American Power Conversion Back-UPS CS 650 FW:817.v4.I USB FW:v4] on usb-0000:00:10.1-1 The messages about failing urbs should be harmless. OK, as the problem doesn't seem to be there anymore, I am closing the bug. If it triggers for you again, please feel free to reopen the bug. *** Bug 9529 has been marked as a duplicate of this bug. *** Could you please do gdb vmlinux /proc/kcore (gdb) l *ffffffff880599f3 (gdb) disassemble hiddev_ioctl and attach the output, so that I know the precise location where the NULL pointer dereference happens? Thanks. I'm getting an error message: No symbol table is loaded. Use the "file" command. Please try this one: gdb /lib/modules/`uname -r`/build/vmlinux /proc/kcore (gdb) l *ffffffff880599f3 (gdb) disassemble hiddev_ioctl and post the output. Thanks. |