From owner-freebsd-fs@FreeBSD.ORG  Fri Oct  5 10:50:54 2012
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id C6CF6106566B;
	Fri,  5 Oct 2012 10:50:54 +0000 (UTC) (envelope-from avg@FreeBSD.org)
Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140])
	by mx1.freebsd.org (Postfix) with ESMTP id DFC2C8FC0C;
	Fri,  5 Oct 2012 10:50:53 +0000 (UTC)
Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua
	[212.40.38.100])
	by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA28434;
	Fri, 05 Oct 2012 13:50:52 +0300 (EEST)
	(envelope-from avg@FreeBSD.org)
Received: from localhost ([127.0.0.1])
	by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD))
	id 1TK5Ua-000Ozt-3F; Fri, 05 Oct 2012 13:50:52 +0300
Message-ID: <506EBB8B.2000800@FreeBSD.org>
Date: Fri, 05 Oct 2012 13:50:51 +0300
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
	rv:15.0) Gecko/20120913 Thunderbird/15.0.1
MIME-Version: 1.0
To: freebsd-fs@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>
References: <505DB4E6.8030407@smeets.im>
	<20120924224606.GE79077@ithaqua.etoilebsd.net>
	<20120925090840.GD35915@deviant.kiev.zoral.com.ua>
	<20120929154101.GK1402@garage.freebsd.pl>
	<20120930122403.GB35915@deviant.kiev.zoral.com.ua>
	<506BFA5B.9060103@FreeBSD.org>
In-Reply-To: <506BFA5B.9060103@FreeBSD.org>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: 
Subject: Re: panic: _sx_xlock_hard: recursed on non-recursive sx
 zfsvfs->z_hold_mtx[i]
 @ ...cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1407
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Oct 2012 10:50:54 -0000

on 03/10/2012 11:42 Andriy Gapon said the following:
> on 30/09/2012 15:24 Konstantin Belousov said the following:
>> The postponing of the reclaim when vnode reserve goes low to the vnlru 
>> process does not solve anything, since you only change the recursion into 
>> the deadlock.
>>
>> I discussed an approach for this issue with avg. Basic idea is presented in
>> the untested patch below. You can specify that some count of the free
>> vnodes must be present for some dynamic scope, started by 
>> getnewvnode_reserve() function. While staying inside the reserved pool,
>> getnewvnode() calls would not recurse into vnlru(). The scope is finished
>> with getnewvnode_drop_reserve().
>>
>> The getnewvnode_reserve() shall be called while no locks are held.
>>
>> What do you think ?
> 
> Here is a patch that makes use of the getnewvnode_reserve API in ZFS:
> http://people.freebsd.org/~avg/zfs-getnewvnode.diff
> 

BTW, my impression is that this problem is a comeback of the original
zfs_reclaim problem, but now in zfs_inactive (thanks to help from nullfs).
So, with the approach that Kostik designed and which fixes zfs_inactive,
zfs_reclaim should now be safe and should no longer require the taskqueue hack.
There should never be a recursion back into ZFS via getnewvnode.

-- 
Andriy Gapon