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 <lukas.l...@gmail.com>: > 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 <dste...@suse.cz>: >> On Tue, Sep 06, 2016 at 10:32:28PM +0200, Lukas Lueg wrote: >>> 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. >> >>> * 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. >> >>> * 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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
