summaryrefslogtreecommitdiffstats
path: root/sys/kern/vfs_subr.c
diff options
context:
space:
mode:
authorkib <kib@FreeBSD.org>2014-12-08 16:42:34 +0000
committerkib <kib@FreeBSD.org>2014-12-08 16:42:34 +0000
commit0957112e3c431e30f0931bb908df03cded76c4d2 (patch)
tree52db55840d8f50b84b63536fb7879df7e583f001 /sys/kern/vfs_subr.c
parente83a8b4fa1e916a1dfd6ffe59024ef83cd10f294 (diff)
downloadFreeBSD-src-0957112e3c431e30f0931bb908df03cded76c4d2.zip
FreeBSD-src-0957112e3c431e30f0931bb908df03cded76c4d2.tar.gz
When getnewbuf_reuse_bp() is called to reclaim some (clean) buffer,
the vnode owning the buffer is not locked. More, it cannot be locked safely, since getnewbuf_reuse_bp() is called from newbuf(), and some other vnode is already locked, for which reused buffer will be reassigned. As the consequence, reclamation of the owning vnode could go in parallel, in particular, the call to vnode_destroy_vobject(), which deallocates the vm object and zeroes the v_bufobj->bo_object. Note that the pages wired by the buffer are left wired and can be safely freed by the vfs_vmio_release() without the need for the vm object lock. Also, seeing stale pointer to the v_object is safe due to vm object type stability. Check for bo_bufobj != NULL and cache the value in local variable to avoid trying to lock NULL vm object. Reported and tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week
Diffstat (limited to 'sys/kern/vfs_subr.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud