linux-kernel - Re: [PATCH v2] xhci: reduce xhci_handshake timeout in xhci

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:   Mon, 14 Feb 2022 14:51:54 +0200
From:   Mathias Nyman <mathias.nyman@...ux.intel.com>
To:     Pavankumar Kondeti <quic_pkondeti@...cinc.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mathias Nyman <mathias.nyman@...el.com>
Cc:     linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        quic_ugoswami@...cinc.com, Jung Daehwan <dh10.jung@...sung.com>
Subject: Re: [PATCH v2] xhci: reduce xhci_handshake timeout in xhci_reset

On 14.2.2022 14.20, Pavankumar Kondeti wrote:
> From: Daehwan Jung <dh10.jung@...sung.com>
> 
> xhci_reset() is called with interrupts disabled. Waiting 10 seconds for
> controller reset and controller ready operations can be fatal to the
> system when controller is timed out. Reduce the timeout to 1 second
> and print a error message when the time out happens.
> 
> Fixes: 22ceac191211 ("xhci: Increase reset timeout for Renesas 720201 host.")

The commit 22ceac191211 ("xhci: Increase reset timeout for Renesas 720201 host.")
intentionally increased the timeout to 10 seconds as that host might take 9
seconds to complete reset. This was done almost 10 years ago so I don't know
if it really is an issue anymore.

Anyways, your patch might break Renesas 72021 instead of fixing it.

I agree that busylooping up to 10 seconds with interrupts disabled doesn't make sense.

Lets see if there is another solution for your case.

- Does a "guard interval" after writing the reset help?
  For example Intel xHCI needs 1ms before touching xHC after writing the reset bit

- Is it the CNR bit or the RESET bit that fails? could be just stuck CNR bit? 

- we only disable local interrupts when xhci_reset() is called from xhci_stop(),
  and sometimes from xhci_shutdown() and xhci_resume() if some conditions are met.
  Have you identified which one is the problematic case?

  I think we halt the host in the above case first, meaning there should be no
  xHC interrupts when xhci_reset() is called. So if we could guarantee xhci interrupt
  isn't handled on this cpu, maybe we could somehow enable local interrupt after 
  halting the host?

  haven't really thought this true yet, but something like this could e investigated:

  spin_lock_irqsave()
  xhci_halt()
  < enable interrupts, magically turn spin_lock_irqsave() to just keeping spin lock>
  xhci_reset()
  spin_unlock()

-Mathias