From mboxrd@z Thu Jan  1 00:00:00 1970
From: daniel.baluta@gmail.com (Daniel Baluta)
Date: Thu, 17 Mar 2011 23:46:42 +0200
Subject: inconsistent lock state on call to kmem_cache_zalloc()
In-Reply-To: <4D82763E.4070903@enea.com>
References: <4D824F44.8090501@enea.com>
	<AANLkTik-j-e0G9Eo98mynFbDF5K35GftBm334_CMaa+8@mail.gmail.com>
	<4D82763E.4070903@enea.com>
Message-ID: <AANLkTi=qP7JjWdGEtDWfoxnDoKQHEELN+Xw0ZnABG+e6@mail.gmail.com>
To: kernelnewbies@lists.kernelnewbies.org
List-Id: kernelnewbies.lists.kernelnewbies.org

On Thu, Mar 17, 2011 at 10:59 PM, Arvid Brodin <arvid.brodin@enea.com> wrote:
> Hi,
>
> Daniel Baluta wrote:
>> Hello,
>>
>>> The call to kmem_cache_zalloc() never returns; the printk() text on the line
>>> after is never displayed and the system locks up. The printk() om the line
>>> before displays.
>>
>> What flags are you passing to kmem_cache_zalloc?
>
> I'm using the flags passed to the urb_enqueue() function; a printk reveals
> the value is 16, which would be GFP_NOIO if I read include/linux/gfp.h correctly.

Hmm, I guess this is not quite OK. You hold a spinlock, and you can sleep
while allocating memory.

Daniel.