From owner-svn-src-all@FreeBSD.ORG Thu Oct 2 04:56:11 2014 Return-Path: Delivered-To: svn-src-all@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 592819DC; Thu, 2 Oct 2014 04:56:11 +0000 (UTC) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 1B2D61D9; Thu, 2 Oct 2014 04:56:10 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id 777BC1A2354; Thu, 2 Oct 2014 14:56:08 +1000 (EST) Date: Thu, 2 Oct 2014 14:56:05 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Glen Barber Subject: Re: svn commit: r272372 - stable/10/bin/rm In-Reply-To: <201410011618.s91GIfR5071251@svn.freebsd.org> Message-ID: <20141002141656.Y1807@besplex.bde.org> References: <201410011618.s91GIfR5071251@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=dMCfxopb c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=5KYu8npawQ8VuZliGPcA:9 a=CjuIK1q_8ugA:10 Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-10@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 04:56:11 -0000 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. > When building a kernel with a high -j value on a high core count > machine, during the cleanobj phase we can wind up doing multiple > rm -rf at the same time for modules that have subdirectories. This > exposed this race (sometimes) as fts_read can return an error if > the directory is removed by another rm -rf. Since the intent of > the -f flag was to ignore errors, even if this was a bug in > fts_read, we should ignore the error like we've been instructed > to do. That may be the intent for sloppy uses, but the meaning of the -f flag is to suppress confirmation and diagnostic messages and modification of the exit status in the case of nonexistent files. (Note that POSIX's OPTIONS section is buggy and only says that this applies to nonexistent operands. Only the main part of the specification says that -f applies recursively.) It is not for breaking reporting of all detected errors. > ============================================================================== > --- stable/10/bin/rm/rm.c Wed Oct 1 16:16:01 2014 (r272371) > +++ stable/10/bin/rm/rm.c Wed Oct 1 16:18:40 2014 (r272372) > @@ -335,7 +335,7 @@ err: > warn("%s", p->fts_path); > eval = 1; > } > - if (errno) > + if (!fflag && errno) > err(1, "fts_read"); > fts_close(fts); > } All other checks of errno in limit the effect of fflag to ENOENT errors. Changing the above to to the same might give conformance to POSIX, depending on whether fts_read() sets errno to ENOENT only when there is an ENOENT error relevant to rm. But I don't like that either. It is only correct to ignore the error for races between multiple rm's where the the interference is limited enough to allow one of the rm's to complete the removal, and moreover, all of the rm's that fail early wait to synchronize with one that actually completes. But the races are caused in the first place by lack of synchronization. See old mail for more details. Bruce