Following up again.. It turns out the deadlocks I saw with this were down
to a problem with kernel_lock that has since been solved.
I made a couple more tweaks to it: up the max number of tracked holds to 8
because vmobjlock became a rwlock, and because aiodoned is gone now be more
selective
> This reminds me that we need to find a way to release upper layer
> vnodes when the lower layer is recyclable -- see the comment in
> layer_inactive. Otherwise files deleted under a null mount while open
> through the null mount may persist on disk indefinitely as long as the
> upper layer is
At Mon, 9 Mar 2020 17:36:24 +0100, Joerg Sonnenberger wrote:
Subject: Re: NULL pointer arithmetic issues
>
> I consider it as something even worse. Just like the case of passing
> NULL pointers to memcpy and friends with zero as size, this
> interpretation / restriction in the standard is
> Date: Mon, 9 Mar 2020 19:59:03 +
> From: Andrew Doran
>
> As far as I recall layer vnodes persist unless recycled like any other
> vnode, so there should be nothing special happening there around contention
> due to lifecycle. I think you could cache or transpose the cached names
> above,
Hi,
Thank you for your kind explanation! I understand the situation.
The current behavior is clean and safe, and we should not try to
``improve'' it easily.
For the case of NFS on m68k, we can rename ffs to __ffssi2 for
__KERNEL; we do not provide ffs(9) as a kernel routine.
Thanks,
rin
On
