[PATCH] Re: bin/160400: zfs(1): zfs rename dumps core

Martin Matuska mm at FreeBSD.org
Wed Sep 28 09:00:24 UTC 2011


The following reply was made to PR bin/160400; it has been noted by GNATS.

From: Martin Matuska <mm at FreeBSD.org>
To: bug-followup at FreeBSD.org
Cc: zfs-devel at FreeBSD.org
Subject: [PATCH] Re: bin/160400: zfs(1): zfs rename dumps core
Date: Wed, 28 Sep 2011 10:59:06 +0200

 This is a multi-part message in MIME format.
 --------------020904070709010904030807
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 7bit
 
 The reproduction of this issue can be simplified and similiar case has
 already been reported on freebsd-fs@:
 http://lists.freebsd.org/pipermail/freebsd-fs/2010-September/009379.html
 http://lists.freebsd.org/pipermail/freebsd-fs/2011-August/012291.html
 
 It is important that the mountpoint of the dataset to be renamed is set
 to none or legacy, otherwise this assertion is not triggered.
 
 # zfs create -o mountpoint=none tank/a
 # zfs create tank/a/b
 # zfs rename tank/a tank/c
 Assertion failed: (!clp->cl_alldependents), file
 /usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_changelist.c,
 line 470.
 Abort (core dumped)
 
 As to my code examination, the assertion in libzfs_changelist.c:
 change_one() is inproper or invalid. The code path is called with
 clp->cl_sorted = B_FALSE and  cl_alldependents = B_TRUE from
 changelist_gather() if mountpoint is legacy or none.
 
 This misbehaviour was introduced in this OpenSolaris commit:
 
 changeset:   10196:210962933dfd
 user:        William Gorrell <william.gorrell at sun.com>
 date:        Wed Jul 29 08:49:33 2009 -0600
 summary:     6612218 inherited zfs set mountpoint mounts children before
 parent
 
 https://github.com/illumos/illumos-gate/commit/3cc4a7920cf40de22a5c8c465a4676b2b7f620dd#usr/src/lib/libzfs/common/libzfs_changelist.c
 
 I am generally putting in question why that assertion was in this place
 at it concerns exclusively the case with mountpoint=none or
 mountpoint=legacy and it manages only the order of the datasets being
 processed. I suggest removing the assertion as we can safely try to
 unmount the dependent filesystems.
 
 Please review the attached patch.
 
 -- 
 Martin Matuska
 FreeBSD committer
 http://blog.vx.sk
 
 
 --------------020904070709010904030807
 Content-Type: text/plain;
  name="libzfs_changelist.c.patch"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
  filename="libzfs_changelist.c.patch"
 
 SW5kZXg6IGNkZGwvY29udHJpYi9vcGVuc29sYXJpcy9saWIvbGliemZzL2NvbW1vbi9saWJ6
 ZnNfY2hhbmdlbGlzdC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGNkZGwvY29udHJpYi9vcGVuc29s
 YXJpcy9saWIvbGliemZzL2NvbW1vbi9saWJ6ZnNfY2hhbmdlbGlzdC5jCShyZXZpc2lvbiAy
 MjU2ODkpCisrKyBjZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvbGliL2xpYnpmcy9jb21tb24v
 bGliemZzX2NoYW5nZWxpc3QuYwkod29ya2luZyBjb3B5KQpAQCAtNDY3LDcgKzQ2Nyw2IEBA
 IGNoYW5nZV9vbmUoemZzX2hhbmRsZV90ICp6aHAsIHZvaWQgKmRhdGEpCiAJCQkgKiBUaGlz
 IGlzIG5lY2Vzc2FyeSB3aGVuIHRoZSBvcmlnaW5hbCBtb3VudHBvaW50CiAJCQkgKiBpcyBs
 ZWdhY3kgb3Igbm9uZS4KIAkJCSAqLwotCQkJQVNTRVJUKCFjbHAtPmNsX2FsbGRlcGVuZGVu
 dHMpOwogCQkJdmVyaWZ5KHV1X2xpc3RfaW5zZXJ0X2JlZm9yZShjbHAtPmNsX2xpc3QsCiAJ
 CQkgICAgdXVfbGlzdF9maXJzdChjbHAtPmNsX2xpc3QpLCBjbikgPT0gMCk7CiAJCX0K
 --------------020904070709010904030807--


More information about the freebsd-bugs mailing list