cvs commit: src/sys/kern vfs_bio.c vfs_subr.c src/sys/sys buf.h proc.h src/sys/ufs/ffs ffs_snapshot.c

Don Lewis truckman at FreeBSD.org
Mon Oct 3 21:41:27 PDT 2005


truckman    2005-10-04 04:41:27 UTC

  FreeBSD src repository

  Modified files:        (Branch: RELENG_6)
    sys/kern             vfs_bio.c vfs_subr.c 
    sys/sys              buf.h proc.h 
    sys/ufs/ffs          ffs_snapshot.c 
  Log:
  MFC snaplk deadlock fix
          src/sys/kern/vfs_bio.c          1.495, 1.496
          src/sys/kern/vfs_subr.c         1.648
          src/sys/sys/buf.h               1.190, 1.191
          src/sys/sys/proc.h              1.436
          src/sys/ufs/ffs/ffs_snapshot.c  1.104, 1.105, 1.106
  
  Original commit messages:
  
      Log:
      Un-staticize runningbufwakeup() and staticize updateproc.
  
      Add a new private thread flag to indicate that the thread should
      not sleep if runningbufspace is too large.
  
      Set this flag on the bufdaemon and syncer threads so that they skip
      the waitrunningbufspace() call in bufwrite() rather than than
      checking the proc pointer vs. the known proc pointers for these two
      threads.  A way of preventing these threads from being starved for
      I/O but still placing limits on their outstanding I/O would be
      desirable.
  
      Set this flag in ffs_copyonwrite() to prevent bufwrite() calls from
      blocking on the runningbufspace check while holding snaplk.  This
      prevents snaplk from being held for an arbitrarily long period of
      time if runningbufspace is high and greatly reduces the contention
      for snaplk.  The disadvantage is that ffs_copyonwrite() can start
      a large amount of I/O if there are a large number of snapshots,
      which could cause a deadlock in other parts of the code.
  
      Call runningbufwakeup() in ffs_copyonwrite() to decrement runningbufspace
      before attempting to grab snaplk so that I/O requests waiting on
      snaplk are not counted in runningbufspace as being in-progress.
      Increment runningbufspace again before actually launching the
      original I/O request.
  
      Prior to the above two changes, the system could deadlock if enough
      I/O requests were blocked by snaplk to prevent runningbufspace from
      falling below lorunningspace and one of the bawrite() calls in
      ffs_copyonwrite() blocked in waitrunningbufspace() while holding
      snaplk.
  
      See <http://www.holm.cc/stress/log/cons143.html>
  
      Revision  Changes    Path
      1.495     +3 -3      src/sys/kern/vfs_bio.c
      1.648     +2 -1      src/sys/kern/vfs_subr.c
      1.190     +1 -0      src/sys/sys/buf.h
      1.436     +1 -1      src/sys/sys/proc.h
      1.104     +16 -4     src/sys/ufs/ffs/ffs_snapshot.c
  
      Log:
      Un-staticize waitrunningbufspace() and call it before returning from
      ffs_copyonwrite() if any async writes were launched.
  
      Restore the threads previous TDP_NORUNNINGBUF state before returning
      from ffs_copyonwrite().
  
      Revision  Changes    Path
      1.496     +1 -1      src/sys/kern/vfs_bio.c
      1.191     +1 -0      src/sys/sys/buf.h
      1.105     +13 -1     src/sys/ufs/ffs/ffs_snapshot.c
  
      Log:
      Correct previous commit to fix the sense of the TDP_NORUNNINGBUF
      check in ffs_copyonwrite() that is a precondition for calling
      waitrunningbufspace().
  
      Pointed out by: tegge
      Pointy hat to:  truckman
      MFC after:      3 days
  
      Revision  Changes    Path
      1.106     +1 -1      src/sys/ufs/ffs/ffs_snapshot.c
  
  Approved by:    re (scottl)
  
  Revision   Changes    Path
  1.491.2.3  +4 -4      src/sys/kern/vfs_bio.c
  1.635.2.9  +2 -1      src/sys/kern/vfs_subr.c
  1.187.2.3  +2 -0      src/sys/sys/buf.h
  1.432.2.2  +1 -1      src/sys/sys/proc.h
  1.103.2.1  +28 -4     src/sys/ufs/ffs/ffs_snapshot.c


More information about the cvs-src mailing list