kern/160283: 'zfs list' does abort in make_dataset_handle

[Stef Walter]

>Number:         160283
>Category:       kern
>Synopsis:       'zfs list' does abort in make_dataset_handle
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Aug 29 16:00:24 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:     Stef Walter
>Release:        8.2-RELEASE-p2
>Organization:
>Environment:
FreeBSD m1.bay.npubs.net 8.2-RELEASE-p2 FreeBSD 8.2-RELEASE-p2 #0: Wed Jul 27 12:49:35 UTC 2011     sam at m1.bay.npubs.net:/usr/obj/usr/src/sys/RACK1  amd64
>Description:
After a failed zfs receive, zfs list now aborts in make_dataset_handle()
in libzfs.so.2.

# zfs list
Abort trap: 6 (core dumped)

The backtrace is:

#0  0x0000000800fe63cc in kill () from /lib/libc.so.7
#1  0x0000000800fe51cb in abort () from /lib/libc.so.7
#2  0x000000080067400f in make_dataset_handle () from /lib/libzfs.so.2
#3  0x0000000800674346 in zfs_iter_filesystems () from /lib/libzfs.so.2
#4  0x000000000040ad51 in ?? ()
#5  0x0000000800674354 in zfs_iter_filesystems () from /lib/libzfs.so.2
#6  0x000000000040ad51 in ?? ()
#7  0x000000080066642c in zfs_iter_root () from /lib/libzfs.so.2

Running on:

FreeBSD m1.bay.npubs.net 8.2-RELEASE-p2 FreeBSD 8.2-RELEASE-p2 #0: Wed Jul 27 12:49:35 UTC 2011     sam at m1.bay.npubs.net:/usr/obj/usr/src/sys/RACK1  amd64

'zfs scrub' did not fix the error. 'zfs create' and other zfs commands
still work, as do access to the various zfs file systems on this system.

After poking around a bit, I find that in make_dataset_handle()
zhp->zfs_dmustats.dds_type is equal to 0 (and this is the cause of the
abort). Additionally zhp->zfs_dmustats.dds_inconsistent is not TRUE.
>How-To-Repeat:
Hard to repeat. Depends on zfs recv aborting at specific times in specific circumstances, possibly involving prior reboots.
>Fix:
Will attach a patch which fixes the issue.

Patch attached with submission follows:

--- cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c.orig	2011-01-10 22:29:45.000000000 +0000
+++ cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c	2011-01-12 01:49:13.000000000 +0000
@@ -404,4 +404,24 @@
 	}
 
+	/*
+	 * We've managed to open the dataset and gather statistics.  Determine
+	 * the high-level type.
+	 */
+	if (zhp->zfs_dmustats.dds_type == DMU_OST_ZVOL)
+		zhp->zfs_head_type = ZFS_TYPE_VOLUME;
+	else if (zhp->zfs_dmustats.dds_type == DMU_OST_ZFS)
+		zhp->zfs_head_type = ZFS_TYPE_FILESYSTEM;
+	else
+		zhp->zfs_dmustats.dds_inconsistent = 1;
+
+	if (zhp->zfs_dmustats.dds_is_snapshot)
+		zhp->zfs_type = ZFS_TYPE_SNAPSHOT;
+	else if (zhp->zfs_dmustats.dds_type == DMU_OST_ZVOL)
+		zhp->zfs_type = ZFS_TYPE_VOLUME;
+	else if (zhp->zfs_dmustats.dds_type == DMU_OST_ZFS)
+		zhp->zfs_type = ZFS_TYPE_FILESYSTEM;
+	else
+		zhp->zfs_dmustats.dds_inconsistent = 1;
+
 	if (zhp->zfs_dmustats.dds_inconsistent) {
 		zfs_cmd_t zc = { 0 };
@@ -446,24 +466,4 @@
 	}
 
-	/*
-	 * We've managed to open the dataset and gather statistics.  Determine
-	 * the high-level type.
-	 */
-	if (zhp->zfs_dmustats.dds_type == DMU_OST_ZVOL)
-		zhp->zfs_head_type = ZFS_TYPE_VOLUME;
-	else if (zhp->zfs_dmustats.dds_type == DMU_OST_ZFS)
-		zhp->zfs_head_type = ZFS_TYPE_FILESYSTEM;
-	else
-		abort();
-
-	if (zhp->zfs_dmustats.dds_is_snapshot)
-		zhp->zfs_type = ZFS_TYPE_SNAPSHOT;
-	else if (zhp->zfs_dmustats.dds_type == DMU_OST_ZVOL)
-		zhp->zfs_type = ZFS_TYPE_VOLUME;
-	else if (zhp->zfs_dmustats.dds_type == DMU_OST_ZFS)
-		zhp->zfs_type = ZFS_TYPE_FILESYSTEM;
-	else
-		abort();	/* we should never see any other types */
-
 	zhp->zfs_hdl->libzfs_log_str = logstr;
 	zhp->zpool_hdl = zpool_handle(zhp);


>Release-Note:
>Audit-Trail:
>Unformatted: