getblk doesn't lock buffer. It only increments reference count. The caller
of getblk is suposed to do any locking.
> and until the caller is done with it nothing can do io on that
> block.
There can be pending read request if
- user reads device directly, or
- filesystem uses asynchonous i/o (breada or ll_rw_block)
> So there are (hopefully) no races of the kind you described in
> current or future implementation of buffer cache (as long as it does not
> deviate from old good SVR3 thing described in Bach's book).
Look at the code:
struct buffer_head * getblk(kdev_t dev, int block, int size)
{
struct buffer_head * bh;
int isize;
repeat:
bh = get_hash_table(dev, block, size);
if (bh) {
if (!buffer_dirty(bh)) {
bh->b_flushtime = 0;
}
return bh;
}
...
There is not (and should not be) any serialization in getblk. The
filesystem should call wait_on_buffer(bh), after getblk()ing, but it
doesn't.
Mikulas Patocka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/