From owner-freebsd-fs@FreeBSD.ORG Mon Nov 8 18:16:14 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 62D8B1065693; Mon, 8 Nov 2010 18:16:14 +0000 (UTC) (envelope-from sarawgi.aditya@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 057F58FC12; Mon, 8 Nov 2010 18:16:13 +0000 (UTC) Received: by gxk9 with SMTP id 9so3767691gxk.13 for ; Mon, 08 Nov 2010 10:16:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=ZvfRvxD+AWPjqTosS2n/4a1mmbAGx28wQ3OTCTC3S1s=; b=gqGWVnl/HTXj/fV0zAOnXzy3Ze9cuGUcgqXLcld5H0JsqN6Mwzwy8Jx3S1oguJ/yth RING6XwWByB4n4jXZdTp3vS7ub25/GIxacBGApLWB+4C0ABo4gBSiO82KKHAMxWZ9qwb l+LRoKMGRymYL6EQSk8poziNg4pM38RxWqFQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=kbKh8QwRk7RQkI/zkr/7M0BH59f6PqZzGOCSSQsXQQAVvI/uwB2AMY+1fyh/0FX3oj 0wwBh13TsxMP/geP+3C0ufP6joj2abTuU8gN2Ogd3nVnZQDMSpKyoHfKVbZwMylqkAZa rIRp3sX2OfQnEFEoVBS5VtEv1Cc4ndtyrtO74= Received: by 10.150.146.17 with SMTP id t17mr939166ybd.337.1289240173058; Mon, 08 Nov 2010 10:16:13 -0800 (PST) Received: from earth ([183.87.49.109]) by mx.google.com with ESMTPS id v8sm113910yba.14.2010.11.08.10.16.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Nov 2010 10:16:12 -0800 (PST) Date: Mon, 8 Nov 2010 23:47:49 +0530 From: Aditya Sarawgi To: Gleb Kurtsou Message-ID: <20101108181748.GD2066@earth> References: <20101108143130.GA2799@tops> <20101108172136.GA2066@earth> <20101108180028.GA3964@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101108180028.GA3964@tops> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, Ivan Voras Subject: Re: The state of Giant lock in the file systems? 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: Mon, 08 Nov 2010 18:16:14 -0000 On Mon, Nov 08, 2010 at 08:00:28PM +0200, Gleb Kurtsou wrote: > On (08/11/2010 22:51), Aditya Sarawgi wrote: > > On Mon, Nov 08, 2010 at 04:31:30PM +0200, Gleb Kurtsou wrote: > > > On (08/11/2010 13:28), Ivan Voras wrote: > > > > I was looking at fusefs sources and there is a dance it does with the > > > > Giant lock which looks fishy. > > > It's intended to be fishy. No kernel level locks should be held before > > > returning to userland, in other words on each syscall vnode is locked (+ > > > Gaint lock for fs if needed), than it's unlocked by filesystem and > > > relocked upon callback from userspace. puffs is MPSAFE if that could be > > > of any help for you. > > > > > > > Grepping for "-ir giant" in /sys/fs on 8-stable shows only a handful of > > > > mentionings, but if I understand it correctly only these "active" instances: > > > > > > > > 1) one set of mtx_assert() calls on it in pseudofs, which I can't figure > > > > out what they're guarding > > > > 2) some manual locking and unlocking in nfsclient which appears to only > > > > guard printf() (???) > > > Somewhat unrelated, but. Does NFS client unlock vnodes while > > > sending/waiting for RCP reply? I thought it does, but I'm not sure. > > > > > > > 3) some more locking in nfsserver which apparently is only there to > > > > guard the underlying local file system > > > > 4) coda, which appears to be the only one marked with D_NEEDGIANT, but > > > > doesn't do much of its own interfacing with it > > > > > > > > Except for these, is there any more magic that would need to be resolved > > > > to excise Giant from VFS? > > > Kostik was working on it. > > > > > > > Would it be correct to think that coda is the single biggest obstacle? > > > Filesystem should be marked as MPSAFE, it's not D_NEEDGIANT flag but > > > MNTK_MPSAFE. A lot of filesystems are still locked by Gaint, i.e ext2fs, > > > smbfs, nwfs, ntfs, etc. > > > > > > > ext2fs on 9-CURRENT is MPSAFE. > Didn't check it for a while, sorry. > No Problem :) > But there's a deadlock in ext2_rename, it doesn't following vnode > locking order (parent -> child) by doing vn_lock(fvp). The problem can't > be fixed in a generic way at the moment, the best solution would > probably be to follow UFS and unlock all vnodes, lock one-by-one and > relookup. The same applies to tmpfs. > Thanks for pointing this out. Saw some mails related to this earlier. Will take a look.