lkml.org 
[lkml]   [2006]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectUse of spinlock after free with CFQ scheduler
Hi,

While developing a block device driver, we stumbled upon the kernel
panic reported at
http://www.ussg.iu.edu/hypermail/linux/kernel/0512.3/0297.html.
According to the mail and your answer, it seems that the CFQ scheduler
uses the queue lock after blk_cleanup_queue(). At this time, the
spinlock might have been freed. I can confirm that the bug doesn't
appear with other I/O schedulers.

However, the proposed fix for "ub" looks quite strange to me. It uses
a static array of spinlocks, so that they remain in memory after
blk_cleanup_queue(). However, "ub" can be compiled as a module, so I
don't see what prevent the use of the queue spinlocks by the CFQ
scheduler once the module has been unloaded. I do not understand how the
provided patch correctly fixes the bug.

The bug was reported on a pre-2.6.15 kernel, but we're still seeing
this bug with a 2.6.16 FedoraCore-hacked kernel.

To me, the bug seems to be in the CFQ scheduler itself, isn't it ?
Maybe we should use the internal queue lock (by passing NULL as the
lock parameter to the blk_init_queue() call), and then modify the CFQ
scheduler so that it correctly increments/decrements the queue->refcnt ?

What do you think about it ?

Thanks!

Thomas
--
Thomas Petazzoni - thomas.petazzoni@enix.org
http://{thomas,sos,kos}.enix.org - http://www.toulibre.org
http://www.{livret,agenda}dulibre.org
-
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/

\
 
 \ /
  Last update: 2006-06-13 17:40    [W:0.032 / U:13.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site