From owner-freebsd-fs Mon May 13 3:43:18 2002 Delivered-To: freebsd-fs@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.19.129.142]) by hub.freebsd.org (Postfix) with ESMTP id AA8DD37B406; Mon, 13 May 2002 03:43:05 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id 0698428B58; Mon, 13 May 2002 17:42:53 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id F20BF28B56; Mon, 13 May 2002 17:42:53 +0700 (ALMST) Date: Mon, 13 May 2002 17:42:53 +0700 (ALMST) From: Boris Popov To: "Semen A. Ustimenko" Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, "Flood, Jim" Subject: Re: NULLFS-related possible deadlock + fix proposal In-Reply-To: <20020511005932.S1705-100000@def.the.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 11 May 2002, Semen A. Ustimenko wrote: > DEADLOCK... Indeed, weird situation. Nice analysis, btw :) > Make vn_lock() in vrele() lock vnode only LK_THISLAYER. Obviously, the > NULLFS and other stacking FSes will have to deal with this in their > VOP_INACTIVE() handlers. This changes won't touch real FSes as they ignore > the LK_THISLAYER, don't they? Yes, you're correct in that LK_THISLAYER currently used only by "stacked" filesystem(s) and it used exactly for such situations to avoid deadlocks. The proposed solution may even work without any additional code because null_inactive() performs its own management on the lower vnode locking. -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message