]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit - sys/boot/i386/libi386/multiboot.h
MFV r322223: 8378 crash due to bp in-memory modification of nopwrite block
authorAndriy Gapon <avg@FreeBSD.org>
Tue, 8 Aug 2017 10:46:51 +0000 (10:46 +0000)
committerAndriy Gapon <avg@FreeBSD.org>
Tue, 8 Aug 2017 10:46:51 +0000 (10:46 +0000)
commitb4e4140d13a6291e0ec72b1bc3510937d0d3d144
tree8be04ae35a48d7a127f5647f3a16d8b6723c0583
parentc6fb3642931ed1c777e42d7aecbd8d7b3da32d3d
parent28bfd86184e7e2e5cb2271c9eda6df27573f5f78
MFV r322223: 8378 crash due to bp in-memory modification of nopwrite block

illumos/illumos-gate@b7edcb940884114e61382937505433c4c38c0278
https://github.com/illumos/illumos-gate/commit/b7edcb940884114e61382937505433c4c38c0278

https://www.illumos.org/issues/8378
  The problem is that zfs_get_data() supplies a stale zgd_bp to dmu_sync(), which
  we then nopwrite against.
  zfs_get_data() doesn't hold any DMU-related locks, so after it copies db_blkptr
  to zgd_bp, dbuf_write_ready()
  could change db_blkptr, and dbuf_write_done() could remove the dirty record.
  dmu_sync() then sees the stale
  BP and that the dbuf it not dirty, so it is eligible for nop-writing.
  The fix is for dmu_sync() to copy db_blkptr to zgd_bp after acquiring the
  db_mtx. We could still see a stale
  db_blkptr, but if it is stale then the dirty record will still exist and thus
  we won't attempt to nopwrite.

Reviewed by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Approved by: Robert Mustacchi <rm@joyent.com>
Author: Matthew Ahrens <mahrens@delphix.com>

MFC after: 2 weeks
cddl/contrib/opensolaris/cmd/ztest/ztest.c
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c