[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1438532122-25368-1-git-send-email-khoroshilov@ispras.ru>
Date: Sun, 2 Aug 2015 23:15:22 +0700
From: Alexey Khoroshilov <khoroshilov@...ras.ru>
To: Andreas Larsson <andreas@...sler.com>,
Linus Walleij <linus.walleij@...aro.org>
Cc: Alexey Khoroshilov <khoroshilov@...ras.ru>,
Alexandre Courbot <gnurou@...il.com>,
linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
ldv-project@...uxtesting.org
Subject: Deadlock in grgpio_irq_unmap()
Dear colleagus,
grgpio_irq_unmap() code looks quite suspicious regarding usage of
priv->bgc.lock spinlock.
It locks the spinlock in line 310:
spin_lock_irqsave(&priv->bgc.lock, flags);
and then it can call grgpio_set_imask() in line 317:
grgpio_set_imask(priv, i, 0);
But grgpio_set_imask() unconditionally locks the spinlock by itself.
static void grgpio_set_imask(struct grgpio_priv *priv, unsigned int offset,
int val)
{
struct bgpio_chip *bgc = &priv->bgc;
unsigned long mask = bgc->pin2mask(bgc, offset);
unsigned long flags;
spin_lock_irqsave(&bgc->lock, flags);
if (val)
priv->imask |= mask;
else
priv->imask &= ~mask;
bgc->write_reg(priv->regs + GRGPIO_IMASK, priv->imask);
spin_unlock_irqrestore(&bgc->lock, flags);
}
So, it looks like unavoidable deadlock here.
Found by Linux Driver Verification project (linuxtesting.org).
--
Alexey Khoroshilov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
--
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/
Powered by blists - more mailing lists