The state of Giant lock in the file systems?

[Gleb Kurtsou]

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.

> 
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"