From patchwork Tue Dec 1 17:10:14 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Russell King - ARM Linux X-Patchwork-Id: 7739011 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 008DBBEEE1 for ; Tue, 1 Dec 2015 17:12:58 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id EC83120650 for ; Tue, 1 Dec 2015 17:12:56 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D8F012064D for ; Tue, 1 Dec 2015 17:12:55 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1a3oS8-0008TK-4P; Tue, 01 Dec 2015 17:10:56 +0000 Received: from pandora.arm.linux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1a3oS2-0007kY-Kp for linux-arm-kernel@lists.infradead.org; Tue, 01 Dec 2015 17:10:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=arm.linux.org.uk; s=pandora-2014; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=zAheWhd/7vGZPXxFcGjn7d76VEIwaxyrs9M+OBt+5Vs=; b=dCYcp4t5DZuXAM5ob9SmqSIHZqI3K2Jc2ov8TMu7Q+w7de6vcyGBuEDHgm8uiXU4+cHwzRfXDqYg/0rcGxsYgsM8d3wjDrMRO+l1OrUdjlpzCfmEg4mfe4yaw8wMnZH7Tubzw/QhcbZwlIf52q1kWJmnFQPFEd6TJluWtY+YLa8=; Received: from n2100.arm.linux.org.uk ([fd8f:7570:feb6:1:214:fdff:fe10:4f86]:48841) by pandora.arm.linux.org.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1a3oRV-0005IY-Tt; Tue, 01 Dec 2015 17:10:18 +0000 Received: from linux by n2100.arm.linux.org.uk with local (Exim 4.76) (envelope-from ) id 1a3oRS-0004st-GE; Tue, 01 Dec 2015 17:10:14 +0000 Date: Tue, 1 Dec 2015 17:10:14 +0000 From: Russell King - ARM Linux To: Steven Rostedt Subject: Re: [PATCH v2 1/2] scripts: Add a recorduidiv program Message-ID: <20151201171014.GY8644@n2100.arm.linux.org.uk> References: <1448488264-23400-1-git-send-email-sboyd@codeaurora.org> <1448488264-23400-2-git-send-email-sboyd@codeaurora.org> <20151125234711.GT8644@n2100.arm.linux.org.uk> <565C6714.802@suse.com> <20151130153208.GR8644@n2100.arm.linux.org.uk> <565C6DE9.2020302@suse.com> <565DC5A9.2010305@suse.cz> <20151201161944.GX8644@n2100.arm.linux.org.uk> <20151201114929.655433a2@gandalf.local.home> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20151201114929.655433a2@gandalf.local.home> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20151201_091051_840101_598A1F86 X-CRM114-Status: GOOD ( 22.49 ) X-Spam-Score: -4.3 (----) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Michal Marek , Thomas Petazzoni , =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= , Arnd Bergmann , linux-kbuild@vger.kernel.org, linux-arm-msm@vger.kernel.org, Nicolas Pitre , Stephen Boyd , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Dec 01, 2015 at 11:49:29AM -0500, Steven Rostedt wrote: > On Tue, 1 Dec 2015 16:19:44 +0000 > Russell King - ARM Linux wrote: > > > They hardly "do nothing", as the (eg) recordmcount plasters the build > > log with warnings. A solution to that would be to make recordmcount > > silent if the section is already present. > > Note, that warning found plenty of bugs when modifications of the build > system was being done and broke recordmcount.c. I really don't want to > silent it. > > But for some reason, your build is causing lots of warnings and not for > others. Perhaps we can add a "SILENT_RECORDMCOUNT" environment variable > and have it set when something like CCACHE_HARDLINK or whatever is > causing it to trigger when we don't care. The case is: Build 1 runs with CCACHE_HARDLINK enabled. - Each object ccache creates will be stored in ccache, and hard linked into the throw-away object tree. - recordmcount modifies in-place the object in the object tree, which also modifies the object in the ccache repository. The throw-away object tree is thrown away, and a new tree is created, and the build re-run. It doesn't matter what CCACHE options are used, the effect will now be the same: - Each "hit" ccache object from the previous build will be linked or copied to the new throw-away object tree. - recordmcount will be re-run on the object, which now contains the results of the previous recordmcount in-place modification. This causes recordmcount to issue a warning. There's two solutions to this: one is to disable CCACHE_HARDLINK for all kernel builds which use in-place object modification. The other solution is to avoid in-place object modification, instead doing a read-write-rename. I think I ought to ask another question though, before we decide what to do. With recordmcount doing in-place object modification, what happens if a SIGINT or similar is received half way through the modification of an object? I would hope that make would delete the object and not leave it around. Another suggestion - maybe recordmcount, which fstat()s the file, should check the st_nlink before modifying the file, and error out with a helpful error message telling people not to use hardlinks, which would stop nasty surprises (and make it a rule that this should be implemented as a general principle for good build behaviour) - iow, something like this (untested): scripts/recordmcount.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c index 698768bdc581..bb7589fd7392 100644 --- a/scripts/recordmcount.c +++ b/scripts/recordmcount.c @@ -203,6 +203,10 @@ static void *mmap_file(char const *fname) fprintf(stderr, "not a regular file: %s\n", fname); fail_file(); } + if (sb.st_nlink != 1) { + fprintf(stderr, "file is hard linked: %s\n", fname); + fail_file(); + } addr = mmap(0, sb.st_size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd_map, 0); mmap_failed = 0;