From: Greg KH <greg@kroah.com>
To: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>, maxk@qualcomm.com
Cc: linux-kernel@vger.kernel.org, Alexander Hoogerhuis <alexh@ihatent.com>
Subject: Re: Sleeping in illegal context with 2.5.65-mm2
Date: Wed, 19 Mar 2003 21:05:37 -0800 [thread overview]
Message-ID: <20030320050537.GA19436@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0303192300410.11075-100000@chaos.physics.uiowa.edu>
On Wed, Mar 19, 2003 at 11:03:51PM -0600, Kai Germaschewski wrote:
> On Wed, 19 Mar 2003, Greg KH wrote:
>
> > > Debug: sleeping function called from illegal context at mm/slab.c:1723
> > > Call Trace:
> > > [<c0119d92>] __might_sleep+0x5f/0x65
> > > [<c013a097>] kmalloc+0x88/0x8f
> > > [<c0238111>] usb_alloc_urb+0x21/0x51
> > > [<f09180bc>] hci_usb_enable_intr+0x20/0xf8 [hci_usb]
> >
> > The call to usb_alloc_urb() here is being done with the GFP_ATOMIC flag,
> > which is correct. Do we need to fix up the warning message to prevent
> > false positives like this from happening?
>
> Not in my tree: (drivers/bluetooth/hci_sb.c)
>
> if (!(urb = usb_alloc_urb(0, GFP_KERNEL)))
> return -ENOMEM;
Doh, nevermind, I was looking at the wrong function, sorry.
> And the function is called in a write_lock_irqsave(), so the complaint is
> justified.
Max, you should probably fix this up.
> (Also, I think __might_sleep() deliberately doesn't get triggered for
> GFP_ATOMIC already, as you suggested).
Yeah, in digging deeper, it's a smart check, sorry.
thanks,
greg k-h
next prev parent reply other threads:[~2003-03-20 5:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-20 2:58 Sleeping in illegal context with 2.5.65-mm2 Alexander Hoogerhuis
2003-03-20 4:39 ` Greg KH
2003-03-20 5:03 ` Kai Germaschewski
2003-03-20 5:05 ` Greg KH [this message]
2003-03-24 21:44 ` Max Krasnyansky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030320050537.GA19436@kroah.com \
--to=greg@kroah.com \
--cc=alexh@ihatent.com \
--cc=kai@tp1.ruhr-uni-bochum.de \
--cc=linux-kernel@vger.kernel.org \
--cc=maxk@qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox