From patchwork Thu Mar 15 20:56:20 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Pitre X-Patchwork-Id: 10285787 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 4AD9560291 for ; Thu, 15 Mar 2018 20:56:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2BC4E287D2 for ; Thu, 15 Mar 2018 20:56:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1FE8228BEE; Thu, 15 Mar 2018 20:56:25 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E9DB2287D2 for ; Thu, 15 Mar 2018 20:56:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752509AbeCOU4X (ORCPT ); Thu, 15 Mar 2018 16:56:23 -0400 Received: from mail-qk0-f193.google.com ([209.85.220.193]:41049 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752457AbeCOU4W (ORCPT ); Thu, 15 Mar 2018 16:56:22 -0400 Received: by mail-qk0-f193.google.com with SMTP id s78so8861149qkl.8 for ; Thu, 15 Mar 2018 13:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=dghNyXlpx2RGtI4GcUBat8/fmro76Y3N8jw1mYk3G/k=; b=WxSQmRsrHgfL/e8RINWBhP26O/IIyKAD/wtDXxP73WlvLhjYHmXOx3k1G1iy/Ea+9w XFAZKIk/G6aCGT5LlpeKy8WmUJGHUmdK7ZaVJgGdkrsOPK/LEiEaNpu3QW9xuxf7medT 2PHI7KJLBlRM+i5Js1l1f6crZI+bRqmxftFjY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=dghNyXlpx2RGtI4GcUBat8/fmro76Y3N8jw1mYk3G/k=; b=iyt9/VQxpxXdPeC7Qc0D7GGH2rQXXcVQUM8chkk7bjrrjOXo2ycB1rLCmzf13hx+eg Ythk04n3cboGxMJ+fo6bsaMY20Sw25hnPKifxN0lunMks60RfbXI+Niok5uKSsr/LnlT zB7n4VbEoc8k7FDQKX40pycqkKOWHyQJMkVu8qV+dCow07s2qk54VTEKd8HAJFkWEE1v +pHXrIlv07v86JunsevuaRPago+emk60MUDgvZ3eIRzFXP0nrx3objxVeHE8WMaWA74j DawMkMlagPzTsfb7xictTP3xA4vLg0F8Hw4HR2XC0jFtf+D4LprJaGJ/ZxCjv+agOMhS JsOw== X-Gm-Message-State: AElRT7GDzJ0/KTsI6iUv6QRIg+1O7+XUojVJMaa4ZYNUv8Q2ffaWFJDP ndP0q6cB2Rf1qUCwaCwUFsAS6w== X-Google-Smtp-Source: AG47ELs1kYs6xHRk3YzG1xE1RLS8Yuo9kfhJFkKrES2BjkkDo/uv1P3eAnIid6uoRe3KK/SPvTmBbQ== X-Received: by 10.55.17.196 with SMTP id 65mr14287746qkr.86.1521147381908; Thu, 15 Mar 2018 13:56:21 -0700 (PDT) Received: from xanadu.home (modemcable228.104-82-70.mc.videotron.ca. [70.82.104.228]) by smtp.gmail.com with ESMTPSA id g9sm4454817qti.11.2018.03.15.13.56.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 15 Mar 2018 13:56:21 -0700 (PDT) Date: Thu, 15 Mar 2018 16:56:20 -0400 (EDT) From: Nicolas Pitre To: Thomas Lindroth cc: Masahiro Yamada , Linux Kbuild mailing list Subject: Re: Intermittent build failure with TRIM_UNUSED_KSYMS and related problems In-Reply-To: <4aee7e23-ac36-9495-14a9-471379a7896b@gmail.com> Message-ID: References: <4bbfeb74-c912-74e5-4f4d-287ec7ad065d@gmail.com> <4aee7e23-ac36-9495-14a9-471379a7896b@gmail.com> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Sender: linux-kbuild-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, 15 Mar 2018, Thomas Lindroth wrote: > Here are the timestamps for the fail case: > -rw-r--r-- 1 cocobo cocobo 66424 2018-03-13 17:20:18.000000000 +0100 linux-fail/include/generated/autoksyms.h > -rw-r--r-- 1 cocobo cocobo 121064 2018-03-13 17:16:53.000000000 +0100 linux-fail/arch/x86/lib/usercopy_64.o > -rw-r--r-- 1 cocobo cocobo 0 2018-03-13 17:16:53.000000000 +0100 linux-fail/include/config/ksym///clear/user.h > > It's suspicious that usercopy_64.o and ksym///clear/user.h got the same timestamp. > My gut feeling says that ksym///clear/user.h was touched after usercopy_64.o was > built but less than 1 sec had passed so they got the same timestamps due to the > poor timestamp resolution on my old ext4 filesystem. Since the timestamps on > ksym///clear/user.h wasn't newer than usercopy_64.o the rebuild was skipped. > > AS arch/x86/lib/putuser.o > AS arch/x86/lib/retpoline.o <--- > AS arch/x86/lib/rwsem.o > CC arch/x86/lib/usercopy.o > CC arch/x86/lib/usercopy_64.o <--- > AR arch/x86/lib/lib.a > EXPORTS arch/x86/lib/lib-ksyms.o > AR arch/x86/lib/built-in.o > CC virt/lib/irqbypass.o > AR virt/lib/built-in.o > AR virt/built-in.o > CHK include/generated/autoksyms.h > KSYMS symbols: before=0, after=1871, changed=1871 > > The problematic usercopy_64.o and retpoline.o are built just before ksym. The build > and ksym generation probably happens in less than 1 sec. > > Here are the timestamps for the success case: > -rw-r--r-- 1 cocobo cocobo 66424 2018-03-13 16:58:02.000000000 +0100 linux-success/include/generated/autoksyms.h > -rw-r--r-- 1 cocobo cocobo 126912 2018-03-13 16:58:01.000000000 +0100 linux-success/arch/x86/lib/usercopy_64.o > -rw-r--r-- 1 cocobo cocobo 0 2018-03-13 16:54:38.000000000 +0100 linux-success/include/config/ksym///clear/user.h > > usercopy_64.o was rebuilt here so it has a more recent timestamp than ksym///clear/user.h. > > To test this a bit more I copied the 4.14.23 source to tmpfs and ran the build there. > Tmpfs supports nanosecond timestamps. The build succeeded 16 times in a row. Usually > there is around 50/50 chance of success/failure on ext4. OK. That must be it. Could you please test the following patch: ----- >8 Subject: [PATCH] kbuild: make scripts/adjust_autoksyms.sh robust against timestamp races Some filesystems have timestamps with coarse precision that may allow for a recently built object file to have the same timestamp as the updated time on one of its dependency files. When that happens, the object file doesn't get rebuilt as it should. This is especially the case on filesystems that don't have sub-second time precision, such as ext3 or Ext4 with 128B inodes. Let's prevent that by making sure updated dependency files have a newer timestamp than the first file we created (i.e. autoksyms.h.tmpnew). Reported-by: Thomas Lindroth Signed-off-by: Nicolas Pitre ----- >8 > > Maybe it is just a coincidence, but there is a lot of underscore > > prefixed symbols in that list, except for one case. This translates to > > successive / in the path for the timestamp file. And that one case that > > doesn't fit the pattern does actually aliases a path that does. I wonder > > if the filesystem cache could get confused by successive / in paths > > here, given the non deterministic nature of the build failure you get. > > > > Could you please test with the following patch to validate this > > hypothesis: > The patch applied with some fuzz to 4.14.23. Using the patch the first two > builds I did succeeded and the third failed like: > Kernel: arch/x86/boot/bzImage is ready (#2) > Building modules, stage 2. > MODPOST 146 modules > ERROR: "__put_user_2" [net/ipv4/netfilter/ip_tables.ko] undefined! OK. Glad this hypothesis didn't verify. Nicolas --- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/scripts/adjust_autoksyms.sh b/scripts/adjust_autoksyms.sh index 513da1a4a2..d67830e6e3 100755 --- a/scripts/adjust_autoksyms.sh +++ b/scripts/adjust_autoksyms.sh @@ -84,6 +84,13 @@ while read sympath; do depfile="include/config/ksym/${sympath}.h" mkdir -p "$(dirname "$depfile")" touch "$depfile" + # Filesystems with coarse time precision may create timestamps + # equal to the one from a file that was very recently built and that + # needs to be rebuild. Let's guard against that by making sure our + # dep files are always newer than the first file we created here. + while [ ! "$depfile" -nt "$new_ksyms_file" ]; do + touch "$depfile" + done echo $((count += 1)) done | tail -1 ) changed=${changed:-0}