Re: Page allocation failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux