Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp746243ybe; Mon, 2 Sep 2019 08:31:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqxLtNZgbiZoQtl95HolugsBwOj05GjgGPeBCZ8E2KgZKThjpmfqF9TN3C3K8Lf/4zA+JjoW X-Received: by 2002:a62:d4:: with SMTP id 203mr3995478pfa.210.1567438262088; Mon, 02 Sep 2019 08:31:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567438262; cv=none; d=google.com; s=arc-20160816; b=IJDvgfbLGIg+kvAnwupwMKhzcZd4fO9wU8GnqLzn3tnc/AWF6PKfKeiqLOoQ5t5xhk cdO3lMmydjJf83zPdICUXlpAA6YAz5TtxVOWuEwiRlpEKlH8vmjxR3h+f2ZwFjCRacvy Db401TWlYnxy/s1GWqIpYSEp5JAOsnwAyQ87MURpvRAWPlabh1eepeL5dqdF1KMIf3E6 uG8Ss/CZUh265tpspvmOOPNp70a5WsQxayQ2N+gs7dJ9A1k7uDAeY4t8XWmddwnlt6hr 7piOuFOn/XKaCMtxLn8NBf7pPyAydnjUP18bJrFUf5hexDmBEUXRAVIOHoNgcPw6kQaN +3qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=yDNBWvG5VuXypH6StSc5QnYtujHaS9STl59CEno/6Ac=; b=E2DYJZI2ExyqMyO8hb0gBJOVd00WbB50Q7jF1f1FDARAZUG9n4YkDBJOyMh01lV85/ q3X7dl2/FiqBOnWL5fHLfk6sEISFeuP1BblnHFjAptvxNROPINeZf308XIN4v3Ja1Agk eighaO2/q4tg0osdAcwWLdo9tvvhbSCY8txbzPq32nG1fV1AOu7GjrUt1kw9xlBNLrTW axas5V3y+Ig/LLutXxSC9sDMz/xat3AWZP0YeH39tZTiNah9xg6h/9V5iOv285uNdWXk Ar30sHtaaxc9dEwey7vKh3W3XQ0QYAIBlO0G5br0DFDZS4d7gJwDCcsV5Ur+gqrp5O1I SFLQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k73si11626610pge.353.2019.09.02.08.30.46; Mon, 02 Sep 2019 08:31:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731406AbfIBOTb (ORCPT + 99 others); Mon, 2 Sep 2019 10:19:31 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:50316 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726438AbfIBOTb (ORCPT ); Mon, 2 Sep 2019 10:19:31 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: gtucker) with ESMTPSA id 173AB28C285 Subject: Re: [PATCH v2] merge_config.sh: Check error codes from make To: Jon Hunter , Mark Brown , Masahiro Yamada Cc: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-tegra References: <20190819200650.18156-1-broonie@kernel.org> From: Guillaume Tucker Message-ID: <260e4eeb-d492-1056-5c60-d7ae8a176bc0@collabora.com> Date: Mon, 2 Sep 2019 15:19:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/09/2019 15:06, Jon Hunter wrote: > > On 19/08/2019 21:06, Mark Brown wrote: >> When we execute make after merging the configurations we ignore any >> errors it produces causing whatever is running merge_config.sh to be >> unaware of any failures. This issue was noticed by Guillaume Tucker >> while looking at problems with testing of clang only builds in KernelCI >> which caused Kbuild to be unable to find a working host compiler. >> >> This implementation was suggested by Yamada-san. >> >> Suggested-by: Masahiro Yamada >> Reported-by: Guillaume Tucker >> Signed-off-by: Mark Brown >> --- > > I have noticed some recent build failures on -next and the bisect is > pointing to this commit. I have been looking at why this commit is > making the builds fail and I see a few different things going on ... > > 1. By using 'set -e', if grep fails to find a kconfig option in the > resulting config file, then script exits silently without reporting > which option it failed to find. Hence, it is unclear what triggered > the failure. This may happen when options are being disabled. > > 2. If an option is disabled by the config fragment that happens to be a > parent of other kconfig options, then although the parent and > children are disabled correctly, the script may fail because it no > longer finds the children in the resulting config file. A specific > example, here is CONFIG_NFS_V4. We disable this option due to > issues with some host machines we use, and disabling this also > disables CONFIG_NFS_V4_1 and CONFIG_NFS_V4_2. Now if all 3 of these > options are enabled by default in the base config file, such as the > case in the ARM64 defconfig, then disabling CONFIG_NFS_V4 in the > config fragment causes merge_config.sh to fail because > CONFIG_NFS_V4_1 and CONFIG_NFS_V4_2 are not defined at all in > the resulting config. This causes grep to fail to find these and > hence causes the script to terminate. In the resulting config file we > just have '# CONFIG_NFS_V4 is not set'. I am not sure if there is an > easy way to determine if a missing config option is legitimate or > not. > > A simple way to test the above is ... > > $ export ARCH=arm64 > $ echo "CONFIG_NFS_V4=n" > kfrag > $ ./scripts/kconfig/merge_config.sh arch/arm64/configs/defconfig kfrag > > If the intent is to catch errors returned by make, then one simple fix would be ... > > diff --git a/scripts/kconfig/merge_config.sh b/scripts/kconfig/merge_config.sh > index bec246719aea..63c8565206a4 100755 > --- a/scripts/kconfig/merge_config.sh > +++ b/scripts/kconfig/merge_config.sh > @@ -179,7 +179,7 @@ make KCONFIG_ALLCONFIG=$TMP_FILE $OUTPUT_ARG $ALLTARGET > for CFG in $(sed -n -e "$SED_CONFIG_EXP1" -e "$SED_CONFIG_EXP2" $TMP_FILE); do > > REQUESTED_VAL=$(grep -w -e "$CFG" $TMP_FILE) > - ACTUAL_VAL=$(grep -w -e "$CFG" "$KCONFIG_CONFIG") > + ACTUAL_VAL=$(grep -w -e "$CFG" "$KCONFIG_CONFIG" || true) > if [ "x$REQUESTED_VAL" != "x$ACTUAL_VAL" ] ; then > echo "Value requested for $CFG not in final .config" > echo "Requested value: $REQUESTED_VAL" > > > I have been using merge_config.sh to enable and disable various options > we need for testing for sometime now and so would hope I am not doing > anything out of the ordinary here. > > Let me know your thoughts. I've added you to another thread with a fix I sent last week for the same issue. The way I addressed it with "echo" was to explicitly return an empty line as that is essentially what is then being used to compare the config values. I guess "true" also works in practice. My understanding is that "set -e" was added primarily to catch errors returned by the make command. The config value checks with grep have always been warnings that don't cause errors, so I would assume that it should stay like this until there's a conscious decision to change this behaviour. Thanks, Guillaume