On 05/28/2012 08:07 AM, Tejun Heo wrote:
On Fri, May 25, 2012 at 10:10:59AM +0800, Asias He wrote:
Commit 777eb1bf15b8532c396821774bf6451e563438f5 disconnects externally
supplied queue_lock before blk_drain_queue(). This would introduce lock
unbalance because theads which have taken the external lock might unlock
the internal lock in the during the queue drain.
This patch fixes this by disconnecting the lock after the queue drain.
I don't think the patch description is correct. The lock switcihng is
inherently broken and the patch doesn't really fix the problem
although it *might* make the problem less likely. Trying to switch
locks while there are other accessors of the lock is simply broken, it
can never work without outer synchronization.
Since the lock switching is broken, is it a good idea to force all the
drivers to use the block layer provided lock? i.e. Change the API from
blk_init_queue(rfn, driver_lock) to blk_init_queue(rfn). Any reason not
to use the block layer provided one.
Your patch might make
the problem somewhat less likely simply because queue draining makes a
lot of request_queue users go away.
Who will use the request_queue after blk_cleanup_queue()?
So, can you please update the commit description? It doesn't really
*fix* anything but I think we're still better off with the change.
Sure. Will send v2.
--
Asias
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
