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