[PATCH] selftests/harness: Fix TEST_F()'s vfork handling

Mickaël Salaün mic at digikod.net
Wed Mar 6 07:32:13 UTC 2024


On Wed, Mar 06, 2024 at 08:25:45AM +0100, Mickaël Salaün wrote:
> On Tue, Mar 05, 2024 at 12:25:54PM -0800, Jakub Kicinski wrote:
> > On Tue,  5 Mar 2024 21:10:29 +0100 Mickaël Salaün wrote:
> > > Always run fixture setup in the grandchild process, and by default also
> > > run the teardown in the same process.  However, this change makes it
> > > possible to run the teardown in a parent process when
> > > _metadata->teardown_parent is set to true (e.g. in fixture setup).
> > > 
> > > Fix TEST_SIGNAL() by forwarding grandchild's signal to its parent.  Fix
> > > seccomp tests by running the test setup in the parent of the test
> > > thread, as expected by the related test code.  Fix Landlock tests by
> > > waiting for the grandchild before processing _metadata.
> > > 
> > > Use of exit(3) in tests should be OK because the environment in which
> > > the vfork(2) call happen is already dedicated to the running test (with
> > > flushed stdio, setpgrp() call), see __run_test() and the call to fork(2)
> > > just before running the setup/test/teardown.  Even if the test
> > > configures its own exit handlers, they will not be run by the parent
> > > because it never calls exit(3), and the test function either ends with a
> > > call to _exit(2) or a signal.
> > > 
> > > Cc: David S. Miller <davem at davemloft.net>
> > > Cc: Günther Noack <gnoack at google.com>
> > > Cc: Jakub Kicinski <kuba at kernel.org>
> > > Cc: Kees Cook <keescook at chromium.org>
> > > Cc: Mark Brown <broonie at kernel.org>
> > > Cc: Shuah Khan <shuah at kernel.org>
> > > Cc: Will Drewry <wad at chromium.org>
> > > Fixes: 0710a1a73fb4 ("selftests/harness: Merge TEST_F_FORK() into TEST_F()")
> > > Link: https://lore.kernel.org/r/20240305201029.1331333-1-mic@digikod.net
> 
> Signed-off-by: Mickaël Salaün <mic at digikod.net>

Reported-by: Mark Brown <broonie at kernel.org>

> 
> > 
> > Your S-o-b is missing. Should be enough if you responded with it.
> > 
> > Code LGTM, thanks!
> > 



More information about the Linux-security-module-archive mailing list