Re: netbsd-5 deadlocks when memory is low

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> If the above is correct, then we have this situation:  [...]

> If I am correct, then a possible fix could be to have one ioflush
> thread per filesystem.  This woule ensure that a user filesystem
> awaiting memory would not prevent ioflush work on local filesystem.

That won't fix it; it'll just make it less likely to deadlock.  If
there is nothing to flush _except_ to the user filesystem that wants
memory, the system is still wedged.

As a scenario less likely to occur, but more likely to deadlock if it
does occur, consider a system configured with swap to a file that's on
a userland filesystem, and then let all other swap (if any) fill up.

I'm not sure this is truly fixable.  Userland processes can demand
arbitrarily large amounts of resources before they're willing to
proceed with filesystem requests from the kernel.  (For that matter, if
the various criteria allow potentially malicious users to mount such
filesystems, the userland process could just flat-out *ignore* the
kernel's requests when it feels like it; if it wedges the whole system
when it does that, this strikes me as a potential..issue.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B