On Fri, 13 Nov 2015, Steinar H. Gunderson wrote: > 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. In fact, there's no need to call copy_urb_data_to_user at all if the buffer lies in the mmap'ed area. > I'm wondering if the copy is just from the buffer > to itself? Yes, it is. I can't imagine why this wasn't handled in the original patch. Simple oversight? > copy_user_enhanced_fast_string is now down at 0.26%, ie. > effectively nothing. Very good. 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
