On Fri, Nov 13, 2015 at 06:50:27PM +0100, Steinar H. Gunderson wrote: > The stack trace is simple enough, although I fear there's some inlining going > on:
OK, I guess since copy_user_enhanced_fast_string is an assembler function, the unwinding doesn't work properly. I added a dump_stack() in copy_urb_data_to_user() instead, which is probably a better place: [ 38.535633] Call Trace: [ 38.535640] [<ffffffff812a5113>] ? dump_stack+0x40/0x5d [ 38.535652] [<ffffffffc00270b5>] ? copy_urb_data_to_user+0x15/0x110 [usbcore] [ 38.535654] [<ffffffffc002723d>] ? processcompl+0x8d/0x130 [usbcore] [ 38.535656] [<ffffffffc0029b83>] ? usbdev_do_ioctl+0xa3/0x1310 [usbcore] [ 38.535659] [<ffffffffc002ae05>] ? usbdev_ioctl+0x5/0x10 [usbcore] [ 38.535663] [<ffffffff811b4bce>] ? do_vfs_ioctl+0x2be/0x490 [ 38.535666] [<ffffffff810c921a>] ? ktime_get_ts64+0x3a/0xe0 [ 38.535668] [<ffffffff811b4e11>] ? SyS_ioctl+0x71/0x80 [ 38.535672] [<ffffffff81512f2e>] ? entry_SYSCALL_64_fastpath+0x12/0x71 There's still the jump from processcompl to copy_urb_data_to_user, but I guess this is the more relevant one. (The dump_stack() triggers hundreds of times per second.) I tried just not setting as->userbuffer if usbm == NULL, and lo and behold, it actually seems to help. I'm wondering if the copy is just from the buffer to itself? copy_user_enhanced_fast_string is now down at 0.26%, ie. effectively nothing. /* Steinar */ -- Homepage: https://www.sesse.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
