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  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]
Date:   Wed, 14 Mar 2018 01:28:54 +0000
From:   <Mario.Limonciello@...l.com>
To:     <dvhart@...radead.org>
CC:     <linux@...inikbrodowski.net>,
        <platform-driver-x86@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: RE: Dell Inc. XPS 13 9343/0TM99H fails to boot v4.16-rc5

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@...radead.org]
> Sent: Wednesday, March 14, 2018 5:43 AM
> To: Limonciello, Mario <Mario_Limonciello@...l.com>
> Cc: linux@...inikbrodowski.net; platform-driver-x86@...r.kernel.org; linux-
> kernel@...r.kernel.org
> Subject: Re: Dell Inc. XPS 13 9343/0TM99H fails to boot v4.16-rc5
> 
> On Tue, Mar 13, 2018 at 07:07:26AM +0000, Mario.Limonciello@...l.com wrote:
> > > -----Original Message-----
> > > From: Dominik Brodowski [mailto:linux@...inikbrodowski.net]
> > > Sent: Tuesday, March 13, 2018 2:44 PM
> > > To: Limonciello, Mario <Mario_Limonciello@...l.com>; Darren Hart
> > > <dvhart@...radead.org>
> > > Cc: platform-driver-x86@...r.kernel.org; linux-kernel@...r.kernel.org
> > > Subject: Re: Dell Inc. XPS 13 9343/0TM99H fails to boot v4.16-rc5
> > >
> > > On Tue, Mar 13, 2018 at 06:12:04AM +0000, Mario.Limonciello@...l.com wrote:
> > > > As long as they're ready before dell-laptop's initialization which uses
> > > > late_initcall that should be fine.
> > > >
> > > > Am I correct to presume you're going to propose a patch you can test and
> > > > confirm your hypothesis rather than Darren reverting my patch to bring
> > > > them together?
> > >
> > > Thanks for the input; a draft patch (which works fine on my system) is
> > > attached below.
> > >
> > > On Mon, Mar 12, 2018 at 11:32:13PM -0700, Darren Hart wrote:
> > > > There is one other caveat, which you'll find documented in
> > > > dell-laptop.c, namely that dell-laptop needs to init after dell-rbtn
> > > > (I'm starting to appreciate the monolithic thinkpad-acpi driver).
> > > >
> > > > We need things to init in this order (items on the same line have no
> > > > dependency):
> > > >
> > > > 1. DCDBAS, ACPI_WMI
> > > > 2. DELL_SMBIOS, DELL_RBTN
> > > > 3. DELL_LAPTOP, DELL_WMI
> > > >
> > > > Currently:
> > > > subsys_initcall: ACPI_WMI, DELL_SMBIOS
> > > > module_init: DCDBAS, DELL_WMI
> > > > late_initcall: DELL_LAPTOP
> > > >
> > > > From a quick naive glance, it appears as though we might be able to
> > > > address this as follows:
> > > >
> > > > subsys_initcall: DCDBAS, ACPI_WMI
> > > > module_init: DELL_SMBIOS, DELL_RBTN
> > > > late_initcall: DELL_LAPTOP, DELL_WMI
> > >
> > > Hmmm. I do not yet understand why you propose to
> > >
> > > a) advance the DCDBAS initialization to subsys_initcall, as only DELL_LAPTOP
> > >    (running as a late_initcall) requires it to be up and running, and
> >
> > Actually dell-smbios itself should require this too.  The SMM backend will use
> > it during initialization to determine if WSMT is enabled.  If it's not operational
> > yet then we may get invalid results.
> >
> 
> Exactly.
> 
> > So considering this I think Darren's proposal is good to move DCDBAS to earlier.
> >
> > >
> > > b) delay DELL_WMI to late_initcall, as it can safely be initialized as long
> > >    as ACPI_WMI is ready.
> >
> > Maybe Darren meant dell-wmi-descriptor not dell-wmi?
> > Otherwise I would agree that part isn't needed.
> 
> Like DELL_LAPTOP, DELL_WMI depends on smbios being ready, so needs to
> init after DELL_SMBIOS as well.
> 
> --

OK thanks for explaining.

Dominik,

Can you please verify if Darren's patch works for you too?

Darren,

If that patch works for Dominik, I'm fine with that for 4.16 if you keep
this series, otherwise we can retry for 4.17 and squash the various patches
together.

Thanks,

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ