linux-kernel - Re: [PATCH 2/3] mmc: sdhci: check interrupt flags in ISR again

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:	Wed, 14 Mar 2012 08:53:05 +0100
From:	Alexander Stein <alexander.stein@...tec-electronic.com>
To:	Adrian Hunter <adrian.hunter@...el.com>
Cc:	Chris Ball <cjb@...top.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH 2/3] mmc: sdhci: check interrupt flags in ISR again

Hello,

Am Mittwoch, 14. März 2012, 09:39:02 schrieb Adrian Hunter:
> On 13/03/12 19:16, Alexander Stein wrote:
> > When using MSI it is possible that a new MSI is sent while an earlier
> > MSI is currently handled. In this case SDHCI_INT_STATUS only contains
> > SDHCI_INT_RESPONSE and the ISR would not be called again. But at the end
> > of the ISR SDHCI_INT_DATA_END is now also pending which would be
> > ignored.
> > 
> > Fix this by rereading the interrupt flags in the ISR until no interrupt
> > we care is pending.
> > 
> > Signed-off-by: Alexander Stein <alexander.stein@...tec-electronic.com>
> [...]
> > @@ -2336,6 +2338,14 @@ static irqreturn_t sdhci_irq(int irq, void
> > *dev_id)> 
> >  		sdhci_writel(host, SDHCI_INT_BUS_POWER, SDHCI_INT_STATUS);
> >  	
> >  	}
> > 
> > +	intmask_unhandled = intmask;
> > +
> > +	intmask = sdhci_readl(host, SDHCI_INT_STATUS);
> > +
> > +	/* Do interrupt handling again if we got new flags */
> > +	if (intmask & ~intmask_unhandled)
> > +		goto again;
> > +
> > 
> >  	intmask &= ~SDHCI_INT_BUS_POWER;
> >  	
> >  	if (intmask & SDHCI_INT_CARD_INT)
> 
> Why not just replace mmiowb() i.e.
> 
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 8d66706..da8a101 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2353,7 +2353,9 @@ static irqreturn_t sdhci_irq(int irq, void *dev_id)
> 
>         result = IRQ_HANDLED;
> 
> -       mmiowb();
> +       intmask = sdhci_readl(host, SDHCI_INT_STATUS);
> +       if (intmask)
> +               goto again;
>  out:
>         spin_unlock(&host->lock);
> 

Well, I chose this way to only printk the error once. With your suggestion it 
might be printed in each loop, dunno how often/fast these IRQ stats are set 
again after clearing. This would end in an endless loop if error flags are set 
again fast enough, but see below.
But in general I like this approach.

> But maybe it would be safer limiting the number of loops i.e.
> 
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 8d66706..d88247d 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2268,7 +2268,7 @@ static irqreturn_t sdhci_irq(int irq, void *dev_id)
>         irqreturn_t result;
>         struct sdhci_host *host = dev_id;
>         u32 intmask;
> -       int cardint = 0;
> +       int cardint = 0, max_loops = 16;
> 
>         spin_lock(&host->lock);
> 
> @@ -2353,7 +2353,9 @@ static irqreturn_t sdhci_irq(int irq, void *dev_id)
> 
>         result = IRQ_HANDLED;
> 
> -       mmiowb();
> +       intmask = sdhci_readl(host, SDHCI_INT_STATUS);
> +       if (intmask && --max_loops)
> +               goto again;
>  out:
>         spin_unlock(&host->lock);

The actual problem I saw was a CMD6 command with an R1b response where the IRQ 
for the 'not busy' event was sent during ISR for the response. So I think 
normally this should only occur once.
Regarding error flags I masked the unhandled flags out in order to print an 
error only once, even if they might be set again in the next loop. With a 
simple check on intmask they might occur up to 16 times in the kernel log.
IMHO it makes no sense to repeatedly print errors about interrupt flags we 
don't handle.

Suggestions to get a more clean way?

Best regards,
Alexander
-- 
Dipl.-Inf. Alexander Stein

SYS TEC electronic GmbH
August-Bebel-Str. 29
D-07973 Greiz

Tel: +49-3661-6279-0, Fax: +49-3661-6279-99
eMail:    Alexander.Stein@...tec-electronic.com
Internet: http://www.systec-electronic.com

Managing Director: Dipl.-Phys. Siegmar Schmidt
Commercial registry: Amtsgericht Jena, HRB 205563
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/