From owner-freebsd-current@FreeBSD.ORG Sun May 26 20:52:16 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5E5ACEE2; Sun, 26 May 2013 20:52:16 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [46.33.159.39]) by mx1.freebsd.org (Postfix) with ESMTP id A8760D72; Sun, 26 May 2013 20:52:14 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.87,746,1363132800"; d="scan'208";a="4997689" Received: from lonpex01cl01.citrite.net ([10.30.203.101]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/AES128-SHA; 26 May 2013 20:52:10 +0000 Received: from [192.168.1.30] (10.30.203.1) by LONPEX01CL01.citrite.net (10.30.203.101) with Microsoft SMTP Server id 14.2.342.3; Sun, 26 May 2013 21:52:08 +0100 Message-ID: <51A275F7.9030401@citrix.com> Date: Sun, 26 May 2013 22:52:07 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jilles Tjoelker Subject: Re: FreeBSD-HEAD gets stuck on vnode operations References: <5190CBEC.5000704@citrix.com> <20130514163149.GS3047@kib.kiev.ua> <51927143.4080102@citrix.com> <201305201434.55406.jhb@freebsd.org> <51A0FA43.2040503@citrix.com> <51A26245.9060707@citrix.com> <20130526202058.GA40375@stack.nl> In-Reply-To: <20130526202058.GA40375@stack.nl> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.30.203.1] Cc: Konstantin Belousov , freebsd-current@freebsd.org, "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 26 May 2013 20:52:16 -0000 On 26/05/13 22:20, Jilles Tjoelker wrote: > Instead of a pause() that may be too short or too long, how about > waiting for the necessary lock? In other words, replace the kern_yield() > call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach > to acquire two locks without imposing an order between them. Since there might be more than one locked vnode, waiting on a specific locked vnode seemed rather arbitrary, but I agree that the pause is also rather arbitrary. Also, can we be sure that the v_interlock mutex will not be destroyed while the syncer process is waiting for it to be unlocked? > I expect blocking on a mutex to be safe enough; a mutex may not be held > across waiting for hardware or other events. >