lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sat, 2 Oct 2021 16:29:42 -0300
From:   Marcelo Schmitt <>
To:     Daniel Latypov <>
Subject: Re: [PATCH] kunit: mock: add support for function mocks with no

Removed Andy from the CC list as we're not talking about that bug anymore.

> > > We can work on something else besides mocking if it makes more sense to the
> > > project.
> >
> > Mocking doesn't feel like an area where we can expect to see progress right now.
> > In terms of other KUnit features we know would be useful now, I think
> > it's mostly just [1] and [2], which hopefully will land in 5.16.
> To be clear, if anyone thinks up a useful feature, that'd be great.
> I personally am just out of ideas at the moment, and I think so are
> Brendan and David.
> We'd want to prioritize features that can improve existing tests or
> unblock known new tests.
> Mocking in the alpha version of KUnit is a case where a feature
> sounded really good on paper and had a bunch of bells and whistles
> (e.g. strict/nice/naggy mocks support, etc.) but was perhaps
> overengineered and thus failed to find a home upstream.
> But I just thought of a few more things we could do in the script.
> I think we have more room for improvement there than in the in-kernel
> part of KUnit right now, but I assume it's the more boring part for
> most people.
> One thing I'd really like to see is getting code coverage to work in
> while using QEMU.
> We have a process for doing so under UML here:
> UML actually uses a different coverage implementation than normal, so
> there's a few things that would need to change.
> We can build and run against "normal" coverage kernels pretty easily:
> $ cat >qemu_coverage_kunitconfig <<EOF
> $ ./tools/testing/kunit/ run --arch=x86_64
> --kunitconfig=qemu_coverage_kunitconfig
> The problem is we'd need to copy the coverage data off the VM instead
> of just letting it shutdown when tests are done.
> If we had a userspace running, we'd basically do something like
> $ scp -r user@vm:/sys/kernel/debug/gcov .
> <some stuff to get these files in the right spot under .kunit/>
> <then we'd run lcov and genhtml, just like we do for UML>
> Normal KUnit tests definitely don't want to have to have the overhead
> of running a userspace, so the implementation might look like a
> "--qemu_coverage" flag, or maybe a set of generic flags that would
> give a user enough control over the VM to do this.
> Or maybe the right answer is to not involve at all.
> Not sure if that sounds interesting to you or anyone.

Sounds cool. We'll try to make it.


> >
> > I think right now we probably need more tests written to have a better
> > idea of what else we could/should do.
> > Partly because of that, David is trying to get the ball rolling on
> > testing ext4. We're also hopeful that it'll be easier to add tests if
> > adjacent code is already tested (sharing fakes, conventions, ability
> > to copy-paste, etc.).
> >
> > [1]
> > [2]
> >
> >

Powered by blists - more mailing lists