diff options
author | Daniel Latypov <dlatypov@google.com> | 2021-09-14 14:03:47 -0700 |
---|---|---|
committer | Shuah Khan <skhan@linuxfoundation.org> | 2021-10-19 14:18:49 -0600 |
commit | b7cbaef303c7b9f26c647bcba72da04dd35396c4 (patch) | |
tree | 662c379770f8adcc664a639dc32787b655c69712 /Documentation | |
parent | 519d81956ee277b4419c723adfb154603c2565ba (diff) | |
download | linux-b7cbaef303c7b9f26c647bcba72da04dd35396c4.tar.bz2 |
kunit: drop assumption in kunit-log-test about current suite
This test assumes that the declared kunit_suite object is the exact one
which is being executed, which KUnit will not guarantee [1].
Specifically, `suite->log` is not initialized until a suite object is
executed. So if KUnit makes a copy of the suite and runs that instead,
this test dereferences an invalid pointer and (hopefully) segfaults.
N.B. since we no longer assume this, we can no longer verify that
`suite->log` is *not* allocated during normal execution.
An alternative to this patch that would allow us to test that would
require exposing an API for the current test to get its current suite.
Exposing that for one internal kunit test seems like overkill, and
grants users more footguns (e.g. reusing a test case in multiple suites
and changing behavior based on the suite name, dynamically modifying the
setup/cleanup funcs, storing/reading stuff out of the suite->log, etc.).
[1] In a subsequent patch, KUnit will allow running subsets of test
cases within a suite by making a copy of the suite w/ the filtered test
list. But there are other reasons KUnit might execute a copy, e.g. if it
ever wants to support parallel execution of different suites, recovering
from errors and restarting suites
Signed-off-by: Daniel Latypov <dlatypov@google.com>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions