linux-kernel - Re: [PATCH 4.4 42/76] mmc: sdhci: Do not disable interrupts while waiting for clock

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:   Thu, 6 Apr 2017 14:12:09 +0200
From:   Ludovic Desroches <ludovic.desroches@...rochip.com>
To:     Ben Hutchings <ben.hutchings@...ethink.co.uk>
CC:     Ulf Hansson <ulf.hansson@...aro.org>,
        <linux-kernel@...r.kernel.org>, <stable@...r.kernel.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Ludovic Desroches <ludovic.desroches@...rochip.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 4.4 42/76] mmc: sdhci: Do not disable interrupts while
 waiting for clock

On Tue, Apr 04, 2017 at 05:50:50PM +0100, Ben Hutchings wrote:
> On Tue, 2017-03-28 at 14:30 +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Adrian Hunter <adrian.hunter@...el.com>
> > 
> > commit e2ebfb2142acefecc2496e71360f50d25726040b upstream.
> > 
> > Disabling interrupts for even a millisecond can cause problems for some
> > devices. That can happen when sdhci changes clock frequency because it
> > waits for the clock to become stable under a spin lock.
> > 
> > The spin lock is not necessary here. Anything that is racing with changes
> > to the I/O state is already broken. The mmc core already provides
> > synchronization via "claiming" the host.
> [...]
> 
> In mainline, drivers/mmc/host/sdhci-of-at91.c has a slightly different
> version of this code that seems to have the same issue.  In 4.4 there's
> another (conditional) mdelay(1) further up this function that seems to
> be related to that hardware, and probably ought to have an unlock/lock
> around it.

Right, how do you want to proceed? Do you want me to send a patch on top
of it to manage this extra mdelay?

Regards

Ludovic