Skip to contentSkip to conversation

IDE locking problem

DISCUSSION Manfred Spraul 4 participants 4 messages Aug 3, 2003 – Aug 4, 2003

lore
Share & tools
lore
#0 lore raw
Quoted 15 lines

Then, IDE could do something like:

- set dead flag
- wait for all pending requests to drain (easy: insert a barrier in the queue and wait on it, with a hack for the barrier insertion to bypass the dead flag... ugh... maybe a blk_terminate_queue() doing all that would be helpful ?)
- unregister blkdev
- then tear down the queue (leaving the "empty" queue with the dead flag set, not just memset(...,0,...), so that any bozo keeping a reference to it will be rejected trying to insert request instead of trying to tap an uninitalized queue object

Quoted 3 lines

What do you think ?

The last step is bad - sooner or later the queue will be kfreed, and if there are bozos around that still have references, they would access random memory. It must be guaranteed that all references expired before the tear down begins. Just leaving a dead flag set is not sufficient.

--
Manfred

#1 lore raw
Quoted 4 lines

The last step is bad - sooner or later the queue will be kfreed, and if there are bozos around that still have references, they would access random memory. It must be guaranteed that all references expired before the tear down begins. Just leaving a dead flag set is not sufficient.

Jens ? I see no refcounting of the queue, but then we enter the deep guts of the block layer and all this is pretty much obscure to me. What can be done here ?

Ben.

#2 lore raw
Quoted 5 lines · Benjamin Herrenschmidt
Quoted 3 lines

The last step is bad - sooner or later the queue will be kfreed, and if there are bozos around that still have references, they would access random memory. It must be guaranteed that all references expired before the tear down begins. Just leaving a dead flag set is not sufficient.

Jens ? I see no refcounting of the queue,. . .

struct request_queue's kobj field perhaps?

#3 lore raw
Quoted 11 lines · Lou Langholtz
Quoted 8 lines · Benjamin Herrenschmidt
Quoted 6 lines

The last step is bad - sooner or later the queue will be kfreed, and if there are bozos around that still have references, they would access random memory. It must be guaranteed that all references expired before the tear down begins. Just leaving a dead flag set is not sufficient.

Jens ? I see no refcounting of the queue,. . .

struct request_queue's kobj field perhaps?

Queue still needs dynamically allocated for this to work, and it isn't. This is one of Al's projects, but he seems to be busy and/or away. It's pretty straight forward but pretty massive change, wonder if Linus could be talked into it...

Signature · 1 line
Jens Axboe