Re: Yet another test regression: fs/ffs/t_snapshot_log/snapshotstress

[Antti Kantee <pooka%NetBSD.org@localhost>]

On 02.05.2013 18:13, J. Hannken-Illjes wrote:
> On May 1, 2013, at 3:08 PM, Andreas Gustafsson <gson%gson.org@localhost> wrote:
>
> > The "snapshotstress" test case of the fs/ffs/t_snapshot_log program has
> > recently started failing with "signal 6 (core dumped)".  The first
> > recorded failure with those particular symptoms in the babylon5 i386
> > tests was with source date 2013.04.29.14.54.03:
> >
> >   
> > http://releng.netbsd.org/b5reports/i386/commits-2013.04.html#2013.04.29.14.54.03
> >
> > It also failed in the previous test run (2013.04.29.14.42.11), but so
> > did with 644 other tests, so it's hard to say if that's relevant or
> > not.

The change that causes KASSERT(BC_BUSY) to fire is most likely the one 
which made the rump kernel block driver do asynchronous I/O, where it 
always previously was synchronous inside the rump kernel (the async part 
was completely hidden in the hypervisor -- it used mmap/msync).

Juergen, since your knowledge of vfs is more current than mine, could 
you have a quick look through the panicking code path with the 
above-mentioned sync->async change in mind and see if I've missed an 
obvious wait somewhere.