linux-kernel - Re: [PATCH v4 05/14] platform/x86: dell-wmi-descriptor: split WMI descriptor into it's own 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: <20171005071153.GA31452@fury>
Date:   Thu, 5 Oct 2017 00:11:53 -0700
From:   Darren Hart <dvhart@...radead.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Mario Limonciello <mario.limonciello@...l.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>, quasisec@...gle.com,
        Pali Rohár <pali.rohar@...il.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>, mjg59@...gle.com,
        Christoph Hellwig <hch@....de>, Greg KH <greg@...ah.com>
Subject: Re: [PATCH v4 05/14] platform/x86: dell-wmi-descriptor: split WMI
 descriptor into it's own driver

On Thu, Oct 05, 2017 at 08:29:10AM +0300, Andy Shevchenko wrote:
> On Thu, Oct 5, 2017 at 4:09 AM, Darren Hart <dvhart@...radead.org> wrote:
> > On Wed, Oct 04, 2017 at 05:48:31PM -0500, Mario Limonciello wrote:
> >> All communication on individual GUIDs should occur in separate drivers.
> >> Allowing a driver to communicate with the bus to another GUID is just
> >> a hack that discourages drivers to adopt the bus model.
> >>
> >> The information found from the WMI descriptor driver is now exported
> >> for use by other drivers.
> 
> > You'll want to add something like:
> >
> > #ifdef CONFIG_DELL_WMI_DESCRIPTOR_MODULE
> >         if (request_module("dell_wmi_descriptor"))
> >                 /* FAIL */
> > #endif
> >
> > During init.
> 
> I don't think #ifdef is needed.

Without the ifdef, we can't distinguish between request_module failing
to load the module because it isn't available and because it is
built-in.

> 
> We may just request module.
> 
> But looking in the code it seems that we simple need to select that
> module. No request_module will be needed.

The select will ensure the module is built, but there is not guarantee
to module load order. The intent of the above is to ensure the symbols
from the required module are loaded.

> Did I miss something?

Or I did :-) Is there something about this module which ensures
dell_wmi_descriptor is loaded first?

-- 
Darren Hart
VMware Open Source Technology Center