Date: Tue, 4 Oct 2005 04:41:27 +0000 (UTC) From: Don Lewis <truckman@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: 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 Message-ID: <200510040441.j944fRPM051152@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510040441.j944fRPM051152>