]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
MFC r329805: MFV r329803:
authormav <mav@FreeBSD.org>
Mon, 16 Apr 2018 03:48:37 +0000 (03:48 +0000)
committermav <mav@FreeBSD.org>
Mon, 16 Apr 2018 03:48:37 +0000 (03:48 +0000)
commit026ce2e11f8cd3116e11814a92ca0fec88be801c
tree1559e1d4f243a5eac2cd67234c02e01dc96dd6d6
parent32253781878f276b91c064399ca60806a1a885c7
MFC r329805: MFV r329803:
9080 recursive enter of vdev_indirect_rwlock from vdev_indirect_remap()

illumos/illumos-gate@bdfded42e66b9fc1395ff2401aa2952f7c44ae34

A scenario came up where a callback executed by vdev_indirect_remap() on a vdev, calls
vdev_indirect_remap() on the same vdev and tries to reacquire vdev_indirect_rwlock that
was already acquired from the first call to vdev_indirect_remap(). The specific scenario,
is that we want to remap a block pointer that is snapshoted but its dataset's remap_deadlist
is not cached. So in order to add it we issue a read through a vdev_indirect_remap() on the
same vdev, which brings up the aforementioned issue.

Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Approved by: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
Author: Serapheim Dimitropoulos <serapheim.dimitro@delphix.com>
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_indirect.c