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

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

On May 6, 2013, at 12:34 PM, Antti Kantee <pooka%netbsd.org@localhost> wrote:

> 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.

Looks like RUMP has become much more aggressive regarding scheduling
and block i/o. The buffer in question is DONE and BUSY which means it
is about to be brelse'd.  The assertion was wrong -- should be fixed
with ffs_snapshot.c rev 1.122.

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