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@xxxxxxxxxxxx> 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
