Re: vrele vs. syncer deadlock

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

> On 11 Dec 2016, at 21:01, David Holland <dholland-tech%netbsd.org@localhost> 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
> dholland%netbsd.org@localhost

--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)