On Tue, 30 May 2023, Kent Overstreet wrote:
> On Tue, May 30, 2023 at 05:00:39PM -0400, Mikulas Patocka wrote:
> > I'd like to know how do you want to do coverage analysis? By instrumenting
> > each branch and creating a test case that tests that the branch goes both
> > ways?
>
> Documentation/dev-tools/gcov.rst. The compiler instruments each branch
> and then the results are available in debugfs, then the lcov tool
> produces annotated source code as html output.
>
> > I know that people who write spacecraft-grade software do such tests, but
> > I can't quite imagine how would that work in a filesystem.
> >
> > "grep -w if fs/bcachefs/*.[ch] | wc -l" shows that there are 5828
> > conditions. That's one condition for every 15.5 lines.
>
> Most of which are covered by existing tests - but by running the
> existing tests with code coverage analylis we can see which branches the
> tests aren't hitting, and then we add fault injection points for those.
>
> With fault injection we can improve test coverage a lot without needing
> to write any new tests (or simple ones, for e.g. init/mount errors)
I compiled the kernel with gcov, I ran "xfstests-dev" on bcachefs and gcov
shows that there is 56% coverage on "fs/bcachefs/*.o".
So, we have 2564 "if" branches (of total 5828) that were not tested. What
are you going to do about them? Will you create a filesystem image for
each branch that triggers it? Or, will you add 2564 fault-injection points
to the source code?
It seems like extreme amount of work.
Mikulas
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
