linux-kernel - Re: [RFC] cxl_test: upgrade as a first class citizen selftests capable driver

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: <63a2124db0877_1bf229440@dwillia2-xfh.jf.intel.com.notmuch>
Date:   Tue, 20 Dec 2022 11:51:41 -0800
From:   Dan Williams <dan.j.williams@...el.com>
To:     Luis Chamberlain <mcgrof@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>
CC:     <alison.schofield@...el.com>, <vishal.l.verma@...el.com>,
        <ira.weiny@...el.com>, <bwidawsk@...nel.org>, <dave@...olabs.net>,
        <a.manzanares@...sung.com>, <linux-cxl@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] cxl_test: upgrade as a first class citizen selftests
 capable driver

Luis Chamberlain wrote:
> On Mon, Dec 19, 2022 at 04:27:10PM -0800, Dan Williams wrote:
> > Luis Chamberlain wrote:
> > > On Fri, Dec 16, 2022 at 08:55:19PM -0800, Dan Williams wrote:
> > > > In other words the suggestion that the current
> > > > organization ultimately leads to bit rot has not been substantiated in
> > > > practice.
> > > 
> > > On top of this patch I just added a custom debug patch to my tree which
> > > enables CXL_BUS and CXL_TEST by default when this is currently allowed
> > > and it got quite a bit of kernel build warnings. Although some of these
> > > are specific to my change, some of them do not seem to be related to
> > > that and likely could benefit from fixing:
> > > 
> > > https://gist.github.com/mcgrof/73dce72939590c6edc9413b0384ae4c2
> > > 
> > > And so although you may not see some build warnings so far, it does not
> > > negate my suggestion that having cxl_test as a proper upstream driver strategy
> > > gets you more build testing / coverage.
> > 
> > If autobuild coverage of test components is the main concern then
> > cxl_test can copy what nfit_test is doing with CONFIG_NVDIMM_TEST_BUILD.
> > No need for disruptive redesign of how this facility is integrated.
> 
> I've itemized a list of gains of having this properly integrated. What
> gains are there of this being an external module other than a few folks
> are used to it and it been done before for other subsystems?

Your crash report is a prime example of why this needs to stay an
external module. Any redefinition of what a symbol does via --wrap= is a
fragile proposition. The fact that crash signatures with cxl_test loaded
have the external module taint flag set is a feature. The --wrap= option
has no business within the main tree because it violates the valid
assumptions of other cxl_test-innocent developers.

The benefit that resonated with me during this discussion was more
compile test coverage for cxl_test components. However, that is achieved
by tools/testing/cxl/ adopting the same compile coverage scheme that
tools/testing/nvdimm/ has with CONFIG_NVDIMM_TEST_BUILD.