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: 7738971 Return-Path: X-Original-To: patchwork-linux-kbuild@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 5C29A9F30B for ; Tue, 1 Dec 2015 17:10:30 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4CFEC2066B for ; Tue, 1 Dec 2015 17:10:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2AE062064D for ; Tue, 1 Dec 2015 17:10:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755921AbbLARK1 (ORCPT ); Tue, 1 Dec 2015 12:10:27 -0500 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:45243 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755823AbbLARK0 (ORCPT ); Tue, 1 Dec 2015 12:10:26 -0500 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 Cc: Michal Marek , Stephen Boyd , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Thomas Petazzoni , linux-kbuild@vger.kernel.org, Nicolas Pitre , Arnd Bergmann , =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= 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) Sender: linux-kbuild-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham 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;