On 05/16/2012 10:17 PM, Huajun Li wrote:
However, I think there still exists another race in destroy_async_on_interface(),
Care to try another patch, or could you please share a piece of codes which
may reproduce the issue?
Thank you -- but this really seems to kill the kernel:
<snip>
May 16 14:14:50 [kernel] [ 359.402791] general protection fault: 0000
[#1] SMP
May 16 14:14:50 [kernel] [ 359.402858] CPU 0
May 16 14:14:50 [kernel] [ 359.402881] Modules linked in:
May 16 14:14:50 [kernel] [ 359.402942]
May 16 14:14:50 [kernel] [ 359.402965] Pid: 5661, comm: Engine25DeviceP
Not tainted 3.3.4 #41 To Be Filled By O.E.M. To Be Filled By O.E.M./To
be filled by O.E.M.
May 16 14:14:50 [kernel] [ 359.403063] RIP: 0010:[<ffffffff8139ae0a>]
[<ffffffff8139ae0a>] destroy_async+0x16/0x7e
May 16 14:14:50 [kernel] [ 359.403122] RSP: 0018:ffff88002a8c1e68
EFLAGS: 00010003
May 16 14:14:50 [kernel] [ 359.403152] RAX: 6b6b6b6b6b6b6b6b RBX:
ffff8800295664b0 RCX: 0000000000000007
May 16 14:14:50 [kernel] [ 359.403185] RDX: 0000000000000707 RSI:
0000000000000292 RDI: ffff8800295664b0
May 16 14:14:50 [kernel] [ 359.403218] RBP: ffff88002a8c1e98 R08:
0000000000000000 R09: 0000000000000000
May 16 14:14:50 [kernel] [ 359.403252] R10: 00007fce93bd8210 R11:
ffff88002a8c1ea8 R12: 0000000000000000
May 16 14:14:50 [kernel] [ 359.403286] R13: ffff8800295664b8 R14:
ffff880076e7f048 R15: ffff88002a7658d0
May 16 14:14:50 [kernel] [ 359.403320] FS: 00007fce93bd9710(0000)
GS:ffff88007d400000(0000) knlGS:0000000000000000
May 16 14:14:50 [kernel] [ 359.403465] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
May 16 14:14:50 [kernel] [ 359.403551] CR2: 00007fdb197af158 CR3:
000000002a494000 CR4: 00000000000406f0
May 16 14:14:50 [kernel] [ 359.403641] DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
May 16 14:14:50 [kernel] [ 359.403733] DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
May 16 14:14:50 [kernel] [ 359.403988] Stack:
May 16 14:14:50 [kernel] [ 359.404311] 0000000000000000
ffff880076e7ef60 ffff88002a8c1ec8 ffffffff8139c15b
May 16 14:14:50 [kernel] [ 359.404536] ffff88002a7658c0
0000000000000008 ffff8800765a3228 ffff880076599c70
May 16 14:14:50 [kernel] [ 359.404782] Call Trace:
May 16 14:14:50 [kernel] [ 359.404863] [<ffffffff813913da>] ?
usb_hub_release_all_ports+0x1f/0x4d
May 16 14:14:50 [kernel] [ 359.404951] [<ffffffff8139c15b>]
usbdev_release+0x8e/0xdd
May 16 14:14:50 [kernel] [ 359.405037] [<ffffffff810ccb15>]
fput+0xf9/0x189
May 16 14:14:50 [kernel] [ 359.405124] [<ffffffff810c9dc3>]
filp_close+0x6b/0x76
May 16 14:14:50 [kernel] [ 359.405208] [<ffffffff810c9e58>]
sys_close+0x8a/0xca
May 16 14:14:50 [kernel] [ 359.405293] [<ffffffff81505122>]
system_call_fastpath+0x16/0x1b
May 16 14:14:50 [kernel] [ 359.405377] Code: 74 0e 48 c7 c7 40 fa 73 81
e8 cf d0 ff ff 31 c0 5b 41 5c c9 c3 55 48 89 e5 41 55 49 89 f5 41 54 53
48 8d 5f 20 48 83 ec 18 eb
May 16 14:14:50 [kernel] [ 359.406703] RIP [<ffffffff8139ae0a>]
destroy_async+0x16/0x7e
May 16 14:14:50 [kernel] [ 359.406703] RSP <ffff88002a8c1e68>
May 16 14:14:50 [kernel] [ 359.406703] ---[ end trace b6841c9c4002a847 ]---
</snip>
As for sample code: We have a board that accepts two byte commands via
bulk transfer over endpoint 4. each command should lead to a response via
interrupt transfer via endpoint 8. Our current test code somehow looks like
this crude excerpt -- don't expect this to compile. I had to cut and
paste it
out of our C++ code.
// command buffer
static unsigned char command[]={0xff,0x41};
// send one comamnd
while(true)
{
if(::libusb_bulk_transfer(usb_handle, 4, command, 2, &oSize, 1000
))!=LIBUSB_SUCCESS)
break;
// We read replies twice. The second read is expected to fail, since
// we only have written one command sequence.
// The normal reply to the command 0xff,041 should be 0x00,0x41
// which is exactly the bytes I see in the SLUB Poisoning
// The result however seems to be that the replies don't reach us
sometimes.
// and we see memory corruptions and even kernel freezes.
for(int i=0;i<2;i++)
{
err = ::libusb_interrupt_transfer(usb_handle, 8|
LIBUSB_ENDPOINT_IN , pSrqBuf, 512, &oSize, 500);
{
// This is ok -- simply nothing to read
if(err != LIBUSB_ERROR_TIMEOUT)
{
return err;
}
}
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
