NetBSD Problem Report #37668

From martin@duskware.de  Wed Jan  2 14:04:25 2008
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id B48BB63BD92
	for <gnats-bugs@gnats.netbsd.org>; Wed,  2 Jan 2008 14:04:25 +0000 (UTC)
Message-Id: <20080102140311.E07D063BD91@narn.NetBSD.org>
Date: Wed,  2 Jan 2008 14:03:11 +0000 (UTC)
From: ad@netbsd.org
Reply-To: ad@netbsd.org
To: netbsd-bugs-owner@NetBSD.org
Subject: lfs deadlocks, possibly due to v_numoutput leak
X-Send-Pr-Version: www-1.0

>Number:         37668
>Category:       kern
>Synopsis:       lfs deadlocks, possibly due to v_numoutput leak
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    dholland
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 02 14:05:02 +0000 2008
>Last-Modified:  Mon May 30 03:15:19 +0000 2016
>Originator:     Andrew Doran
>Release:        4.99.48
>Organization:
The NetBSD Project
>Environment:
n/a
>Description:
lfs file system with a high write rate will eventually deadlock.
Threads are waiting for v_numoutput to drain, perhaps because:

- the accounting is wrong
- or the buffers are never being flushed
- or flushed buffers are not being passed to lfs on completion

>How-To-Repeat:
tar cf - /usr/src | (cd /lfs; tar xf -)

>Fix:
Unknown

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->ad
Responsible-Changed-By: ad@netbsd.org
Responsible-Changed-When: Sat, 05 Jan 2008 02:36:06 +0000
Responsible-Changed-Why:
take


Responsible-Changed-From-To: ad->kern-bug-people
Responsible-Changed-By: ad@NetBSD.org
Responsible-Changed-When: Sun, 01 Feb 2009 17:03:19 +0000
Responsible-Changed-Why:
would rather finish zfs than waste further weeks on lfs


From: coypu@SDF.ORG
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/37668: lfs deadlocks, possibly due to v_numoutput leak
Date: Sun, 29 May 2016 14:05:39 +0000

 The reproduction step doesn't work for me (at least not right away)
 However, running these two commands does:

 tar cf - /not-lfs/src | (cd /lfs; tar xf -)

 # followed by..
 cd /lfs && echo garabage > conftest && rm conftest2 && \
   dd bs=3 count=1 < conftest

 ...encountered 'in the wild', when compiling packages,
 a common configure (libtool.m4) has:

 # _LT_PATH_DD
 # -----------
 # find a working dd
 m4_defun([_LT_PATH_DD],
 [AC_CACHE_CHECK([for a working dd], [ac_cv_path_lt_DD],
 [printf 0123456789abcdef0123456789abcdef >conftest.i
 cat conftest.i conftest.i >conftest2.i
 : ${lt_DD:=$DD}
 AC_PATH_PROGS_FEATURE_CHECK([lt_DD], [dd],
 [if "$ac_path_lt_DD" bs=32 count=1 <conftest2.i >conftest.out 2>/dev/null; then
   cmp -s conftest.i conftest.out \
   && ac_cv_path_lt_DD="$ac_path_lt_DD" ac_path_lt_DD_found=:
 fi])
 rm -f conftest.i conftest2.i conftest.out])
 ])# _LT_PATH_DD

From: coypu@SDF.ORG
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/37668: lfs deadlocks, possibly due to v_numoutput leak
Date: Sun, 29 May 2016 14:31:17 +0000

 Woops, meant:

 tar cf - /not-lfs/src | (cd /lfs; tar xf -)

 # followed by

 cd /lfs && echo garabage > conftest
 dd bs=3 count=1 < conftest > conftest2


 It'll eventually free itself up, but this is a way to trigger LFS
 problems. (increase block size to a whooping 32 to cause serious havoc!)

 (sorry for the noise ad.)

Responsible-Changed-From-To: kern-bug-people->dholland
Responsible-Changed-By: dholland@NetBSD.org
Responsible-Changed-When: Mon, 30 May 2016 03:15:19 +0000
Responsible-Changed-Why:
lfs


>Unformatted:

Home	PR Database Search