BUG: sleeping function called from invalid context at mm/slub.c:1717
Subsystems (2)
Hi,
This is new with todays -git:
BUG: sleeping function called from invalid context at mm/slub.c:1717 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper Pid: 0, comm: swapper Not tainted 2.6.31 #206 Call Trace: <IRQ> [<ffffffff8103eb23>] __might_sleep+0xf3/0x110 [<ffffffff810e4d83>] kmem_cache_alloc+0x123/0x170 [<ffffffff813306c9>] hid_input_report+0x89/0x3a0 [<ffffffffa00cd5f4>] hid_ctrl+0xa4/0x1f0 [usbhid] [<ffffffff8108a4c7>] ? handle_IRQ_event+0xa7/0x1e0 [<ffffffffa004da1f>] usb_hcd_giveback_urb+0x3f/0xa0 [usbcore] [<ffffffffa0074ab4>] uhci_giveback_urb+0xb4/0x240 [uhci_hcd] [<ffffffffa00750e7>] uhci_scan_schedule+0x357/0xab0 [uhci_hcd] [<ffffffffa0077a01>] uhci_irq+0x91/0x190 [uhci_hcd] [<ffffffffa004d44e>] usb_hcd_irq+0x2e/0x70 [usbcore] [<ffffffff8108a4c7>] handle_IRQ_event+0xa7/0x1e0 [<ffffffff8108c58c>] handle_fasteoi_irq+0x7c/0xf0 [<ffffffff8100f176>] handle_irq+0x46/0xa0 [<ffffffff8100e49a>] do_IRQ+0x6a/0xf0 [<ffffffff8100c853>] ret_from_intr+0x0/0xa
And I notice there's a HID merge from yesterday, Jiri CC'ed.
Signature · 1 line
Jens Axboe
Quoted 22 lines · Jens Axboe
This is new with todays -git:
BUG: sleeping function called from invalid context at mm/slub.c:1717 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper Pid: 0, comm: swapper Not tainted 2.6.31 #206 Call Trace: <IRQ> [<ffffffff8103eb23>] __might_sleep+0xf3/0x110 [<ffffffff810e4d83>] kmem_cache_alloc+0x123/0x170 [<ffffffff813306c9>] hid_input_report+0x89/0x3a0 [<ffffffffa00cd5f4>] hid_ctrl+0xa4/0x1f0 [usbhid] [<ffffffff8108a4c7>] ? handle_IRQ_event+0xa7/0x1e0 [<ffffffffa004da1f>] usb_hcd_giveback_urb+0x3f/0xa0 [usbcore] [<ffffffffa0074ab4>] uhci_giveback_urb+0xb4/0x240 [uhci_hcd] [<ffffffffa00750e7>] uhci_scan_schedule+0x357/0xab0 [uhci_hcd] [<ffffffffa0077a01>] uhci_irq+0x91/0x190 [uhci_hcd] [<ffffffffa004d44e>] usb_hcd_irq+0x2e/0x70 [usbcore] [<ffffffff8108a4c7>] handle_IRQ_event+0xa7/0x1e0 [<ffffffff8108c58c>] handle_fasteoi_irq+0x7c/0xf0 [<ffffffff8100f176>] handle_irq+0x46/0xa0 [<ffffffff8100e49a>] do_IRQ+0x6a/0xf0 [<ffffffff8100c853>] ret_from_intr+0x0/0xa
Quoted 1 line
And I notice there's a HID merge from yesterday, Jiri CC'ed.
Thanks for letting me know. The patch below should fix it.
From: Jiri Kosina <[email protected]>
Subject: [PATCH] HID: fix non-atomic allocation in hid_input_report
'interrupt' variable can't be used to safely determine whether we are running in atomic context or not, as we might be called from during control transfer completion through hid_ctrl() in atomic context with interrupt == 0.
--- drivers/hid/hid-core.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-)
drivers/hid/hid-core.c +1 -2
@@ -1089,8 +1089,7 @@ int hid_input_report(struct hid_device *hid, int type, u8 *data, int size, int ireturn -1 ; } - buf =kmalloc (sizeof (char ) *HID_DEBUG_BUFSIZE , - interrupt ?GFP_ATOMIC :GFP_KERNEL ); + buf =kmalloc (sizeof (char ) *HID_DEBUG_BUFSIZE ,GFP_ATOMIC );if (!buf) { report =hid_get_report (report_enum, data);
Signature · 1 line
1.5.6
Quoted 24 lines · Jiri Kosina
Quoted 22 lines · Jens Axboe
This is new with todays -git:
BUG: sleeping function called from invalid context at mm/slub.c:1717 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper Pid: 0, comm: swapper Not tainted 2.6.31 #206 Call Trace: <IRQ> [<ffffffff8103eb23>] __might_sleep+0xf3/0x110 [<ffffffff810e4d83>] kmem_cache_alloc+0x123/0x170 [<ffffffff813306c9>] hid_input_report+0x89/0x3a0 [<ffffffffa00cd5f4>] hid_ctrl+0xa4/0x1f0 [usbhid] [<ffffffff8108a4c7>] ? handle_IRQ_event+0xa7/0x1e0 [<ffffffffa004da1f>] usb_hcd_giveback_urb+0x3f/0xa0 [usbcore] [<ffffffffa0074ab4>] uhci_giveback_urb+0xb4/0x240 [uhci_hcd] [<ffffffffa00750e7>] uhci_scan_schedule+0x357/0xab0 [uhci_hcd] [<ffffffffa0077a01>] uhci_irq+0x91/0x190 [uhci_hcd] [<ffffffffa004d44e>] usb_hcd_irq+0x2e/0x70 [usbcore] [<ffffffff8108a4c7>] handle_IRQ_event+0xa7/0x1e0 [<ffffffff8108c58c>] handle_fasteoi_irq+0x7c/0xf0 [<ffffffff8100f176>] handle_irq+0x46/0xa0 [<ffffffff8100e49a>] do_IRQ+0x6a/0xf0 [<ffffffff8100c853>] ret_from_intr+0x0/0xa
Quoted 3 lines
Quoted 1 line
And I notice there's a HID merge from yesterday, Jiri CC'ed.
Thanks for letting me know. The patch below should fix it.
Yes that works, thanks Jiri!
Signature · 1 line
Jens Axboe
Hi, Jiri.
Quoted 30 lines · Jiri Kosina
Quoted 22 lines · Jens Axboe
This is new with todays -git:
BUG: sleeping function called from invalid context at mm/slub.c:1717 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper Pid: 0, comm: swapper Not tainted 2.6.31 #206 Call Trace: <IRQ> [<ffffffff8103eb23>] __might_sleep+0xf3/0x110 [<ffffffff810e4d83>] kmem_cache_alloc+0x123/0x170 [<ffffffff813306c9>] hid_input_report+0x89/0x3a0 [<ffffffffa00cd5f4>] hid_ctrl+0xa4/0x1f0 [usbhid] [<ffffffff8108a4c7>] ? handle_IRQ_event+0xa7/0x1e0 [<ffffffffa004da1f>] usb_hcd_giveback_urb+0x3f/0xa0 [usbcore] [<ffffffffa0074ab4>] uhci_giveback_urb+0xb4/0x240 [uhci_hcd] [<ffffffffa00750e7>] uhci_scan_schedule+0x357/0xab0 [uhci_hcd] [<ffffffffa0077a01>] uhci_irq+0x91/0x190 [uhci_hcd] [<ffffffffa004d44e>] usb_hcd_irq+0x2e/0x70 [usbcore] [<ffffffff8108a4c7>] handle_IRQ_event+0xa7/0x1e0 [<ffffffff8108c58c>] handle_fasteoi_irq+0x7c/0xf0 [<ffffffff8100f176>] handle_irq+0x46/0xa0 [<ffffffff8100e49a>] do_IRQ+0x6a/0xf0 [<ffffffff8100c853>] ret_from_intr+0x0/0xaQuoted 1 line
And I notice there's a HID merge from yesterday, Jiri CC'ed.
Thanks for letting me know. The patch below should fix it.
Quoted 7 lines
From: Jiri Kosina <[email protected]>
Subject: [PATCH] HID: fix non-atomic allocation inhid_input_report'interrupt' variable can't be used to safely determine whether we are running in atomic context or not, as we might be called from during control transfer completion through
hid_ctrl()in atomic context with interrupt == 0.
I am not a USB expert so It might be dump comment. :)
We have to change description of hid_input_report.
* @interrupt: called from atomic?
I think it lost meaning.
I am worried that interrupt variable is propagated down to sub functions. Is it right on sub functions?
One more thing, I am concerned about increasing GFP_ATOMIC customers although we can avoid it.
Is it called rarely?
Could you find a alternative method to overcome this issue?
Quoted 30 lines
Reported-by Jens Axboe <[email protected]>Signed-off-by Jiri Kosina <[email protected]>---
drivers/hid/hid-core.c | 3 +--1 files changed, 1 insertions(+), 2 deletions(-)drivers/hid/hid-core.c +1
-3@@ -1089,8 +1089,7 @@ int hid_input_report(struct hid_device *hid, int type, u8 *data, int size, int i return -1; } - buf = kmalloc(sizeof(char) * HID_DEBUG_BUFSIZE, - interrupt ? GFP_ATOMIC : GFP_KERNEL); + buf = kmalloc(sizeof(char) * HID_DEBUG_BUFSIZE, GFP_ATOMIC); if (!buf) { report = hid_get_report(report_enum, data); --1.5.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 8 lines
Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 4 lines · Minchan Kim
We have to change description of
hid_input_report.* @interrupt: called from atomic?
I think it lost meaning.
Good point, I will change it, thanks.
Quoted 2 lines
I am worried that interrupt variable is propagated down to sub functions. Is it right on sub functions?
Yes. This variable is not used for chosing correct allocation flags anywhere else, it is just carrying the semantics what the HID core should do, what callbacks to call, etc. So it's correct.
But you are right that the name and kerneldocs is confusing, and I will fix that.
Quoted 3 lines
One more thing, I am concerned about increasing
GFP_ATOMICcustomers although we can avoid it. Is it called rarely? Could you find a alternative method to overcome this issue?
This is just a temporary buffer for debugging output, it is freed almost immediately later in the function, and even if the allocation fails, nothing bad happens (just the debugging output is not delivered to the debugfs buffer).
Thanks,
Signature · 8 lines
Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>