Date: Mon, 13 Apr 2009 12:56:34 -0700 From: Tim Kientzle <kientzle@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r189967 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Message-ID: <49E398F2.7090604@freebsd.org> In-Reply-To: <200903181406.32619.jhb@freebsd.org> References: <200903181619.n2IGJifl031031@svn.freebsd.org> <200903181406.32619.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Wednesday 18 March 2009 12:19:44 pm John Baldwin wrote: >> Author: jhb >> Date: Wed Mar 18 16:19:44 2009 >> New Revision: 189967 >> URL: http://svn.freebsd.org/changeset/base/189967 >> >> Log: >> The zfs_get_xattrdir() function is used to find the extended attribute >> directory for a znode. When the directory already exists, it returns a >> referenced but unlocked vnode. When a directory does not yet exist, it >> calls zfs_make_xattrdir() to create a new one. zfs_make_xattrdir() returns >> the vnode both referenced and and locked and zfs_get_xattrdir() was leaking >> this vnode lock to its callers. Fix this by dropping the vnode lock if >> zfs_make_xattrdir() successfully creates a new extended attribute >> directory. > > This should fix the panics with ZFS and tar + EA. Thanks. One point I'm curious about. This problem was originally triggered by calls to extattr_list_fd(). This seems to imply that any call to extattr_list_fd() will allocate an extended attribute directory if it doesn't already exist. This is surprising. It also raises questions about both performance (tar now does extattr_list_fd() for every file being archived) and operation with read-only mounts. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49E398F2.7090604>