From owner-freebsd-current@FreeBSD.ORG Tue Aug 2 05:14:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21BFF106564A; Tue, 2 Aug 2011 05:14:34 +0000 (UTC) (envelope-from alex@zagrebin.ru) Received: from mail.zagrebin.ru (gw.zagrebin.ru [91.215.205.128]) by mx1.freebsd.org (Postfix) with ESMTP id B2F9F8FC08; Tue, 2 Aug 2011 05:14:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zagrebin.ru; s=mail; h=Content-Type:MIME-Version:Message-ID:Subject:Cc:To:From:Date; bh=l7yZn36CRGax4l5waVH//ZhZ79VpBvJZKjOjtHhtzmg=; b=T6yHHvjevRSkSCf8Q5ickJh6X4gKgj3lC/Kc9QWpOrZEokA8WLF3ojTzi1H4tQrVgRybkxpvP1rer3EWolJ1zohzNTHchMZdn+LrLq/gB3txTRycr/8tomW0SPHAuGsy1lyMImPqrzoou4MTusYd2Gp4Ol/B75gmy3eIxgYpfgY=; Received: from alex by mail.zagrebin.ru with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qo6sx-0002SC-Je; Tue, 02 Aug 2011 08:47:19 +0400 Date: Tue, 2 Aug 2011 08:47:19 +0400 From: Alexander Zagrebin To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20110802044718.GA8838@gw.zagrebin.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 02 Aug 2011 11:02:53 +0000 Cc: freebsd-current@freebsd.org Subject: ZFS v28: kernel panics while reading an extended attribute X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 05:14:34 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! It seems, I've found a bug in the ZFS v28 on the latest stable: if we have a snapshot with some files having an extended attributes, then attempt to read an extended attributes's value leads to a well reproducible kernel panic. The part of backtrace follows: #6 0xffffffff804bbe44 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0xffffffff80950ea7 in zil_commit (zilog=0x0, foid=5795917) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c:1497 #8 0xffffffff80979e6b in zfs_freebsd_read (ap=Variable "ap" is not available.) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:622 #9 0xffffffff80979750 in zfs_getextattr (ap=0xffffff80dd5d8820) at vnode_if.h:384 #10 0xffffffff8038921b in extattr_get_vp (vp=0xffffff0056a01588, attrnamespace=1, attrname=0xffffff80dd5d89a0 "DOSATTRIB", data=Variable "data" is not available.) at vnode_if.h:1332 It seems that ZIL isn't available for snapshots, but zfs_freebsd_read doesn't check this when calling zil_commit. The attached patch fixes this issue. Can anybody confirm this? -- Alexander Zagrebin --NzB8fVQJ5HfG6fxh Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="patch-zfs_vnops.c" --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c.orig 2011-08-01 23:04:07.358173627 +0400 +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c 2011-08-02 00:10:02.674585604 +0400 @@ -618,7 +618,8 @@ zfs_read(vnode_t *vp, uio_t *uio, int io /* * If we're in FRSYNC mode, sync out this znode before reading it. */ - if (ioflag & FRSYNC || zfsvfs->z_os->os_sync == ZFS_SYNC_ALWAYS) + if (zfsvfs->z_log && + (ioflag & FRSYNC || zfsvfs->z_os->os_sync == ZFS_SYNC_ALWAYS)) zil_commit(zfsvfs->z_log, zp->z_id); /* --NzB8fVQJ5HfG6fxh--