getblk() has an old crufty API in which the logical block size is not a
authorMatthew Dillon <dillon@dragonflybsd.org>
Sat, 29 Jan 2005 19:17:06 +0000 (19:17 +0000)
committerMatthew Dillon <dillon@dragonflybsd.org>
Sat, 29 Jan 2005 19:17:06 +0000 (19:17 +0000)
commit21ab32bd5136ed2dc3034cb7b406e1310dbd18f7
treea7c155ccac61a9e0dc41337000f804df6969e09f
parentc98bc1f9cff9230208db7d1da80cbec6663ce889
getblk() has an old crufty API in which the logical block size is not a
well known quantity.  Device drivers standardize on using DEV_BSIZE (512),
while file ops are supposed to use mount->mnt_stat.f_iosize.

The existing code was testing for a non-NULL vnode->v_mountedhere field
but this field is part of a union and only valid for VDIR types.  It was being
improperly tested on non-VDIR vnode types.  In particular, if vn_isdisk()
fails due to the disk device being ripped out from under a filesystem,
the code would fall through and try to use v_mountedhere, leading to a
crash.  It also makes no sense to use the target mount to calculate the
block size for the underlying mount point's vnode, so this test has been
removed entirely.  The vn_isdisk() test has been replaced with an explicit
VBLK/VCHR test.

Finally, note that filesystems like UFS use varying buffer cache buffer
sizes for different areas of the same block device (e.g. bitmap areas,
inode area, file data areas, superblock), which is why DEV_BSIZE is being
used here.  What really needs to happen is for b_blkno to be entirely
removed in favor of a 64 bit offset.

Crash-Reported-by: Vyacheslav Bocharov <list@smz.com.ua>
sys/kern/vfs_bio.c