There are now 21 bugs open on bko, most of them crashes and some
undefined behavior. The nodes are now mostly running idle as no new
paths are discovered (after around one billion images tested in the
current run).

My thoughts are to wait until the current bugs have been fixed, then
restart the whole process from HEAD (together with the corpus of
~2.000 seed images discovered by now) and catch new bugs and aborts()
- we need to get rid of the reachable ones so code coverage can
improve. After those, I'll change the process to run btrfsck --repair,
which is slower but has a lot of yet uncovered code.

DigitalOcean has provided some funding for this undertaking so we are
good on CPU power. Kudos to them.

2016-09-13 22:28 GMT+02:00 Lukas Lueg [off-list ref]:

I've booted another instance with btrfs-progs checked out to 2b7c507
and collected some bugs which remained from the run before the current
one. The current run discovered what qgroups are just three days ago
and will spend some time on that. I've also added UBSAN- and
MSAN-logging to my setup and there were three bugs found so far (one
is already fixed). I will boot a third instance to run lowmem-mode
exclusively in the next few days.

There are 11 bugs open at the moment, all have a reproducing image
attached to them. The whole list is at

https://bugzilla.kernel.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=btrfs&email1=lukas.lueg%40gmail.com&emailreporter1=1&emailtype1=exact&list_id=858441&query_format=advanced


2016-09-09 16:00 GMT+02:00 David Sterba [off-list ref]:

quoted

On Tue, Sep 06, 2016 at 10:32:28PM +0200, Lukas Lueg wrote:

quoted

I'm currently fuzzing rev 2076992 and things start to slowly, slowly
quiet down. We will probably run out of steam at the end of the week
when a total of (roughly) half a billion BTRFS-images have passed by.
I will switch revisions to current HEAD and restart the whole process
then. A few things:

* There are a couple of crashes (mostly segfaults) I have not reported
yet. I'll report them if they show up again with the latest revision.

Ok.

quoted

* The coverage-analysis shows assertion failures which are currently
silenced. An assertion failure is technically a worse disaster
successfully prevented, it still constitutes unexpected/unusable
behaviour, though. Do you want assertions to be enabled and images
triggering those assertions reported? This is basically the same
conundrum as with BUG_ON and abort().

Yes please. I'd like to turn most bugons/assertions into a normal
failure report if it would make sense.

quoted

* A few endless loops entered into by btrfsck are currently
unmitigated (see bugs 155621, 155571, 155551 and 155151). It would be
nice if those had been taken care of by next week if possible.

Two of them are fixed, the other two need more work, updating all
callers of read_node_slot and the callchain. So you may still see that
kind of looping in more images. I don't have an ETA for the fix, I won't
be available during the next week.

At the moment, the initial sanity checks should catch most of the
corrupted values, so I'm expecting that you'll see different classes of
problems in the next rounds.

The testsuite now contains all images that you reported and we have a
fix in git. There are more utilities run on the images, there may be
more problems for us to fix.