Hi, Shuah! >>>>> On Fri, 10 Jul 2020 08:18:49 -0600, Shuah Khan wrote:
> On 7/10/20 12:02 AM, Yauheni Kaliuta wrote: >> On Thu, Jul 9, 2020 at 6:36 PM Shuah Khan <[email protected]> wrote: >>> >>> On 7/9/20 12:49 AM, kernel test robot wrote: >>>> Greeting, >>>> >>>> FYI, we noticed the following commit (built with gcc-9): >>>> >>>> commit: 7cb32086e59b514a832a3e11f5370d37e7cfe022 ("selftests: >>>> simplify run_tests") >>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master >>>> >>>> >>> >>> Thanks for the report. I will drop this patch for now from next. >>> >>> Yauheni, >>> >>> This patch broke x86 32-bit test run >>> make run_tests -C x86 >>> >>> Please resubmit the patch with the fix. >> >> I did not check carefully the report, but isn't it expected that some >> tests are moved after the patch since they originally were placed >> incorrectly? >> >> > The failure doesn't have anything to do with test being moved. You can > reproduce this very easily by running make as shown below in x86 dir > under tools/testing/selftests > make run_tests -C x86 > I reproduced the problem with your and patch and verified that the > problem tracks your patch. I dropped the patch from linux-next > Your other two patches in the series are fine. > In any case, this patch isn't really adding any functionality and > is a good cleanup. Let's do the cleanup right or not. Checked. That is because with the patch both lib.mk and x86/Makefile add the $(OUTPUT) prefix. So the question is to agree about the convention, should lib.mk targets expect short test names for TEST_PROGS or full path from the subtests' Makefiles. The existing code is hackish (incorrectly -- adding $(OUTPUT) only to the first list members -- tries to handle it only for out-of-tree build). I can make the patch without adding $(OUTPUT). It will require to fix possible tests which provided only one test and rely on that behaviour for the OOT build. Do you have an easy way to get a list of such tests? -- WBR, Yauheni Kaliuta
