Messages in this thread |  | | Date | Sun, 11 Nov 2001 11:13:55 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [CFT][PATCH] long-living cache for block devices |
| |
On Sun, 11 Nov 2001, Alexander Viro wrote: > > As it is, driver has a right to destroy any internal data structures as > soon as the last ->release() is called. None of them expect requests > coming in after that and frankly, that makes sense.
New requests will not be coming in - not for read-ahead, not for anything else.
There may be old requests that haven't finished, of course. And there may be requests on the request queue that the driver hasn't even looked at yet (Hmm.. I'm not sure that latter one is right - we must have done the device sync anyway, and that will unplug the requests queue etc).
But there cannot be any users that are still adding requests. That would be a bug regardless.
We might want to make sure that the request queue is truly empty, that's for sure. That's a driver-level thing that makes sense, and that should probably be part of the logic that does the bdev sync. After all, that queue should be a per-driver thing anyway (right now it isn't, but hey, that's for all the wrong historical reasons rather than anything else).
> IOW, if there is any point in _having_ ->release() at all, we'd better > make sure that nothing will bother the driver between the final ->release() > and the next ->open().
I think the "no bother" is true regardless of whether we explicitly destroy buffers or not. And quite frankly, I'd rather _not_ hide bugs by waiting for requests that shouldn't be there in the first place.
Linus
- 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/
|  |