NFS fix from DragonFly

From: Nate Lawson (nate_at_root.org)
Date: 04/20/04

  • Next message: Nate Lawson: "resolver fix from DF"
    Date: Tue, 20 Apr 2004 13:14:06 -0700 (PDT)
    To: current@freebsd.org
    
    

    Curious if we should address this?

    dillon 2004/03/12 19:13:53 PST

    DragonFly src repository

      Modified files:
        sys/vfs/nfs nfs.h nfs_socket.c
      Log:
      Fix a bunch of NFS races. These races existed in FreeBSD 4.x but are more
      likely to occur now due to the additional thread switching that DragonFly
      performs when doing things like sending UDP packets. Three bugs are
      being fixed:

      * nfs_request() adds the request to the nfs_timer queue before doing initial
        processing (e.g. transmission) of the request. The initial transmission of
        the request will race between nfs_request and nfs_timer, potentially causing
        the congestion window calculation (nm_sent) to be bumped twice instead of
        once. This eventually closes the congestion window permanently and
        causes the NFS mount to freeze. (Additionally the request could be
        transmitted twice unnecessarily, also fixed).

      * Updates to rep->r_flags and nmp->nm_sent were not being properly protected
        against nfs_timer due to splsoftclock() being released too early. All
        such accesses are now protected.

      * nfs_reply() depends on nfs_rcvlock to do an interlock check to see if the
        request has already been replied, but nfs_rcvlock() only does this if it
        cannot immediately get the receiver lock. The problem is that the NFS
        code in between request transmission and nfs_reply() can block, potentially
        allowing a reply to be returned to another nfsiod. The NFS receiver winds
        up getting stuck waiting for a reply that has already been returned.
        nfs_rcvlock() now unconditionally checks to see if the reply has already
        occured before entering the loop.

      Revision Changes Path
      1.6 +9 -8 src/sys/vfs/nfs/nfs.h
      1.14 +37 -14 src/sys/vfs/nfs/nfs_socket.c

    http://www.dragonflybsd.org/cvsweb/src/sys/vfs/nfs/nfs.h.diff?r1=1.5&r2=1.6&f=h
    http://www.dragonflybsd.org/cvsweb/src/sys/vfs/nfs/nfs_socket.c.diff?r1=1.13&r2=1.14&f=h
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  • Next message: Nate Lawson: "resolver fix from DF"

    Relevant Pages

    • NFS client side bug fixes that probably apply to FBsd-4 and 5.
      ... Fix a bunch of NFS races. ... likely to occur now due to the additional thread switching that DragonFly ... processing (e.g. transmission) of the request. ...
      (freebsd-hackers)
    • [GIT] NFS client updates for 2.6.22...
      ... commit a19b89cad51b6f0da8f4bafdfdcfb10264cbcdea ... should remove any cached ACL so that any subsequent request for the ACL ... NFS: Fix directory caching problem - with test case and patch. ...
      (Linux-Kernel)
    • NFS negative dentry caching problem in 2.4.21, and patch
      ... Below is a description of the problem and a suggested patch. ... Hat support request, so when it says "RHEL3", think "Linux 2.4.21". ... We have a big problem with how the NFS client code in RHEL3 ... from an NFS server (doesn't matter what kind, ...
      (Linux-Kernel)
    • Re: NFS Still broken in 2.6.x?
      ... I'm running into a bit of trouble with NFS on 2.6. ... The patch below should fix this problem. ... Subject: Readahead algorithm problems again... ... 32k max, 4k request ...
      (Linux-Kernel)
    • Re: Compressing file system, NFS
      ... > not given a request of dealing with an entire file, ... say redoing nullfs to slip in compression. ... > supports NFS, and it supports very large files and disk farms. ... Novell NetWare is no option for me. ...
      (comp.unix.bsd.freebsd.misc)