On 05/11/2012 10:42 PM, Alan Stern wrote:
On Fri, 11 May 2012, Oncaphillis wrote:
hallo,
I'm developing a hardware application based on theEZ-USB SX2 Chip
from Cypress using libusb-1.0.8 and I see kernel crashes like:
<snip>
May 03 19:11:59 [kernel] [<ffffffff8137ccde>] free_async+0x22/0x47
May 03 19:11:59 [kernel] [<ffffffff8137f494>] usbdev_do_ioctl+0xa51/0xd3f
free_async() calls kfree() more than once. Can you figure out which
call causes the problem?
I enabled SLUB Poisoning and found the following
<snip>
May 09 18:46:34 [kernel] [ 133.013088]
=============================================================================
May 09 18:46:34 [kernel] [ 133.013091] BUG kmalloc-512 (Not tainted):
Poison overwritten
May 09 18:46:34 [kernel] [ 133.013093]
-----------------------------------------------------------------------------
May 09 18:46:34 [kernel] [ 133.013093]
May 09 18:46:34 [kernel] [ 133.013096] INFO:
0xffff880079b253b0-0xffff880079b253b1. First byte 0x9d instead of 0x6b
May 09 18:46:34 [kernel] [ 133.013102] INFO: Allocated in
proc_do_submiturb+0x41a/0x876 age=188 cpu=0 pid=4468
proc_do_submiturb() does several allocations. Can you figure out which
one this is?
This also seems to be the transfer_buffer. At least it's the kmalloc
following directly after the bug report of the slug although I don't get
the same address. I assume that slug allocts a new address if it detects
an error. I also see kfrees of 0x00000 adresses when freeing
ios_pkt and setup_packet but I assume that its o.k. for kfree.
The error seems to hit less often if I insert more and more printk.
seems like its a matter of timing. Could it be the transfer_buffer is
used as a start_point for DMA, the driver starts up the DMA and assumes
to early that it failed ? That coul fit to the loss of 2 byte sequences
we see. The corrupting byes always seem to be 9d 8d.
So -- as far as I understand SLUB Poisoning someone makes a kmalloc and
gets a chunk of memory
which someone else, presumably _proc_do_submiturb, wrote into after if
called kfree on the block.
Any suggestions on how to proceed on this issue ?
Figuring out which structure is getting overwritten would be a good
start.
Alan Stern
--
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
--
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
