The state of Giant lock in the file systems?
kostikbel at gmail.com
Mon Nov 8 15:10:33 UTC 2010
On Mon, Nov 08, 2010 at 10:04:59AM -0500, John Baldwin wrote:
> On Monday, November 08, 2010 7:28:26 am Ivan Voras wrote:
> > I was looking at fusefs sources and there is a dance it does with the
> > Giant lock which looks fishy.
> > 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() (???)
> > 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?
> > Would it be correct to think that coda is the single biggest obstacle?
> Err, all the VFS_LOCK_GIANT() stuff for filesystems that do not have
> MNTK_MPSAFE set. I believe the currently MPSAFE fs's are UFS, ZFS, MSDOSFS,
> CD9660, UDF, NFS client, and devfs. I think all others are !MPSAFE still.
pseudofs-based fses are mpsafe too.
I already claimed several times that I will remove VFS_LOCK_GIANT
after smbfs is locked. Patch for removal is sitting in my repository
for almost a year.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20101108/85d2fe7b/attachment.pgp
More information about the freebsd-fs