Hi, I've now shut down all fuzzer nodes since they only cost money and there is no progress on most of the aforementioned bugs.
Best regards Lukas ---------- Forwarded message ---------- From: Lukas Lueg <lukas.l...@gmail.com> Date: 2016-09-26 11:39 GMT+02:00 Subject: Re: State of the fuzzer To: linux-btrfs@vger.kernel.org Hi David, do we have any chance of engagement on those 23 bugs which came out of the last fuzzing round? The nodes have been basically idle for a week, spewing duplicates and variants of what's already known... Best regards Lukas 2016-09-20 13:33 GMT+02:00 Lukas Lueg <lukas.l...@gmail.com>: > 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
