> On 11 Dec 2016, at 21:01, David Holland <dholland-t...@netbsd.org> wrote:
>
> On a low-memory machine Nick ran into the following deadlock:
>
> (a) rename -> vrele on child -> inactive -> truncate -> getblk ->
> no memory in buffer pool -> wait for syncer
This prediction seems wrong. It is not the syncers job to free
memory to buffer pool - it will just update and write buffers
ending up on one of the buffer queues.
To release memory to the buffer pool the pagedaemon calls buf_drain()
when it detects a low memory condition. Looks like this check from
uvm_pageout() fails:
bufcnt = uvmexp.freetarg - uvmexp.free;
if (bufcnt < 0)
bufcnt = 0;
> (b) syncer waiting for locked parent vnode from the rename
>
> This makes it in general unsafe to vrele while holding a vnode lock.
>
> In theory we could arrange this, but it's not desirable: the tidy
> locking model for directory operations is: lock parent, call into fs,
> fs handles child, unlock parent on return, so needing to unlock the
> parent before releasing the child would bust up the abstraction
> layer. (Not that we currently have this, but we're ostensibly working
> towards it.)
>
> Does anyone have any suggestions for a patch to address this problem
> without first rewriting the syncer? While the latter is probably a
> good idea, it's not entirely trivial to do and get right, making it
> e.g. a poor pullup candidate...
>
> --
> David A. Holland
> dholl...@netbsd.org
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
