Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 2 Jun 2023 17:36:09 -0400
From:   Peter Xu <peterx@redhat.com>
To:     John Hubbard <jhubbard@nvidia.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        David Hildenbrand <david@redhat.com>,
        Shuah Khan <shuah@kernel.org>,
        Nathan Chancellor <nathan@kernel.org>, linux-mm@kvack.org,
        linux-kselftest@vger.kernel.org,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 05/12] selftests/mm: fix invocation of tests that are run
 via shell scripts
Message-ID: <ZHpgybHDDAMFsADT@x1n>
References: <20230602013358.900637-1-jhubbard@nvidia.com>
 <20230602013358.900637-6-jhubbard@nvidia.com>
 <ZHoL8vJPIUzP2RKN@x1n>
 <e31f1411-1986-c25d-af74-05ad73a53c8d@nvidia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <e31f1411-1986-c25d-af74-05ad73a53c8d@nvidia.com>
Precedence: bulk

On Fri, Jun 02, 2023 at 12:19:17PM -0700, John Hubbard wrote:
> On 6/2/23 08:34, Peter Xu wrote:
> > On Thu, Jun 01, 2023 at 06:33:51PM -0700, John Hubbard wrote:
> > > We cannot depend upon git to reliably retain the executable bit on shell
> > > scripts, or so I was told several years ago while working on this same
> > > run_vmtests.sh script. And sure enough, things such as test_hmm.sh are
> > > lately failing to run, due to lacking execute permissions.
> > > 
> > > A nice clean way to fix this would have been to use TEST_PROGS instead
> > > of TEST_FILES for the .sh scripts here. That tells the selftest
> > > framework to run these (and emit a warning if the files are not
> > > executable, but still run them anyway).
> > > 
> > > Unfortunately, run_vmtests.sh has its own run_test() routine, which does
> > > *not* do the right thing for shell scripts.
> > > 
> > > Fix this by explicitly adding "bash" to each of the shell script
> > > invocations. Leave fixing the overall approach to another day.
> > 
> > Is it possible someone just doesn't have "bash" at all?  I used to only use
> 
> Well, maybe [1]. But that someone won't be running these tests as-is, because
> the tests explicitly require bash, even before this patch.
> 
> > "sh" without bash installed I think, but that was not on Linux, so I'm not
> > sure how much that applies..
> 
> sh invocations are for when you want to express that this script should
> avoid using bash-specific things, in order to ensure portability to
> other environments.
> 
> But here, the run_vmtests.sh file requires bash already, as per the
> first line:
> 
>     #!/bin/bash
> 
> ...which is ultimately why I decided to use bash, rather than sh here.

That one can be easily override with $XXX run_vmtests.sh, hard-coded "bash"
in Makefiles can't, afaiu.

> 
> > 
> > Maybe use $(SHELL)?  I saw a bunch of usage in the tree too.
> > 
> 
> That's more of a Makefile construct that you are seeing, and only in a
> few odd Makefiles. Recall that in Make, $(SHELL) has the same effect
> that ${SHELL} has in bash/sh, by the way: dereferencing a variable.
> 
> And Make's "$(shell ...)" command is what is normally used to *run* a
> shell command, in the kernel's build system.
> 
> Having said all that, I will take a quick look at what it would take
> to shift over to the selftest framework's run_test() instead, in
> order to avoid this ugly "fix".

Just to mention that I was not talking about $(shell ...), but the
environment var $(SHELL), or "env | grep SHELL".

Please feel free to have a look at tools/perf/arch/x86/Makefile.

Thanks,

-- 
Peter Xu