On Wed, Mar 25, 2020 at 5:42 AM Alan Maguire alan.maguire@oracle.com wrote:
On Tue, 24 Mar 2020, Patricia Alfonso wrote:
On Tue, Mar 24, 2020 at 9:40 AM Alan Maguire alan.maguire@oracle.com wrote:
On Thu, 19 Mar 2020, Patricia Alfonso wrote:
In order to integrate debugging tools like KASAN into the KUnit framework, add KUnit struct to the current task to keep track of the current KUnit test.
Signed-off-by: Patricia Alfonso trishalfonso@google.com
include/linux/sched.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/include/linux/sched.h b/include/linux/sched.h index 04278493bf15..1fbfa0634776 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1180,6 +1180,10 @@ struct task_struct { unsigned int kasan_depth; #endif
+#if IS_BUILTIN(CONFIG_KUNIT)
This patch set looks great! You might have noticed I refreshed the kunit resources stuff to incorporate feedback from Brendan, but I don't think any API changes were made that should have consequences for your code (I'm building with your patches on top to make sure). I'd suggest promoting from RFC to v3 on the next round unless anyone objects.
As Dmitry suggested, the above could likely be changed to be "#ifdef CONFIG_KUNIT" as kunit can be built as a module also. More on this in patch 2..
I suppose this could be changed so that this can be used in possible future scenarios, but for now, since built-in things can't rely on modules, the KASAN integration relies on KUnit being built-in.
I think we can get around that. I've tried tweaking the resources patchset such that the functions you need in KASAN (which is builtin) are declared as "static inline" in include/kunit/test.h; doing this allows us to build kunit and test_kasan as a module while supporting the builtin functionality required to retrieve and use kunit resources within KASAN itself.
Okay, great!
The impact of this amounts to a few functions, but it would require a rebase of your changes. I'll send out a v3 of the resources patches shortly; I just want to do some additional testing on them. I can also send you the modified versions of your patches that I used to test with.
That sounds good.
With these changes I can run the tests on baremetal x86_64 by modprobe'ing test_kasan. However I see a few failures:
[ 87.577012] # kasan_memchr: EXPECTATION FAILED at lib/test_kasan.c:509 Expected kasan_data->report_expected == kasan_data->report_found, but kasan_data->report_expected == 1 kasan_data->report_found == 0 [ 87.577104] not ok 30 - kasan_memchr [ 87.603823] # kasan_memcmp: EXPECTATION FAILED at lib/test_kasan.c:523 Expected kasan_data->report_expected == kasan_data->report_found, but kasan_data->report_expected == 1 kasan_data->report_found == 0 [ 87.603929] not ok 31 - kasan_memcmp [ 87.630644] # kasan_strings: EXPECTATION FAILED at lib/test_kasan.c:544 Expected kasan_data->report_expected == kasan_data->report_found, but kasan_data->report_expected == 1 kasan_data->report_found == 0 [ 87.630910] # kasan_strings: EXPECTATION FAILED at lib/test_kasan.c:546 Expected kasan_data->report_expected == kasan_data->report_found, but kasan_data->report_expected == 1 kasan_data->report_found == 0 [ 87.654037] # kasan_strings: EXPECTATION FAILED at lib/test_kasan.c:548 Expected kasan_data->report_expected == kasan_data->report_found, but kasan_data->report_expected == 1 kasan_data->report_found == 0 [ 87.677179] # kasan_strings: EXPECTATION FAILED at lib/test_kasan.c:550 Expected kasan_data->report_expected == kasan_data->report_found, but kasan_data->report_expected == 1 kasan_data->report_found == 0 [ 87.700242] # kasan_strings: EXPECTATION FAILED at lib/test_kasan.c:552 Expected kasan_data->report_expected == kasan_data->report_found, but kasan_data->report_expected == 1 kasan_data->report_found == 0 [ 87.723336] # kasan_strings: EXPECTATION FAILED at lib/test_kasan.c:554 Expected kasan_data->report_expected == kasan_data->report_found, but kasan_data->report_expected == 1 kasan_data->report_found == 0 [ 87.746304] not ok 32 - kasan_strings
The above three tests consistently fail while everything else passes, and happen irrespective of whether kunit is built as a module or built-in. Let me know if you need any more info to debug (I built the kernel with CONFIG_SLUB=y if that matters).
Unfortunately, I have not been able to replicate this issue and I don't have a clue why these specific tests would fail with a different configuration. I've tried running these tests on UML with KUnit built-in with SLUB=y and SLAB=y, and I've done the same in x86_64. Let me know if there's anything else that could help me debug this myself.
Thanks!
Alan
struct kunit *kunit_test;+#endif /* IS_BUILTIN(CONFIG_KUNIT) */
#ifdef CONFIG_FUNCTION_GRAPH_TRACER /* Index of current stored address in ret_stack: */ int curr_ret_stack; -- 2.25.1.696.g5e7596f4ac-goog
-- Best, Patricia
-- Best, Patricia