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>] [day] [month] [year] [list]
Date:   Mon, 7 Jun 2021 00:28:17 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Radim Pavlik <radim.pavlik@...-biometrics.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Thomas Preston <thomas.preston@...ethink.co.uk>,
        Jan Kundrát <jan.kundrat@...net.cz>,
        Phil Reid <preid@...ctromag.com.au>,
        Lars Poeschel <poeschel@...onage.de>,
        Jason Kridner <jkridner@...il.com>
Cc:     "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] pinctrl: mcp23s08: fix race condition in irq handler

On Tue, Jun 1, 2021 at 12:48 PM Radim Pavlik
<radim.pavlik@...-biometrics.com> wrote:

> Checking value of MCP_INTF in mcp23s08_irq suggests that the handler may be
> called even when there is no interrupt pending.
>
> But the actual interrupt could happened between reading MCP_INTF and MCP_GPIO.
> In this situation we got nothing from MCP_INTF, but the event gets acknowledged
> on the expander by reading MCP_GPIO. This leads to losing events.
>
> Fix the problem by not reading any register until we see something in MCP_INTF.
>
> The error was reproduced and fix tested on MCP23017.
>
> Signed-off-by: Radim Pavlik <radim.pavlik@...-biometrics.com>

The patch makes perfect sense to me.

This message was mangled really seriously and could not be
applied, but since the patch was simple I recreated it locally
and applied for fixes.

It also seems the lore mail archive has not accepted it.

> +       if (intf == 0) {
> +               /* There is no interrupt pending */
> +               goto unlock;
> +       }
>          if (mcp_read(mcp, MCP_INTCAP, &intcap))
>                  goto unlock;
>
> @@ -368,10 +372,6 @@ static irqreturn_t mcp23s08_irq(int irq, void *data)
>          mcp->cached_gpio = gpio;
>          mutex_unlock(&mcp->lock);
>
> -       if (intf == 0) {
> -               /* There is no interrupt pending */
> -               return IRQ_HANDLED;
> -       }

Paging some other mcp28s08 users to make sure they don't have
a problem with this.

Yours,
Linus Walleij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ