linux-kernel - Re: BUG: sleeping function called from invalid context at mm/slub.c:1717

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.00.0909151202560.17028@wotan.suse.de>
Date:	Tue, 15 Sep 2009 12:10:05 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: BUG: sleeping function called from invalid context at
 mm/slub.c:1717

On Tue, 15 Sep 2009, Jens Axboe wrote:

> 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.

Thanks for letting me know. The patch below should fix it.



From: Jiri Kosina <jkosina@...e.cz>
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.

Reported-by: Jens Axboe <jens.axboe@...cle.com>
Signed-off-by: Jiri Kosina <jkosina@...e.cz>
---
 drivers/hid/hid-core.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 342b7d3..ca9bb26 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/