linux-kernel - RE: [PATCH] Drivers: hv: vmbus: Fix harmless building warnings without CONFIG

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] [day] [month] [year] [list]

Message-ID: <PU1P153MB016961C78DA0656E479C5F15BF880@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
Date:   Fri, 20 Sep 2019 21:02:16 +0000
From:   Dexuan Cui <decui@...rosoft.com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        "sashal@...nel.org" <sashal@...nel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Michael Kelley <mikelley@...rosoft.com>
Subject: RE: [PATCH] Drivers: hv: vmbus: Fix harmless building warnings
 without CONFIG_PM

> From: Arnd Bergmann <arnd@...db.de>
> Sent: Friday, September 20, 2019 12:33 AM
> On Thu, Sep 19, 2019 at 11:38 PM Dexuan Cui <decui@...rosoft.com> wrote:
> > > Sent: Thursday, September 19, 2019 5:11 AM
> > > On Thu, Sep 19, 2019 at 7:19 AM Dexuan Cui <decui@...rosoft.com>
> wrote:
> 
> > > I think this will still produce a warning if CONFIG_PM is set but
> > > CONFIG_PM_SLEEP is not, possibly in other configurations as
> > > well.
> >
> > You're correct. Thanks!
> >
> > I'll use " #ifdef CONFIG_PM_SLEEP ... #endif" instead.
> >
> > The mentioned functions are only used in the micros
> > SET_NOIRQ_SYSTEM_SLEEP_PM_OPS, which is empty if CONFIG_PM_SLEEP
> > is not defined. So it looks to me using "#ifdef CONFIG_PM_SLEEP ..." should
> > resolve the issue.
> 
> Probably, yes. There are sometimes surprising effects, such as when one of the
> functions inside of the #ifdef call another function that is otherwise unused.

I reviewed the related functions again and I believe with the v2 we don't have
such an issue as you described here.
 
> I would normally try to build a few hundred randconfig builds to be fairly sure
> of a change like this, or use __maybe_unused like most other drivers do here.
> 
>        Arnd

I do see a lot of drivers using __maybe_unused, but IMO conditional
compilation is slightly better. In case conditional compilation still has some
unexpected issue, we can always make a further fix. :-)

Thanks,
-- Dexuan