linux-kernel - Re: [PATCH v2 0/2] USB: Quiesce interrupts across pm freeze

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]

Date:   Tue, 19 Apr 2022 10:35:59 -0400
From:   Alan Stern <stern@...land.harvard.edu>
To:     Oliver Neukum <oneukum@...e.com>
Cc:     Evan Green <evgreen@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Mathias Nyman <mathias.nyman@...el.com>,
        Rajat Jain <rajatja@...omium.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Razvan Heghedus <heghedus.razvan@...il.com>,
        Wei Ming Chen <jj251510319013@...il.com>,
        Youngjin Jang <yj84.jang@...sung.com>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH v2 0/2] USB: Quiesce interrupts across pm freeze

On Tue, Apr 19, 2022 at 09:05:53AM +0200, Oliver Neukum wrote:
> 
> 
> On 18.04.22 23:00, Evan Green wrote:
> > The documentation for the freeze() method says that it "should quiesce
> > the device so that it doesn't generate IRQs or DMA". The unspoken
> > consequence of not doing this is that MSIs aimed at non-boot CPUs may
> > get fully lost if they're sent during the period where the target CPU is
> > offline.
> >
> > The current behavior of the USB subsystem still allows interrupts to
> > come in after freeze, both in terms of remote wakeups and HC events
> > related to things like root plug port activity. This can get controllers
> > like XHCI, which is very sensitive to lost interrupts, in a wedged
> > state. This series attempts to fully quiesce interrupts coming from USB
> > across in a freeze or quiescent state.
> >
> > These patches are grouped together because they serve a united purpose,
> > but are actually independent. They could be merged or reverted
> > individually.
> Hi,
> 
> sorry for being a bit late in this discussion. There was something that
> I didn't remember immediately.
> 
> We have a set of quirky devices that need HID_QUIRK_ALWAYS_POLL.
> They have the nasty firmware bug that, if you suspend them without
> remote wakeup, they will crash or reset themselves.
> I am afraid that has an obvious relevance to your cool patches.
> I am not completely sure how to deal with this. It seems to me that the
> quirk will need to be shifted from HID to core USB and thaw() needs to
> be translated into usb_device_reset() + reset_resume() for them,
> but I am not really sure about the optimal mechanism.

We may not need to do anything.  This patch specifically addresses 
hibernation, not system suspend or runtime suspend.  A device crashing 
or resetting during hibernation is not at all unusual; we should be able 
to handle such cases properly.

The THAW part of suspend-to-hibernation is used only for writing the 
memory image to permanent storage.  I doubt that a malfunctioning HID 
device would interfere with this process.

Alan Stern