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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 10 Jul 2020 13:47:43 -0700
From:   Saravana Kannan <saravanak@...gle.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.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, Jul 10, 2020 at 6:21 AM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>
> On Tue, Jun 30, 2020 at 10:11:01AM -0700, Saravana Kannan wrote:
> > I already have a patch to avoid deferred probe during batch fwnode
> > parsing. I'm trying to do a few more tests before I send it out. So,
> > it'd be nice if we don't revert it right now and give me some time to
> > finish testing.
>
> So this series is no longer needed given your other series that I just
> took?

This series is no longer needed to fix the issue with fw_devlink
optimization that Geert was seeing. The other series you pulled in
takes care of Geert's issue.

But deferred probe can still break suspend/resume ordering (example
mentioned in the commit text). So I think we should fix that (version
X of this patch).

Rafael was concerned about some of the extra work v1 will cause for
cases that work fine today. So, we need to find a compromise where we
can fix the issue and optimize the fix as much as possible.

One optimization we can do is to call device_pm_move_to_tail(dev) in
really_probe() only after deferred probe is triggered (as in the
thread gets to run) for the first time. Until then, really_probe()
wouldn't have to call device_pm_move_to_tail(dev);

-Saravana