Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp777067pxj; Thu, 3 Jun 2021 20:25:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw6gtyvRWSslefxHqEvUGob02ynfB4wXoRnosisZVP/UKddyb/Ec2sny19jZG0An1U+heje X-Received: by 2002:a05:6402:4256:: with SMTP id g22mr2443396edb.214.1622777150327; Thu, 03 Jun 2021 20:25:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622777150; cv=none; d=google.com; s=arc-20160816; b=yQFNmoh7tYarhJ21sOGpQ0nxWEcLCPk+KTuxJCurmLzvmnQPHpF45X/KcetwIJqZKb eL31dOCZ5dvaZ4RRO9X93tRz0ln1v7Y7DOjCZjYsVk4+EFw5P+D7YSGKHT7tVCY+mSgw cF5BPD4r66Q5O71kmQK1eiDPd55Ib1rI5sJUI2YV1fGoMnY4JW1Gf/gupTK32syzNQPK 9BELPU8/eKsrQN6RZAAFTRHmO5eyzU0OCw2qCXcJEgmVAKXIWmujVT1IU6uwzCYV/c/0 HcWG2qQS0627H5v62ssu8S4UJjst/LR26BLWl8Oi0EO1/9rQ6tiyd1cRvwguisp8N4mI tpzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature:dkim-filter; bh=4ZgwLrSdL0ckNfaVKbFIuxYSiOqIzn7/uA3PaNeKOHs=; b=fQCaCDxD9OIpRj/WQ96SUw4nuwM+QIPhopjoLgyw6ByI4NTN2WGQLcaEYsyRkCpVvc jOhWDtRCuqJDZJ0UtaHYZbLnrmXb8z697GSq4lmR6EpWQzC7UD0/wDsoTSHsYKq4KqJR dpai2qx+aTXnI4hZZs3mERU/r4058lUMKZ2Nm4tpQdMx+E3x0azh4tjH4uOIeaonIO+Q 1ZPSEgBrrf9n4RhSErXesvc4d2zwl7OQpeb9Hcng0ToQ6mI+KTzIox2LlZUYDAMKvNBV k+otUtretebA1UVp5UvJF/IU5jtNWa+173P7eYxo8ij/IMARn/s3+MdSxoxp7t+YKHgm e8Zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=oAqnyCjf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jg13si3601455ejc.566.2021.06.03.20.25.25; Thu, 03 Jun 2021 20:25:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=oAqnyCjf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229761AbhFDDZ1 (ORCPT + 99 others); Thu, 3 Jun 2021 23:25:27 -0400 Received: from conssluserg-04.nifty.com ([210.131.2.83]:42730 "EHLO conssluserg-04.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229752AbhFDDZ0 (ORCPT ); Thu, 3 Jun 2021 23:25:26 -0400 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) (authenticated) by conssluserg-04.nifty.com with ESMTP id 1543NAX0031704 for ; Fri, 4 Jun 2021 12:23:11 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com 1543NAX0031704 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1622776991; bh=4ZgwLrSdL0ckNfaVKbFIuxYSiOqIzn7/uA3PaNeKOHs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=oAqnyCjfxeEVNk8weaq7LPQmzv++IXw4cCCGEDQGHyzhCTOkgk8miy4DYws+Boy6q /FoAduPGNonLt+JnBjAu4suQiZ+lzJjTI3TwcpTRkF9yvMq2eOCTyQxFp2O+ViytxX TEQDZDGSpnomYLFSGIteAgmzdg1c5YLn6o1xjTmgIr0FO5dAuGMvbwtbD26x7xZwj+ qsDX6z2eRiBKk0tvRGMhC02WtZ7/DGAyQ4U/vF+lNbGVz8VdtryDB8hJsuRizHZZuG swz8DolPgHyYFsMnAqprDb0LN6aI9Zxq3ZNRej/8F7RjnqVWE3xErsNKKNqb3EN3Ry 72Udmi3k1bEGQ== X-Nifty-SrcIP: [209.85.210.180] Received: by mail-pf1-f180.google.com with SMTP id t28so6443646pfg.10 for ; Thu, 03 Jun 2021 20:23:11 -0700 (PDT) X-Gm-Message-State: AOAM533IScNKEfYmZEZbg7Yk9m1i5tyjBUgFcjjFfXhTF7YUqlOTJEKR ER4+34aI7W4plfXfejE0Wc7zpwemlQT6HKY8JFU= X-Received: by 2002:aa7:99c9:0:b029:2e9:e084:e1de with SMTP id v9-20020aa799c90000b02902e9e084e1demr2482878pfi.80.1622776990547; Thu, 03 Jun 2021 20:23:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Masahiro Yamada Date: Fri, 4 Jun 2021 12:22:33 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: kbuild: Ctrl-C of parallel kernel build sometimes corrupts .o.cmd files permanently To: Ingo Molnar Cc: Michal Marek , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 3, 2021 at 9:44 PM Ingo Molnar wrote: > > > * Ingo Molnar wrote: > > > > CC security/keys/keyctl_pkey.o > > > CC kernel/sys.o > > > CC arch/x86/power/hibernate_64.o > > > ^Cmake[5]: *** Deleting file 'drivers/video/fbdev/core/fbcmap.o' <---- Deleting > > > make[5]: *** [scripts/Makefile.build:272: > > > drivers/video/fbdev/core/fbmon.o] Interrupt > > > make[3]: *** [scripts/Makefile.build:272: security/selinux/nlmsgtab.o] Interrupt > > > make[2]: *** [scripts/Makefile.build:272: arch/x86/power/cpu.o] Interrupt > > > make[2]: *** [scripts/Makefile.build:272: > > > > Interestingly I don't get *any* interruption messages at all: > > > > CC drivers/dma/dw/acpi.o > > CC sound/pci/ice1712/ice1712.o > > CC drivers/char/ipmi/ipmi_watchdog.o > > CC fs/overlayfs/export.o > > CC fs/nls/nls_cp936.o > > CC drivers/char/ipmi/ipmi_poweroff.o > > ^Ckepler:~/tip> > > > > The '^C' there - it just stops, make never prints anything for me. > > Found something - seems to be related whether the build is going into a > pipe or not. > > > I usually build this way (directly or via a script): > > make -j96 bzImage ARCH=x86 2>&1 | tee e > > Ctrl-C interruption is not handled by kbuild in this case: > > CC fs/jffs2/xattr_trusted.o > CC sound/firewire/motu/motu-transaction.o > CC sound/usb/clock.o > ^Ckepler:~/tip> > > Immediate prompt - no cleanup sequence. > > But if I do it without 'tee', I get the expected cleanup sequence by make: > > kepler:~/tip> make -j96 bzImage ARCH=x86 2>&1 > > CC fs/jffs2/acl.o > CC sound/pci/echoaudio/mona.o > CC fs/nls/nls_iso8859-9.o > ^Cmake[2]: *** Deleting file 'drivers/reset/core.o' > make[3]: *** Deleting file 'sound/pci/mixart/mixart.o' > make[3]: *** Deleting file 'sound/pci/emu10k1/voice.o' > make[2]: *** Deleting file 'fs/gfs2/aops.o' > > Thanks, > > Ingo Hmm, I do not know why GNU Make behaves like this... I will ask about this in GNU Make ML. -- Best Regards Masahiro Yamada