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]

Message-ID: <CAK8P3a0aDdEt323i=z4BGuh71ntPqm-L33U4q+FiQOdMUin6wg@mail.gmail.com>
Date:   Thu, 14 Mar 2019 08:09:06 +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>,
        Qiuxu Zhuo <qiuxu.zhuo@...el.com>, 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 Thu, Mar 14, 2019 at 12:01 AM Luck, Tony <tony.luck@...el.com> wrote:
>
> On Wed, Mar 06, 2019 at 09:15:13PM +0100, Arnd Bergmann wrote:
> > On Wed, Mar 6, 2019 at 6:58 PM Luck, Tony <tony.luck@...el.com> wrote:
> > > From: Qiuxu Zhuo <qiuxu.zhuo@...el.com>
> > >
> > > This seems cleaner than adding all the EXPORTs to skx_common.c
> > > I also tried a build with the 0x8A152468-config.gz that Arnd
> > > supplied.
> >
> > It's still a bit fragile since you do something that kbuild doesn't
> > expect with having a file in both a module and built-in code
> > in some configurations. I'm fairly sure this version works today,
> > but it would break the next time that file gets changed to include
> > a reference to THIS_MODULE, or anything else that is different
> > between built-in and modular code.
> >
> > Another alternative would be to mark all symbols in this file
> > 'static' and then include skx_common.c from the other two files.
> > Of course that is also ugly and it increases the overall code size,
> > so I don't see a way to win this.
>
> Boris,
>
> So where should we go. Proposed solutions are piling up:
>
> 1) Make skx_common a module
>         [downside: have to EXPORT everything in it]
> 2) Move module-ish bits out of skx_common
>         [downside: perhaps fragile]
> 3) #include skx_common.c into {skx,i10nm}_edac.c
>         [downside: no patch yet, bigger code size]

Sorry to add on to the already long list, but one more idea after
looking at the two files:

4) Have a single driver module, with the skx_common.c containing
    the top-level module_init/module_exit functions that call into the
    hardware specific versions.

This is the opposite of the usual recommendation (the driver
is already structured nicely otherwise), but it would be cheap
way out here.

      Arnd