nfs + msdosfs = crashes & panics

David Rhodus drhodus at machdep.com
Tue Apr 13 19:33:27 PDT 2004


On Apr 13, 2004, at 9:26 PM, Matthew Dillon wrote:

:On Tue, 13 Apr 2004 17:39:24 -0700
:Jeffrey Hsu <hsu at xxxxxxxxxxx> wrote:
:
:> You're probably indirecting though a non-existent proc-related
:> structure. The protocol threads don't have a proc structure 
associated
:> with them.  Before, there were a bunch of places which incorrectly
:> used curproc to check things like credentials.   All the places
:> are going to core dump now.  I've fixed a bunch of places which
:> incorrectly used curthread, but there are still some left.
:
:I was starting to wonder if it had something to do with the struct
:ucred... this would make sense... esp. considering it's an MS-DOS
:filesystem... i.e., it carries no user info on files.
:
:FWIW, it's the same behaviour with -mapall=catseye as without (catseye
:is the user who owns the /c directory, and mount_msdos treats that 
user
:as the owner of all files under it, when it's mounted.)
:
:-Chris

    Yup, that was it.   msdosfs_write() was getting proc from
    uio->uio_td->td_proc, but uio_td can be NULL.  In this case I just
    conditionalized it, the proc is being used to do filesize resource
    limit checks and I think we can safely say that we don't really 
care
    about that for msdosfs which stores no user cred info anyways, and
    doubly so when accessed from an NFS server.
Interesting, has anyone tried to do an umapfs overlay with nfs ? I know
most of the people in FreeBSD find umapfs to be offensive but it is
very nice when doing UID overlays between machines using nfs.
-DR






More information about the Bugs mailing list