linux-kernel - Re: [PATCH 1/1] merge_config.sh: ignore unwanted grep errors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 2 Sep 2019 15:53:39 +0100
From:   Jon Hunter <jonathanh@...dia.com>
To:     Guillaume Tucker <guillaume.tucker@...labora.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Mark Brown <broonie@...nel.org>
CC:     <linux-kbuild@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <kernel@...labora.com>, linux-tegra <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH 1/1] merge_config.sh: ignore unwanted grep errors


On 02/09/2019 15:49, Guillaume Tucker wrote:
> On 02/09/2019 15:32, Jon Hunter wrote:
>>
>> On 02/09/2019 15:26, Guillaume Tucker wrote:
>>> On 02/09/2019 15:21, Jon Hunter wrote:
>>>>
>>>> On 02/09/2019 15:14, Guillaume Tucker wrote:
>>>>> + Jon Hunter who hit a similar issue
>>>>
>>>> Thanks for adding me.
>>>>
>>>>> On 28/08/2019 21:19, Guillaume Tucker wrote:
>>>>>> The merge_config.sh script verifies that all the config options have
>>>>>> their expected value in the resulting file and prints any issues as
>>>>>> warnings.  These checks aren't intended to be treated as errors given
>>>>>> the current implementation.  However, since "set -e" was added, if the
>>>>>> grep command to look for a config option does not find it the script
>>>>>> will then abort prematurely.
>>>>>>
>>>>>> Handle the case where the grep exit status is non-zero by setting
>>>>>> ACTUAL_VAL to an empty string to restore previous functionality.
>>>>>>
>>>>>> Fixes: cdfca821571d ("merge_config.sh: Check error codes from make")
>>>>>> Signed-off-by: Guillaume Tucker <guillaume.tucker@...labora.com>
>>>>>> ---
>>>>>>  scripts/kconfig/merge_config.sh | 2 +-
>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/scripts/kconfig/merge_config.sh b/scripts/kconfig/merge_config.sh
>>>>>> index d924c51d28b7..d673268d414b 100755
>>>>>> --- a/scripts/kconfig/merge_config.sh
>>>>>> +++ b/scripts/kconfig/merge_config.sh
>>>>>> @@ -177,7 +177,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" || echo)
>>>>
>>>> Shouldn't this just be 'true' instead of 'echo'?
>>>
>>> I just explained why I used "echo" on your thread.  Essentially,
>>> I think both can be used but "echo" made more sense to me because
>>> the script is then using the output string from the command
>>> rather than the exit status.
>>
>> Yes just saw that. However, I don't think that using 'echo' is
>> necessary. The grep command does not output anything and so the variable
>> will essentially be an empty string, we just need to ensure that no
>> error is returned from the command. In cases such as these I always use
>> 'true' in conjunction with grep.
> 
> Sure, that makes sense too.  Your solution is arguably a bit
> simpler so I agree it would be better to use "true" here.
> 
> I can submit a v2 with "true" if that helps, unless you prefer to
> send your version of the fix yourself?

Seeing as you have already created the patch, please go ahead and send.

Thanks
Jon

-- 
nvpublic