Re: iomap: writeback ioend/bio allocation deadlock risk

[Ming Lei <ming.lei@redhat.com>]

On Fri, May 21, 2021 at 09:17:27AM +0200, Christoph Hellwig wrote:
> On Fri, May 21, 2021 at 11:27:54AM +0800, Ming Lei wrote:
> >         if %__gfp_direct_reclaim is set then bio_alloc will always be able to
> >         allocate a bio.  this is due to the mempool guarantees.  to make this work,
> >         callers must never allocate more than 1 bio at a time from the general pool.
> >         callers that need to allocate more than 1 bio must always submit the
> >         previously allocated bio for io before attempting to allocate a new one.
> >         failure to do so can cause deadlocks under memory pressure.
> > 
> > 1) more than one ioends can be allocated from 'iomap_ioend_bioset'
> > before submitting them all, so mempoll guarantee can't be made, which can
> > be observed frequently in writeback over ext4
> > 
> > 2) more than one chained bio(allocated from fs_bio_set) via iomap_chain_bio,
> > which is easy observed when writing big files on XFS:
> 
> The comment describing bio_alloc_bioset is actually wrong.  Allocating

OK, we can fix the doc, but...

> more than 1 at a time is perfectly fine, it just can't be more than
> the pool_size argument passed to bioset_init.
> 
> iomap_ioend_bioset is sized to make sure we can always complete up
> to 4 pages, and the list is only used inside a page, so we're fine.

The number itself does not matter, because there isn't any limit on how
many ioends can be allocated before submitting, for example, it can be
observed that 64 ioends is allocated before submitting when writing
5GB file to ext4. So far the reserved pool size is 32.

> 
> fs_bio_set always has two entries to allow exactly for the common
> chain and submit pattern.

It is easy to trigger dozens of chained bios in one ioend when writing
big file to XFS.


Thanks,
Ming