msdosfs not MPSAFE
Bruce Evans
brde at optusnet.com.au
Thu Jul 12 21:16:40 UTC 2007
On Thu, 12 Jul 2007, Kostik Belousov wrote:
> On Wed, Jul 11, 2007 at 12:08:19AM +1000, Bruce Evans wrote:
>> msdsofs has been broken since Giant locking for file systems (or syscalls)
>> was removed. It allows multiple threads to race accessing the shared
>> static buffer `nambuf' and related variables. This causes remarkably
>> [Add Giant locking]
>> Please fix this better. mbnambuf_init() could return a non-static buffer
>> that doesn't require locking. Deallocation would be painful. Note that
>> even the details for Giant locking can't be hidden in msdosfs_conv.c like
>> the current interfaces intend, since mbnambuf_init() is used a lot to
>> reinitialize an in-use buffer, and there is no interface to drop usage.
> It seems that msdosfs_lookup() can sleep, thus Giant protection would be
> lost.
It can certainly block in bread().
I now think this is not really an SMP bug. The nambuf* data structure
requires a long-term global lock, but it has never had one. The bug
seems to be relatively new. nambuf* is for multi-byte characters, not
for long names, and has only existed since 2003 (msdosfs_vnops.c 1.141,
etc.). I thought that long names were built up in nambuf, but they
are apparently built up in the directory entry. This should work for
multi-byte characters too -- don't translate anything until all the low-
level directory entries have been accumulated.
How does my adding Giant locking help? I checked that at least in
FreeBSD-~5.2-current, msdosfs_readdir() is already Giant-locked, so my
fix just increments the recursion count. What happens to recursively-
held Giant locks across sleeps? I think they should cause a KASSERT()
failure, but if they are handled by only dropping Giant once then my
fix might sort of work but sleeps would be broken generally.
Bruce
_______________________________________________
freebsd-bugs at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe at freebsd.org"
More information about the freebsd-fs
mailing list