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:   Mon, 11 Jul 2022 17:08:04 -0600
From:   Shuah Khan <skhan@...uxfoundation.org>
To:     Anders Roxell <anders.roxell@...aro.org>
Cc:     Guillaume Tucker <guillaume.tucker@...labora.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Shuah Khan <shuah@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        kernel@...labora.com, linux-kbuild@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH 0/4] Fix kselftest build with sub-directory

On 7/11/22 6:13 AM, Anders Roxell wrote:
> On Fri, 8 Jul 2022 at 19:14, Shuah Khan <skhan@...uxfoundation.org> wrote:
>>
>> On 7/8/22 10:23 AM, Guillaume Tucker wrote:
>>> Earlier attempts to get "make O=build kselftest-all" to work were
>>> not successful as they made undesirable changes to some functions
>>> in the top-level Makefile.  This series takes a different
>>> approach by removing the root cause of the problem within
>>> kselftest, which is when the sub-Makefile tries to install kernel
>>> headers "backwards" by calling make with the top-level Makefile.
>>> The actual issue comes from the fact that $(srctree) is ".." when
>>> building in a sub-directory with "O=build" which then obviously
>>> makes "-C $(top_srcdir)" point outside of the real source tree.
>>>
>>> With this series, the generic kselftest targets work as expected
>>> from the top level with or without a build directory e.g.:
>>>
>>>     $ make kselftest-all
>>>
>>>     $ make O=build kselftest-all
>>>
>>> Then in order to build using the sub-Makefile explicitly, the
>>> headers have to be installed first.  This is arguably a valid
>>> requirement to have when building a tool from a sub-Makefile.
>>> For example, "make -C tools/testing/nvdimm/" fails in a similar
>>> way until <asm/rwonce.h> has been generated by a kernel build.
>>>
>>> Guillaume Tucker (4):
>>>     selftests: drop khdr make target
>>>     selftests: stop using KSFT_KHDR_INSTALL
>>>     selftests: drop KSFT_KHDR_INSTALL make target
>>>     Makefile: add headers_install to kselftest targets
>>>
>>
>> This takes us to back to the state before b2d35fa5fc80 added
>> khdr support. I reluctantly agreed to the change and it has
>> proven to be a problematic change. I would rather have had the
>> dependency stated that headers should be installed prior to
>> building tests - test build depends on kernel build anyway and
>> having dependency on headers having build isn't a huge deal.
> 
> I agree that it's not a huge deal.
> 
>>
>> So I am in favor of getting rid of khdr support. However, this
>> khdr support was a change originated from Linaro test ring. Undoing
>> this might have implication on their workflow.
> 
> It shouldn't be a problem.
> I've been running these patches through a smoke test and it looks
> good.
> 
> Tested-by: Anders Roxell <anders.roxell@...aro.org>
> 
> 

Thank you Anders for confirming this isn't a problem for Linaro workflow
and testing.

Than you Guillaume for fixing the problem. I will apply these for 5.20-rc1.

thanks,
-- Shuah

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ