linux-kernel - Re: [PATCH] EDAC, {skx|i10nm}_edac: Fix randconfig build error

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:   Fri, 22 Mar 2019 20:56:27 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     "Luck, Tony" <tony.luck@...el.com>
Cc:     Borislav Petkov <bp@...en8.de>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        James Morse <james.morse@....com>,
        "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>,
        "linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] EDAC, {skx|i10nm}_edac: Fix randconfig build error

On Fri, Mar 22, 2019 at 6:55 PM Luck, Tony <tony.luck@...el.com> wrote:
>
> On Fri, Mar 22, 2019 at 03:00:25PM +0100, Arnd Bergmann wrote:
> > Sorry, this was my mistake, my email was garbled. The patch was
> > correct though: the idea here is not to change the Kconfig symbols
> > but to change the Makefile to do the right thing even when Kconfig
> > is set wrong.
>
> Well this does seem like a "clever" way out of the randconfig
> problem.  New patch applies and when I set .config to have:
>
> CONFIG_EDAC_DEBUG=y
> CONFIG_EDAC_SKX=y
> CONFIG_EDAC_I10NM=m
> CONFIG_EDAC_SKX_COMMON=y
>
> I don't see any build errors.
>
> There are lots of "skx_" symbols in System.map
>
> But I'm not at all sure what happened to the I10NM driver.
>
> I don't see it mentioned in the output from "make".
>
> It didn't get built as a module (no ".ko" file for it).
>
> It doesn't seem to be built in (no ".o" in drivers/edac/built-in.a)
>
> So I added a #error line to the start of i10nm_edac.c and
> ran "make" again.  Nothing.

Oops, I guess my testing method was also insufficient,
I only checked that the bug was gone, not that it actually
worked.

> So, I don't think this is doing what you think it should
> do.  Even if it did, it would seem very confusing to a user
> that asked for "one module, one built-in" in Kconfig, but
> found both built-in.
>
> Boris: I'm voting for Qiuxu's most recent solution (moving
> all the EDAC_DEBUG bits out of skx_common.c).

Yes, that's probably best then. My patch was likely close to
another correct solution, but I've screwed it up twice now ;-)

     Arnd