From owner-svn-src-stable-10@FreeBSD.ORG Sat Oct 4 04:09:05 2014 Return-Path: Delivered-To: svn-src-stable-10@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 988954F2; Sat, 4 Oct 2014 04:09:05 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 683708E5; Sat, 4 Oct 2014 04:09:04 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XaGeP-000KRl-NJ; Sat, 04 Oct 2014 04:08:57 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9448uMD022630; Fri, 3 Oct 2014 22:08:56 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/UUThfTFteRu4pWOmYWTkC X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: svn commit: r272372 - stable/10/bin/rm From: Ian Lepore To: NGie Cooper In-Reply-To: References: <201410011618.s91GIfR5071251@svn.freebsd.org> <20141002141656.Y1807@besplex.bde.org> <20141002061628.GO1275@hub.FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Oct 2014 22:08:55 -0600 Message-ID: <1412395735.12052.104.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "src-committers@freebsd.org" , svn-src-stable-10@freebsd.org, svn-src-stable@freebsd.org, "svn-src-all@freebsd.org" , Glen Barber , Bruce Evans X-BeenThere: svn-src-stable-10@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for only the 10-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 04:09:05 -0000 On Wed, 2014-10-01 at 23:25 -0700, NGie Cooper wrote: > On Wed, Oct 1, 2014 at 11:16 PM, Glen Barber wrote: > > On Thu, Oct 02, 2014 at 02:56:05PM +1000, Bruce Evans wrote: > >> On Wed, 1 Oct 2014, Glen Barber wrote: > >> > >> >Log: > >> > MFC r268376 (imp): > >> > > >> > rm -rf can fail sometimes with an error from fts_read. Make it > >> > honor fflag to ignore fts_read errors, but stop deleting from > >> > that directory because no further progress can be made. > >> > >> I asked for this to be backed out in -current. It is not suitable for MFC. > >> > > > > It fixes an immediate issue that prevents high-concurrent make(1) jobs > > from stomping over each other. > > The real problem is noted in this bug: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192490 ; the > SUBDIR_PARALLEL logic is executing multiple instances of the > clean/cleandir .PHONY targets. > > I agree with bde@ that this commit is papering over a bigger problem, > but it's annoying enough and causes enough false positives that I > understand why gjb@ MFCed the commit imp@ did in head. > > Thank you.. > I agree that the change to rm only papers over the real problem. I think bug 192490 should be re-opened so that we can address the actual build system problem, but I don't know if that's allowed for in the new bugzilla workflows, or if we need to open a new report now. I've been digging into the actual build system problem this evening, and I'm starting to think that all the reported failures that contain enough of the log to be useful show that the build failed in a directory that has subdirectories. That is, one of the failures appeared to be caused by rm -rf running concurrently in usr.bin/lex and usr.bin/lex/lib. Another failure involves modules/aic7xxx and modules/aic7xxx/ahc. In another log it appeared that ata/atapci/chipsets was being deleted simulataneously with ata/atapci/chipsets/ataacard and several other subdirs under chipsets/. If this is indeed the cause of the problem I'm too tired right now to think of a fix, but I at least wanted to get what I found in writing before I sleep and completely forget it. :) BTW, I didn't see any evidence that the exact same path was being multiply deleted at the same time. That is, no duplicated entries in SUBDIR lists or accidentally processing the entire sys/modules hiearchy twice in parallel somehow through two different parent paths or anything like that. -- Ian