The state of Giant lock in the file systems?

[Aditya Sarawgi]

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.