linux-kernel - Re: [PATCH v1] driver core: Fix suspend/resume order issue with deferred probe

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGETcx8KknvzZxfW4o=siswB__c9yeh=1wOVyvtM2112WEBizQ@mail.gmail.com>
Date:   Fri, 26 Jun 2020 13:34:13 -0700
From:   Saravana Kannan <saravanak@...gle.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        "Cc: Android Kernel" <kernel-team@...roid.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] driver core: Fix suspend/resume order issue with
 deferred probe

On Fri, Jun 26, 2020 at 4:27 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Thu, Jun 25, 2020 at 7:52 PM Saravana Kannan <saravanak@...gle.com> wrote:
> >
> > On Thu, Jun 25, 2020 at 10:47 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
> > >
> > > Note that deferred probing gets in the way here and so the problem is
> > > related to it.
> >
> > I mean, we officially support deferred probing. Shouldn't we fix it so
> > that it doesn't break suspend/resume?
>
> Yes, we should fix deferred probing.
>
> > Also, it's pretty easy to have
> > cases where one module probes multiple device instances and loading it
> > in one order would break dpm_list order for one device and loading it
> > in another order would break it for another device. And there would be
> > no "proper" order to load modules (because module order != device
> > order).
>
> I'm not saying that the current code is perfect.  I'm saying that the
> fix as proposed adds too much cost for everybody who may not care IMO.

Ok, how about I don't do this reordering until we see the first
deferred probe request? Will that work for you? In that case, systems
with no deferred probing will not incur any reordering cost. Or if
reordering starts only towards the end, all the previous probes won't
incur reordering cost.

I'm open to other suggestions too.

>
> > >
> > > Yes, it is, I'm afraid.  There are devices without drivers. :-)
> >
> > Devices that still suspend/resume without drivers?! I didn't know that
> > was possible.
>
> There are "class" devices, "type" devices and devices that simply have
> no drivers, but the bus type code may still want to touch them during
> system-wide suspend/resume.
>
> Modules may still not be loaded when the system is suspended for the
> first time etc.

Thanks for the context.


-Saravana