Re: 2.4.19pre3aa2

[Jari Ruusu]

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.

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.

Regards,
Jari Ruusu <[e-mail]>