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]
Message-ID: <cf4e9f8b-7d31-44d9-93fd-1677918b56f4@nvidia.com>
Date:   Mon, 11 Dec 2023 11:00:39 -0800
From:   John Hubbard <jhubbard@...dia.com>
To:     Muhammad Usama Anjum <usama.anjum@...labora.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     David Hildenbrand <david@...hat.com>, Peter Xu <peterx@...hat.com>,
        Shuah Khan <shuah@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>, linux-mm@...ck.org,
        linux-kselftest@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Anders Roxell <anders.roxell@...aro.org>,
        Jonathan Corbet <corbet@....net>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] Revert "selftests: error out if kernel header files are
 not yet built"

On 12/11/23 03:00, Muhammad Usama Anjum wrote:
> On 12/9/23 7:01 AM, John Hubbard wrote:
>> This reverts commit 9fc96c7c19df ("selftests: error out if kernel header
>> files are not yet built").
> I don't think whole of this commit needs to be reverted. Lets leave the
> warning message as it is and just remove the condition to abort the
> compilation.
> 

Hi Muhammad!

If we do decide that "make headers" or something like it is required,
then yes, this patch should be changed from a revert, to a "warn instead
of failing out" patch.

First, though, I'd like us to choose a design direction. The patch as
written is intended to put us on a design that does not require "make
headers" before building the selftests, because that approach would work
for all the cases I've seen so far.

If we want something else, then David Hildenbrand has listed several
ideas, and I've added a 4th one to the list, in [1].


[1] https://lore.kernel.org/3eadd79c-c02a-495f-92c0-0315046ef59f@nvidia.com


thanks,
-- 
John Hubbard
NVIDIA

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ