[PATCH v3 0/2] filter_seccomp: new bpf generation strategy

[Dmitry V. Levin]

On Mon, Nov 04, 2019 at 12:36:07PM +0100, Paul Chaignon wrote:
> On Sun, Nov 03, 2019 at 07:01:24PM +0300, Dmitry V. Levin wrote:
> > On Thu, Oct 31, 2019 at 08:55:12PM +0100, Paul Chaignon wrote:
[...]
> > We still can do better with test coverage of these new features, though.
> 
> Any specific cases you'd like us to test?
> 
> The third test case in tests/filter_seccomp.in should already be
> triggering the use of the new binary match strategy.  (Not that I think
> it's enough.)

From the test coverage I can see that bpf code is generated both for
linear and binary match strategies, and at least one of these strategies
generates bpf code that passes tests.  As far as I can tell, there is no
way to see whether the bpf code generated e.g. by the new binary match
strategy is actually tested.

> Some of the corner cases are also a bit hard to test (e.g., jump offset
> overflow and oversized filter) because I currently am unable to come up
> with a trace set that triggers them.

Could you prove they cannot be triggered? ;)

> I had a look at the Codecov reporting, but it looks kinda weird:
> exec_or_die() is supposedly never executed, as if Codecov is only tracing
> the tracer process...?

This looks rather like a bug in gcov used in the travis build (maybe
the gcc version is too old) because in local coverage tests I see that
exec_or_die is covered.

When gcc --coverage (or analogue) is used, it wraps all forks and execs
in a special way, see
https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/libgcov-interface.c


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20191104/f8522957/attachment.bin>