Re: Linux v5.0-rc7: bcm2835 MMC issues

From: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
To: Aaro Koskinen <aaro.koskinen-X3B1VOXEql0@public.gmane.org>
Cc: linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: Linux v5.0-rc7: bcm2835 MMC issues
Date: Sat, 30 Mar 2019 16:13:01 +0100 (CET)	[thread overview]
Message-ID: <1917947427.237135.1553958781997@email.ionos.de> (raw)
In-Reply-To: <20190330145300.GI16484-4/PLUo9XfK9owWHViPbQSXlKr5M7+etX9Sl0XMgJPXI@public.gmane.org>

> Aaro Koskinen <aaro.koskinen@iki.fi> hat am 30. März 2019 um 15:53 geschrieben:
> 
> 
> Hi,
> 
> On Sat, Mar 30, 2019 at 02:15:33PM +0100, Stefan Wahren wrote:
> > > > [ 1164.390902] 
> > > > [ 1164.398302] ======================================================
> > > > [ 1164.416501] WARNING: possible circular locking dependency detected
> > > > [ 1164.434710] 5.1.0-rc2-rpi3-los_6ba38c+-00247-g9936328b41ce-dirty #1 Not tainted
> > > > [ 1164.454495] ------------------------------------------------------
> > > > [ 1164.472908] cc1plus/30873 is trying to acquire lock:
> > > > [ 1164.489750] 0000000040a8ff57 (&mq->complete_lock){+.+.}, at: mmc_blk_mq_complete_prev_req.part.12+0x3c/0x220
> > > > [ 1164.518548] 
> > > > [ 1164.518548] but task is already holding lock:
> > > > [ 1164.541662] 0000000059d7e9bb (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.19+0x0/0x40
> > > > [ 1164.567105] 
> > > > [ 1164.567105] which lock already depends on the new lock.
> > > > [ 1164.567105] 
> > > > [ 1164.595691] 
> > > > [ 1164.595691] the existing dependency chain (in reverse order) is:
> > > > [ 1164.616711] 
> > > > [ 1164.616711] -> #2 (fs_reclaim){+.+.}:
> > > > [ 1164.630507]        lock_acquire+0xe8/0x250
> > > > [ 1164.638922]        fs_reclaim_acquire.part.19+0x34/0x40
> > > > [ 1164.652170]        fs_reclaim_acquire+0x20/0x28
> > > > [ 1164.665139]        __kmalloc+0x50/0x390
> > > > [ 1164.673717]        bcm2835_dma_create_cb_chain+0x70/0x270
> > >
> > > I think the bug is that it's using GFP_KERNEL here.
> > 
> > Hm, i'm not sure about how to solve this properly. Can you try this,
> > because i wasn't able to reproduce this:
> 
> Steps to reproduce:
> - Enable LOCKDEP (Kernel hacking -> Lock debugging -> prove locking correctness)

Thanks for clarifying. This is PROVE_LOCKING, not just DEBUG_LOCKDEP.

> - File system and swap on MMC
> - Disable watchdog if it's running
> - Create a process that eats all memory:
> 
>   perl -e ' $x = "foo"; while (1) { $x .= $x } '
> 
> The warning shows up almost instantly. Also beware, the system gets
> totally stuck in a while, so it seems the deadlock actually happens
> (if you enable CONFIG_DETECT_HUNG_TASK it shows MMC is stuck).
> 
> > diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> > index ec8a291..54093ff 100644
> > --- a/drivers/dma/bcm2835-dma.c
> > +++ b/drivers/dma/bcm2835-dma.c
> > @@ -671,7 +671,7 @@ static struct dma_async_tx_descriptor *bcm2835_dma_prep_slave_sg(
> >         d = bcm2835_dma_create_cb_chain(chan, direction, false,
> >                                         info, extra,
> >                                         frames, src, dst, 0, 0,
> > -                                       GFP_KERNEL);
> > +                                       GFP_NOWAIT);
> >         if (!d)
> >                 return NULL;
> 
> Yeah, that helps. I think bcm2835_dma_prep_dma_memcpy needs it as well,
> so bcm2835_dma_create_cb_chain could just always use GFP_NOWAIT. 

As long there is no issue, i would keep it.

> 
> A.

_______________________________________________
linux-rpi-kernel mailing list
linux-rpi-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel