On Thu, 09 Jan 2020 23:03:37 +0100, Alexander Bluhm wrote:
> That is why I have to keep the list alive while flushing it out.
> So I came to the TAILQ solution.
It seems like the best solution right now.
> > The alternative would be to add another loop around the list processing. I
> > think
On Thu, Jan 09, 2020 at 01:22:21PM -0500, Ted Unangst wrote:
> Martin Pieuchot wrote:
> > On 09/01/20(Thu) 10:46, Alexander Bluhm wrote:
> > > Without this diff my regress machines became so unstable, that they
> > > often do not finish the test run.
> > >
> > > With this diff, they run fine. No
Martin Pieuchot wrote:
> On 09/01/20(Thu) 10:46, Alexander Bluhm wrote:
> > Without this diff my regress machines became so unstable, that they
> > often do not finish the test run.
> >
> > With this diff, they run fine. No regressions.
>
> Sadly this is a workaround. What is the issue? We're
mount point?
> Any ok?
>
> bluhm
>
> On Sat, Jan 04, 2020 at 10:55:46PM +0100, Alexander Bluhm wrote:
> > On my amd64 test machine regress/sys/kern/mount run-regress-unmount-busy
> > triggers the dangling vnode panic regulary. Something has changed
> > in
ess-unmount-busy
> triggers the dangling vnode panic regulary. Something has changed
> in the previous months that makes it more likely.
>
> Problem is that while flushing the mnt_vnodelist list, the unmount
> process sleeps. Then active processes can write new dirty vnodes
> to th
Hi,
On my amd64 test machine regress/sys/kern/mount run-regress-unmount-busy
triggers the dangling vnode panic regulary. Something has changed
in the previous months that makes it more likely.
Problem is that while flushing the mnt_vnodelist list, the unmount
process sleeps. Then active
