linux-kernel - Re: [PATCH 5.15 00/37] 5.15.96-rc2 review

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 23 Feb 2023 12:47:41 -0700
From:   Nathan Chancellor <nathan@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org, patches@...ts.linux.dev,
        linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
        shuah@...nel.org, patches@...nelci.org,
        lkft-triage@...ts.linaro.org, pavel@...x.de, jonathanh@...dia.com,
        f.fainelli@...il.com, sudipm.mukherjee@...il.com,
        srw@...dewatkins.net, rwarsow@....de
Subject: Re: [PATCH 5.15 00/37] 5.15.96-rc2 review

On Thu, Feb 23, 2023 at 10:03:43AM -0800, Linus Torvalds wrote:
> On Thu, Feb 23, 2023 at 9:31 AM Guenter Roeck <linux@...ck-us.net> wrote:
> >
> > This isn't the first time this happens. I seem to recall that you mentioned
> > some time ago that whatever you use to apply patches (quilt ?) doesn't
> > handle executable permission bits correctly.
> 
> Note that even though git itself does handle these things right, we've
> also always said that if some old fogey wants to use tar-balls and
> patches, that's supposed to still work.
> 
> I guess the same "old fogey" comment then covers quilt too.
> 
> End result: we should try to generally not execute our scripts
> directly, but to explicitly state which interpreter it should use,
> rather than then depend on the #! in the script itself to do it.
> 
> In fact, for shell scripting in particular, we go further than that,
> and use $(CONFIG_SHELL)
> 
> Of course, in this case, it's actually using the Makefile '$(shell
> ..)' format, so I guess it looks a bit odd to write it as
> 
>    $(shell $(CONFIG_SHELL) script..)
> 
> but I do think we should do it.

Right, we would also need CONFIG_SHELL within scripts/pahole-flags.sh
for scripts/pahole-version.sh, which is really what was blowing up here,
but the invocation of 'scripts/pahole-flags.sh' in Makefile needs it too
to avoid the same problem if it were added to an older kernel.

diff --git a/scripts/pahole-flags.sh b/scripts/pahole-flags.sh
index 0d99ef17e4a5..ca3c311a3855 100755
--- a/scripts/pahole-flags.sh
+++ b/scripts/pahole-flags.sh
@@ -7,7 +7,7 @@ if ! [ -x "$(command -v ${PAHOLE})" ]; then
 	exit 0
 fi
 
-pahole_ver=$($(dirname $0)/pahole-version.sh ${PAHOLE})
+pahole_ver=$(${CONFIG_SHELL} $(dirname $0)/pahole-version.sh ${PAHOLE})
 
 if [ "${pahole_ver}" -ge "118" ] && [ "${pahole_ver}" -le "121" ]; then
 	# pahole 1.18 through 1.21 can't handle zero-sized per-CPU vars

I can send a patch unless you want to take those changes directly, you
have half a commit message there already I think :)

Cheers,
Nathan