From owner-freebsd-fs@FreeBSD.ORG Tue Sep 7 22:21:49 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA97310656C7; Tue, 7 Sep 2010 22:21:49 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [64.81.247.49]) by mx1.freebsd.org (Postfix) with ESMTP id CB5E78FC12; Tue, 7 Sep 2010 22:21:49 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id o87MB4Tg020746; Tue, 7 Sep 2010 15:11:04 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201009072211.o87MB4Tg020746@chez.mckusick.com> To: Ivan Voras In-reply-to: Date: Tue, 07 Sep 2010 15:11:04 -0700 From: Kirk McKusick Cc: freebsd-fs@freebsd.org Subject: Re: kern/150143: [patch][tmpfs] Source directory vnode can disappear before locking it in tmpfs_rename X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 22:21:50 -0000 > To: freebsd-fs@freebsd.org > From: Ivan Voras > Date: Tue, 07 Sep 2010 12:07:31 +0200 > Subject: Re: kern/150143: [patch][tmpfs] Source directory vnode can disappear > before locking it in tmpfs_rename > > On 09/06/10 09:08, linimon@FreeBSD.org wrote: > > Synopsis: [patch][tmpfs] Source directory vnode can disappear before locking it in tmpfs_rename > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-fs > > Responsible-Changed-By: linimon > > Responsible-Changed-When: Mon Sep 6 07:07:55 UTC 2010 > > Responsible-Changed-Why: > > Over to maintainer(s). > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=150143 > > Can someone look at the patch in this PR, please? > > I've tested it but don't want to commit it without someone reviewing it > (though I could commit it if the potential reviewer is busy with other > things). I have not worked with tmpfs, so may not be the best person to review this patch. But I have spent considerable time in ufs_rename, so am familiar with the problems associated with rename. In reviewing your patch, it looks like a reasonable approach to the problem. While I do not have enough context to convince myself that it will fully fix the problem, it certainly should help rename work better. Kirk McKusick