Skip site navigation (1)Skip section navigation (2)
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>