linux-kernel - Re: PCI / PM: Crashes in PME scan during system suspend

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:   Tue, 18 Apr 2017 20:39:38 +0200
From:   Lukas Wunner <lukas@...ner.de>
To:     "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Yinghai Lu <yinghai@...nel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Simon Horman <horms@...ge.net.au>,
        linux-pci <linux-pci@...r.kernel.org>,
        Linux PM list <linux-pm@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Niklas Söderlund 
        <niklas.soderlund@...natech.se>
Subject: Re: PCI / PM: Crashes in PME scan during system suspend

On Tue, Apr 18, 2017 at 04:06:27PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, April 18, 2017 08:49:39 AM Geert Uytterhoeven wrote:
> > On Sun, Apr 16, 2017 at 9:55 AM, Lukas Wunner <lukas@...ner.de> wrote:
> > > Subject: [PATCH] PCI: Freeze PME scan before suspending devices
> > >
> > > Laurent Pinchart reported that the Renesas R-Car H2 Lager board
> > > (r8a7790) crashes during suspend tests.  Geert Uytterhoeven managed to
> > > reproduce the issue on an M2-W Koelsch board (r8a7791):
> > >
> > > It occurs when the PME scan runs, once per second.  During PME scan, the
> > > PCI host bridge (rcar-pci) registers are accessed while its module clock
> > > has already been disabled, leading to the crash.
> > >
> > > The issue only occurs during suspend tests, after writing either
> > > "platform" or "processors" to /sys/power/pm_test.  It does not (or is
> > > less likely) to happen during full system suspend ("core" or "none")
> > > because system suspend also disables timers, and thus the workqueue
> > > handling PME scans no longer runs.  Geert believes the issue may still
> > > happen in the small window between disabling module clocks and disabling
> > > timers.
> > 
> > It can also be reproduced easily by configuring s2ram to use s2idle instead
> > of deep suspend, which is a real usecase:
> > 
> > # echo 0 > /sys/module/printk/parameters/console_suspend
> > # echo s2idle > /sys/power/mem_sleep
> > # echo mem > /sys/power/state
> > 
> > Tested-by: Geert Uytterhoeven <geert+renesas@...der.be>
> 
> There is a small concern here that some wakeup events may be missed if they
> are delivered via PME without a working IRQ, but that's fairly minor and it
> cannot be avoided entirely, so

Well, that's a conundrum.  I don't know which devices depend on PME polling
and whether they may signal PME between freezing the workqueue and suspending
the host bridge.  If this unexpectedly turns out to be a problem in practice,
it might be possible to solve it by calling pci_pme_list_scan() once directly
from one of the host bridge's pm_ops callbacks.

I've amended the commit message with the tags and additional information
provided by you and Geert and will resend the patch to the list shortly.

Thanks,

Lukas