Re: hung task detected in ubifs

[Martin Townsend <mtownsend1973@xxxxxxxxx>]

On Thu, Dec 20, 2018 at 1:15 PM Richard Weinberger <richard@xxxxxx> wrote:
>
> Am Donnerstag, 20. Dezember 2018, 14:07:45 CET schrieb Martin Townsend:
> > Hi Richard,
> >
> > On Thu, Dec 20, 2018 at 10:54 AM Richard Weinberger
> > <richard.weinberger@xxxxxxxxx> wrote:
> > >
> > > On Thu, Dec 20, 2018 at 10:49 AM Martin Townsend
> > > <mtownsend1973@xxxxxxxxx> wrote:
> > > > 5 locks held by programmingapp/930:>  #0:  (&mm->mmap_sem){......}, at: [<80113ef0>] do_page_fault+0xb8/0x350
> > > >  #1:  (&le->mutex){......}, at: [<80568150>] ubi_eba_read_leb+0x34/0x438
> > > >  #2:  (of_dma_lock){......}, at: [<804ab890>]
> > > > of_dma_request_slave_channel+0x140/0x228
> > > >  #3:  (dma_list_mutex){......}, at: [<804a9d3c>] __dma_request_channel+0x24/0x8c
> > > >  #4:  (cma_mutex){......}, at: [<80246814>] cma_alloc+0xc8/0x29c
> > >
> > > The system seems to block in CMA, therefore make_reservation() does not make any
> > > progress and all write back blocks too.
> > > Do you have CONFIG_MIGRATION enabled?
> > >
> > > If possible, enable LOCKDEP, it can give us more details what is going on.
> > >
> > > --
> > > Thanks,
> > > //richard
> >
> > I just checked and CONFIG_MIGRATION=y.
>
> Hmm, that should be ok.
> I expected CONFIG_MIGRATION=n.
>
> In the meanwhile you can also try that patch:
> http://lists.infradead.org/pipermail/linux-mtd/2018-December/086389.html
>
> It fixes allocation failures of CMA.
> But I'm not sure whether you're facing the same problem.
>
> > Interesting that it seems to block in the CMA, could it be that the
> > programmingapp process has used up all the CMA memory?  I'll ask for a
> > complete log file.
>
> I don't know what the system is doing.
> Does it really(!) deadlock or does it just take very long to continue?
> (Lockdep should be able to tell...)
>
> The MTD driver seems to do DMA which uses CMA to allocate memory.
> So we need to understand why the CMA allocation blocks (forever?).
> From the current picture I cannot tell whether UBIFS is the root cause
> or just a victim.
>
> Thanks,
> //richard
>
>
>
The hung task timeout is the default 2 minutes and it's setup to panic
so I don't know if it recovers. I'll ask them to try a longer value or
disable the panic and see if it recovers.
I checked and LOCKDEP=y and the held locks are in the original trace.
Are there particular locking checks you would like? Currently its
setup like this:
  │ │    [*] RT Mutex debugging, deadlock detection
  │ │    -*- Spinlock and rw-lock debugging: basic checks
  │ │    -*- Mutex debugging: basic checks
  │ │    [ ] Wait/wound mutex debugging: Slowpath testing
  │ │    [*] Lock debugging: detect incorrect freeing of live locks
  │ │    [ ] Lock debugging: prove locking correctness
  │ │    [ ] Lock usage statistics
  │ │    [ ] Lock dependency engine debugging
  │ │    [*] Sleep inside atomic section checking
  │ │    [ ] Locking API boot-time self-tests
  │ │    < > torture tests for locking

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/