On Mon, Oct 30 2006, Arjan van de Ven wrote: > > > which has always been considered safe, while not very pretty. > > > actually it's different I think (based on a brief inspection of the > code, I could well be wrong): > get_request_wait() causes a get_request() call with a GFP_NOIO gfp_mask > which perculates upto cfq_set_request() as argument. > cfq_set_request() then calls the inline cfq_get_queue() (which isn't in > the backtrace due to inlining) which does > } else if (gfp_mask & __GFP_WAIT) { > /* > * Inform the allocator of the fact that we will > * just repeat this allocation if it fails, to allow > * the allocator to do whatever it needs to attempt to > * free memory. > */ > spin_unlock_irq(cfqd->queue->queue_lock); > > which enables interrupts right smack in the middle of holding a whole > bunch of locks..... Where do you get 'a bunch' from? If you call get_request() with a gfp_mask that includes __GFP_WAIT with a spinlock held, it's a bug. Just as if you had called kmalloc() or similar with __GFP_WAIT set and holding a lock. cfq even includes a warning check: might_sleep_if(gfp_mask & __GFP_WAIT); So there's no bug there, cfq even grabbed the lock on its own before calling cfq_get_queue(). > so to me it looks like lockdep at least has the appearance of moaning > about a reasonably fishy situation... To me it looks more about lockdep complaining because it doesn't grok the full picture. The question is how to shut it up. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html