Re: mtdswap + ubi results in deadlock

[Emil Lenngren <emil.lenngren@xxxxxxxxx>]

Hi,

Den tis 15 okt. 2019 kl 20:59 skrev Richard Weinberger
<richard.weinberger@xxxxxxxxx>:
>
> Emil,
>
> On Tue, Oct 15, 2019 at 7:00 PM Emil Lenngren <emil.lenngren@xxxxxxxxx> wrote:
> >
> > Hi. I'm trying to use mtdswap together with ubi increase memory.
> > Normally mtdswap has its own wear leveling but I want ubi to do that
> > job instead. So I removed all wear leveling and oob usage from mtdswap
> > (or really it doesn't do wear leveling if the mtd device has no oob)
> > and am now using it with a gluebi mtd partition on top of ubi. It
> > works good but in some occasions it deadlocks because ubi internally
> > uses kmalloc, which in case of low memory, waits for swap to complete.
> > But swap won't complete until the data is written to flash.
> >
> > Do you have any idea how to mitigate this issue?
>
> Well, if you use UBI for swap then no memory allocation within UBI is allowed
> to trigger swapping. Otherwise the memory allocation goes into
> recursion and locks
> up. This is what happens in your case.
>
> You can try to pinpoint these allocations and use GFP_NOFS there but I fear
> that will case other problems.

Thanks for the tip, I'll try that. But just trying to find some
information about GFP_NOFS, I found this article from 2003
https://lwn.net/Articles/22909/. It says "The GFP_NOIO flag allows
sleeping, but no I/O operations will be started to help satisfy the
request. GFP_NOFS is a bit less restrictive; some I/O operations can
be started (writing to a swap area, for example), but no filesystem
operations will be performed.". I'm not sure how much has changed
since 2003 but if I interpret it correctly then GFP_NOFS wouldn't work
since that can still trigger a swap, which would result in the same
recursive deadlock?

/Emil

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