Re: 2.4.19pre3aa2

[Andrea Arcangeli <andrea@suse.de>]

On Sat, Mar 16, 2002 at 02:10:27PM +0200, Jari Ruusu wrote:
> Andrea Arcangeli wrote:
> > Nevertheless as Jens said the infinite-loop-allocation in the
> > ->make_request_fn path are deadlock prone at the moment, not because
> > they sleeps but because they need a reserved mempool to guarantee
> > operations can go ahead slowly without deadlocks even if dynamic
> > allocation fails, but this is not a very pratical problem, it's very
> > unlikely to deadlock there (it's not worse than the other infinite loop
> > in getblk() that affects not just loop).
> 
> Unlikely to deadlock for normal filesystems, but swap on encrypted loop is a
> different case.

Not really much different, it's no different than other paths like
getblk (when you swap on top of the fs) and brw_page (OTOH we have a
little reserved shared pool for the async bh needed by brw_page but it's not
math accurate first of all because it's shared for the other pagecache
I/O too), it just increases a little the mem pressure when there's
a transfer function involved and the translation cannot be done in
place, but I obviously agree that such loop deadlock needs fixing
reagardless if it's easy to reproduce it or not :). Infact I think I
mentioned such deadlock in the past too.

> Deadlock free operation is exactly why my prealloc loop patch is needed.
> Beyond initial preallocating that is done at losetup time, it does not
> allocate anything from kernel memory pools, but effectively recycles its
> private per loop device preallocated memory. Encrypted swap needs that, and
> normal device backed loop file systems are also happy with deadlock free and
> VM stress free operation.

Yes, thanks.

Andrea