Bug 11913

Summary: USB/INPUT: slab error in cache_alloc_debugcheck_after(): double free?
Product: Drivers Reporter: Rafael J. Wysocki (rjw)
Component: USBAssignee: Helge Deller (deller)
Status: CLOSED CODE_FIX    
Severity: normal CC: deller, jirislaby
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.28-rc2 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 11808    

Description Rafael J. Wysocki 2008-10-30 16:39:03 UTC
Subject    : 2.6.28-rc2: USB/INPUT: slab error in cache_alloc_debugcheck_after(): double free?
Submitter  : Helge Deller <deller@gmx.de>
Date       : 2008-10-30 23:11
References : http://marc.info/?l=linux-kernel&m=122540833301394&w=4

This entry is being used for tracking a regression from 2.6.27.  Please don't
close it until the problem is fixed in the mainline.
Comment 1 Rafael J. Wysocki 2008-10-31 15:35:27 UTC
Handled-By : Jiri Kosina <jkosina@suse.cz>
Handled-By : Jiri Slaby <jirislaby@gmail.com>
Notify-Also : Jeroen Roovers <jer@gentoo.org>
Comment 2 Helge Deller 2008-11-02 09:00:05 UTC
a bisecting showed that commit cb8f488c33539f096580e202f5438a809195008f might be one of the reasons, why it fails on parisc.
Still investigating....
Comment 3 Jiri Slaby 2008-11-08 06:21:31 UTC
Handled-By : Jiri Kosina <jkosina@suse.cz>
Handled-By : Jiri Slaby <jirislaby@gmail.com>
Handled-By : Denys Vlasenko <vda.linux@googlemail.com>
Notify-Also : Jeroen Roovers <jer@gentoo.org>
Comment 4 Rafael J. Wysocki 2008-11-09 10:41:47 UTC
First-Bad-Commit : cb8f488c33539f096580e202f5438a809195008f
Comment 5 Rafael J. Wysocki 2008-11-16 09:28:28 UTC
We seem to be missing information allowing us to identify the problem.  About to close as "insufficient data".
Comment 6 Jiri Slaby 2008-11-16 11:19:40 UTC
Well, there are probably two bugs in there. One is the referred commit. But there still seems to be another issue. I hope Helge is trying to bisect it, Linus provided him a bisecting manual for such double-bug cases.
Comment 7 Helge Deller 2008-11-16 15:43:02 UTC
Rafael,
identifying the problem is really hard.
I'd suggest (if that's possible, e.g. as WILL_FIX_LATER?) to mark this as a non-blocker for a 2.6.28 release, as it only affects HP PARISC architecture. Keeping the bug report itself open, may help me to continue to this bug.

2.6.28-rc5 crashes similiar, but now it does not seem to be an USB related problem, as at this stage USB hasn't been touched yet at all.

...
SuperIO: Parallel port at 0x378
SuperIO: Floppy controller at 0x3f0
SuperIO: ACPI at 0x7e0
...
Slab corruption: size-32 start=8ed91d38, len=32
Redzone: 0x0/0x0.
Last user: [<00000000>](0x0)
000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Prev obj: start=8ed91cd8, len=32
Redzone: 0x0/0x0.
Last user: [<00000000>](0x0)
000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
slab error in cache_alloc_debugcheck_after(): cache `size-32': double free, or memory outside object was overn
Backtrace:
 [<1018c358>] cache_alloc_debugcheck_after+0xd8/0x200
 [<1018c814>] kmem_cache_alloc+0xd8/0x120
 [<102a7f30>] pci_get_subsys+0x50/0xa4
 [<102a7fa0>] pci_get_device+0x1c/0x28
 [<10103274>] pci_init+0x28/0x44
 [<1010d9c8>] do_one_initcall+0x70/0x190
 [<106bdcf8>] do_initcalls+0x30/0x4c
 [<106bddf8>] kernel_init+0x64/0xac
 [<10113c5c>] ret_from_kernel_thread+0x1c/0x24

8ed91d30: redzone 1:0x0, redzone 2:0x0
Backtrace:
 [<1018c814>] kmem_cache_alloc+0xd8/0x120
 [<102a7f30>] pci_get_subsys+0x50/0xa4
 [<102a7fa0>] pci_get_device+0x1c/0x28
 [<10103274>] pci_init+0x28/0x44
 [<1010d9c8>] do_one_initcall+0x70/0x190
 [<106bdcf8>] do_initcalls+0x30/0x4c
 [<106bddf8>] kernel_init+0x64/0xac
 [<10113c5c>] ret_from_kernel_thread+0x1c/0x24


Kernel Fault: Code=15 regs=8f824480 (Addr=990d2478)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000011100000101100001111 Not tainted
r00-03  000e0b0f 00000028 1018c43c 8ed91d30
r04-07  8ed91d30 d84156c5 635688c0 8f8001c0
r08-11  ffffffff 1066be10 1014b45c 1066bbd0
r12-15  00000000 ffffffff 00000000 f0400004
r16-19  f0000884 f000017c f0000174 fffffffd
r20-23  990d245c 11a05220 00001d94 00669c3c
r24-27  ffffffff 00000038 8f8001c0 106083d0
r28-31  8ed91d58 028d0517 8f824480 1018c428
sr00-03  00000000 00000000 00000000 00000000
sr04-07  00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 1018c438 10189fc8
 IIR: 6a930038    ISR: 00000000  IOR: 990d2478
 CPU:        0   CR30: 8f824000 CR31: c22344e0
 ORIG_R28: 1066be10
 IAOQ[0]: cache_alloc_debugcheck_after+0x1b8/0x200
 IAOQ[1]: obj_offset+0x0/0x8
 RP(r2): cache_alloc_debugcheck_after+0x1bc/0x200
Backtrace:
 [<1018c814>] kmem_cache_alloc+0xd8/0x120
 [<102a7f30>] pci_get_subsys+0x50/0xa4
 [<102a7fa0>] pci_get_device+0x1c/0x28
 [<10103274>] pci_init+0x28/0x44
 [<1010d9c8>] do_one_initcall+0x70/0x190
 [<106bdcf8>] do_initcalls+0x30/0x4c
 [<106bddf8>] kernel_init+0x64/0xac
 [<10113c5c>] ret_from_kernel_thread+0x1c/0x24
Kernel panic - not syncing: Kernel Fault
Comment 8 Helge Deller 2008-12-02 15:09:08 UTC
Hi Rafael,
I just tested 2.6.28-rc7 and everything seems fine.
Please close this bug.
Thanks, Helge
Comment 9 Rafael J. Wysocki 2008-12-02 15:20:50 UTC
Great, closing.