AFAIR, the underlying problem here was that in some cases, ie. when the
BLOCK_FLAGS_NOREAD flag is used with block_get(), the library will not
attempt to consult the block device and thus will not have a chance of
knowing the block is over the limit. It will happily instantiate a new
block beyond the end of the device and will fail only when it is too
late when it tries to write such a block back to the device.
Thus, it is preferable for the real offender to get a non-deferred error
from block_get() rather than later in block_put() or, even worse, for
someone else to get a deferred error in block_get().
True, and the patch in its current form will prevent you from
allocating the block, regardless of the flag.
I agree with Jakub, the bounds should be checked as soon as possible
(e.g. in block_get()), because libblock can keep track of the current
size of the device all the time. And any potential error should be
handled ASAP, not deferred to some possibly unrelated caller.
This approach does not prevent the device from growing/shrinking,
because there can be always some kind of notification mechanism. It also
does not prevent all possible kinds of races (e.g. allocating a block,
then shrinking the device, then trying to flush the block beyond the new
boundary), but at least it is not racy by design.
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
