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

[Minchan Kim <minchan.kim@gmail.com>]

Hi, Jiri.

On Tue, Sep 15, 2009 at 7:10 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> 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@suse.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.

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?


>
> Reported-by: Jens Axboe <jens.axboe@oracle.com>
> Signed-off-by: Jiri Kosina <jkosina@suse.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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Kind regards,
Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>