linux/include/kunit/test-bug.h

97 lines
3.1 KiB

kunit: support failure from dynamic analysis tools Add a kunit_fail_current_test() function to fail the currently running test, if any, with an error message. This is largely intended for dynamic analysis tools like UBSAN and for fakes. E.g. say I had a fake ops struct for testing and I wanted my `free` function to complain if it was called with an invalid argument, or caught a double-free. Most return void and have no normal means of signalling failure (e.g. super_operations, iommu_ops, etc.). Key points: * Always update current->kunit_test so anyone can use it. * commit 83c4e7a0363b ("KUnit: KASAN Integration") only updated it for CONFIG_KASAN=y * Create a new header <kunit/test-bug.h> so non-test code doesn't have to include all of <kunit/test.h> (e.g. lib/ubsan.c) * Forward the file and line number to make it easier to track down failures * Declare the helper function for nice __printf() warnings about mismatched format strings even when KUnit is not enabled. Example output from kunit_fail_current_test("message"): [15:19:34] [FAILED] example_simple_test [15:19:34] # example_simple_test: initializing [15:19:34] # example_simple_test: lib/kunit/kunit-example-test.c:24: message [15:19:34] not ok 1 - example_simple_test Fixed minor check patch with checkpatch --fix option: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Uriel Guajardo <urielguajardo@google.com> Reviewed-by: Alan Maguire <alan.maguire@oracle.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-03-11 07:23:13 -08:00
kunit: support failure from dynamic analysis tools Add a kunit_fail_current_test() function to fail the currently running test, if any, with an error message. This is largely intended for dynamic analysis tools like UBSAN and for fakes. E.g. say I had a fake ops struct for testing and I wanted my `free` function to complain if it was called with an invalid argument, or caught a double-free. Most return void and have no normal means of signalling failure (e.g. super_operations, iommu_ops, etc.). Key points: * Always update current->kunit_test so anyone can use it. * commit 83c4e7a0363b ("KUnit: KASAN Integration") only updated it for CONFIG_KASAN=y * Create a new header <kunit/test-bug.h> so non-test code doesn't have to include all of <kunit/test.h> (e.g. lib/ubsan.c) * Forward the file and line number to make it easier to track down failures * Declare the helper function for nice __printf() warnings about mismatched format strings even when KUnit is not enabled. Example output from kunit_fail_current_test("message"): [15:19:34] [FAILED] example_simple_test [15:19:34] # example_simple_test: initializing [15:19:34] # example_simple_test: lib/kunit/kunit-example-test.c:24: message [15:19:34] not ok 1 - example_simple_test Fixed minor check patch with checkpatch --fix option: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Uriel Guajardo <urielguajardo@google.com> Reviewed-by: Alan Maguire <alan.maguire@oracle.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-03-11 07:23:13 -08:00
bug/kunit: Core support for suppressing warning backtraces Some unit tests intentionally trigger warning backtraces by passing bad parameters to kernel API functions. Such unit tests typically check the return value from such calls, not the existence of the warning backtrace. Such intentionally generated warning backtraces are neither desirable nor useful for a number of reasons: - They can result in overlooked real problems. - A warning that suddenly starts to show up in unit tests needs to be investigated and has to be marked to be ignored, for example by adjusting filter scripts. Such filters are ad hoc because there is no real standard format for warnings. On top of that, such filter scripts would require constant maintenance. Solve the problem by providing a means to suppress warning backtraces originating from the current kthread while executing test code. Since each KUnit test runs in its own kthread, this effectively scopes suppression to the test that enabled it. Limit changes to generic code to the absolute minimum. Implementation details: Suppression is integrated into the existing KUnit hooks infrastructure in test-bug.h, reusing the kunit_running static branch for zero overhead when no tests are running. Suppression is checked at three points in the warning path: - In warn_slowpath_fmt(), the check runs before any output, fully suppressing both message and backtrace. This covers architectures without __WARN_FLAGS. - In __warn_printk(), the check suppresses the warning message text. This covers architectures that define __WARN_FLAGS but not their own __WARN_printf (arm64, loongarch, parisc, powerpc, riscv, sh), where the message is printed before the trap enters __report_bug(). - In __report_bug(), the check runs before __warn() is called, suppressing the backtrace and stack dump. To avoid double-counting on architectures where both __warn_printk() and __report_bug() run for the same warning, kunit_is_suppressed_warning() takes a bool parameter: true to increment the suppression counter (used in warn_slowpath_fmt and __report_bug), false to check only (used in __warn_printk). The suppression state is dynamically allocated via kunit_kzalloc() and tied to the KUnit test lifecycle via kunit_add_action(), ensuring automatic cleanup at test exit. Writer-side access to the global suppression list is serialized with a spinlock; readers use RCU. Two API forms are provided: - kunit_warning_suppress(test) { ... }: scoped, uses __cleanup for automatic teardown on scope exit, kunit_add_action() as safety net for abnormal exits (e.g. kthread_exit from failed assertions). Suppression handle is only accessible inside the block. - kunit_start/end_suppress_warning(test): direct functions returning an explicit handle, for retaining the handle within the test, or for cross-function usage. Link: https://lore.kernel.org/r/20260514-kunit_add_support-v11-1-b36a530a6d8f@redhat.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Alessandro Carminati <acarmina@redhat.com> Reviewed-by: Kees Cook <kees@kernel.org> Reviewed-by: David Gow <david@davidgow.net> Signed-off-by: Albert Esteve <aesteve@redhat.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-14 13:06:37 +02:00
kunit: support failure from dynamic analysis tools Add a kunit_fail_current_test() function to fail the currently running test, if any, with an error message. This is largely intended for dynamic analysis tools like UBSAN and for fakes. E.g. say I had a fake ops struct for testing and I wanted my `free` function to complain if it was called with an invalid argument, or caught a double-free. Most return void and have no normal means of signalling failure (e.g. super_operations, iommu_ops, etc.). Key points: * Always update current->kunit_test so anyone can use it. * commit 83c4e7a0363b ("KUnit: KASAN Integration") only updated it for CONFIG_KASAN=y * Create a new header <kunit/test-bug.h> so non-test code doesn't have to include all of <kunit/test.h> (e.g. lib/ubsan.c) * Forward the file and line number to make it easier to track down failures * Declare the helper function for nice __printf() warnings about mismatched format strings even when KUnit is not enabled. Example output from kunit_fail_current_test("message"): [15:19:34] [FAILED] example_simple_test [15:19:34] # example_simple_test: initializing [15:19:34] # example_simple_test: lib/kunit/kunit-example-test.c:24: message [15:19:34] not ok 1 - example_simple_test Fixed minor check patch with checkpatch --fix option: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Uriel Guajardo <urielguajardo@google.com> Reviewed-by: Alan Maguire <alan.maguire@oracle.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-03-11 07:23:13 -08:00
kunit: Use the static key when retrieving the current test In order to detect if a KUnit test is running, and to access its context, the 'kunit_test' member of the current task_struct is used. Usually, this is accessed directly or via the kunit_fail_current_task() function. In order to speed up the case where no test is running, add a wrapper, kunit_get_current_test(), which uses the static key to fail early. Equally, Speed up kunit_fail_current_test() by using the static key. This should make it convenient for code to call this unconditionally in fakes or error paths, without worrying that this will slow the code down significantly. If CONFIG_KUNIT=n (or m), this compiles away to nothing. If CONFIG_KUNIT=y, it will compile down to a NOP (on most architectures) if no KUnit test is currently running. Note that kunit_get_current_test() does not work if KUnit is built as a module. This mirrors the existing restriction on kunit_fail_current_test(). Note that the definition of kunit_fail_current_test() still wraps an empty, inline function if KUnit is not built-in. This is to ensure that the printf format string __attribute__ will still work. Also update the documentation to suggest users use the new kunit_get_current_test() function, update the example, and to describe the behaviour when KUnit is disabled better. Cc: Jonathan Corbet <corbet@lwn.net> Cc: Sadiya Kazi <sadiyakazi@google.com> Signed-off-by: David Gow <davidgow@google.com> Reviewed-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-11-25 16:43:05 +08:00
bug/kunit: Core support for suppressing warning backtraces Some unit tests intentionally trigger warning backtraces by passing bad parameters to kernel API functions. Such unit tests typically check the return value from such calls, not the existence of the warning backtrace. Such intentionally generated warning backtraces are neither desirable nor useful for a number of reasons: - They can result in overlooked real problems. - A warning that suddenly starts to show up in unit tests needs to be investigated and has to be marked to be ignored, for example by adjusting filter scripts. Such filters are ad hoc because there is no real standard format for warnings. On top of that, such filter scripts would require constant maintenance. Solve the problem by providing a means to suppress warning backtraces originating from the current kthread while executing test code. Since each KUnit test runs in its own kthread, this effectively scopes suppression to the test that enabled it. Limit changes to generic code to the absolute minimum. Implementation details: Suppression is integrated into the existing KUnit hooks infrastructure in test-bug.h, reusing the kunit_running static branch for zero overhead when no tests are running. Suppression is checked at three points in the warning path: - In warn_slowpath_fmt(), the check runs before any output, fully suppressing both message and backtrace. This covers architectures without __WARN_FLAGS. - In __warn_printk(), the check suppresses the warning message text. This covers architectures that define __WARN_FLAGS but not their own __WARN_printf (arm64, loongarch, parisc, powerpc, riscv, sh), where the message is printed before the trap enters __report_bug(). - In __report_bug(), the check runs before __warn() is called, suppressing the backtrace and stack dump. To avoid double-counting on architectures where both __warn_printk() and __report_bug() run for the same warning, kunit_is_suppressed_warning() takes a bool parameter: true to increment the suppression counter (used in warn_slowpath_fmt and __report_bug), false to check only (used in __warn_printk). The suppression state is dynamically allocated via kunit_kzalloc() and tied to the KUnit test lifecycle via kunit_add_action(), ensuring automatic cleanup at test exit. Writer-side access to the global suppression list is serialized with a spinlock; readers use RCU. Two API forms are provided: - kunit_warning_suppress(test) { ... }: scoped, uses __cleanup for automatic teardown on scope exit, kunit_add_action() as safety net for abnormal exits (e.g. kthread_exit from failed assertions). Suppression handle is only accessible inside the block. - kunit_start/end_suppress_warning(test): direct functions returning an explicit handle, for retaining the handle within the test, or for cross-function usage. Link: https://lore.kernel.org/r/20260514-kunit_add_support-v11-1-b36a530a6d8f@redhat.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Alessandro Carminati <acarmina@redhat.com> Reviewed-by: Kees Cook <kees@kernel.org> Reviewed-by: David Gow <david@davidgow.net> Signed-off-by: Albert Esteve <aesteve@redhat.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-14 13:06:37 +02:00
kunit: Use the static key when retrieving the current test In order to detect if a KUnit test is running, and to access its context, the 'kunit_test' member of the current task_struct is used. Usually, this is accessed directly or via the kunit_fail_current_task() function. In order to speed up the case where no test is running, add a wrapper, kunit_get_current_test(), which uses the static key to fail early. Equally, Speed up kunit_fail_current_test() by using the static key. This should make it convenient for code to call this unconditionally in fakes or error paths, without worrying that this will slow the code down significantly. If CONFIG_KUNIT=n (or m), this compiles away to nothing. If CONFIG_KUNIT=y, it will compile down to a NOP (on most architectures) if no KUnit test is currently running. Note that kunit_get_current_test() does not work if KUnit is built as a module. This mirrors the existing restriction on kunit_fail_current_test(). Note that the definition of kunit_fail_current_test() still wraps an empty, inline function if KUnit is not built-in. This is to ensure that the printf format string __attribute__ will still work. Also update the documentation to suggest users use the new kunit_get_current_test() function, update the example, and to describe the behaviour when KUnit is disabled better. Cc: Jonathan Corbet <corbet@lwn.net> Cc: Sadiya Kazi <sadiyakazi@google.com> Signed-off-by: David Gow <davidgow@google.com> Reviewed-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-11-25 16:43:05 +08:00
kunit: Use the static key when retrieving the current test In order to detect if a KUnit test is running, and to access its context, the 'kunit_test' member of the current task_struct is used. Usually, this is accessed directly or via the kunit_fail_current_task() function. In order to speed up the case where no test is running, add a wrapper, kunit_get_current_test(), which uses the static key to fail early. Equally, Speed up kunit_fail_current_test() by using the static key. This should make it convenient for code to call this unconditionally in fakes or error paths, without worrying that this will slow the code down significantly. If CONFIG_KUNIT=n (or m), this compiles away to nothing. If CONFIG_KUNIT=y, it will compile down to a NOP (on most architectures) if no KUnit test is currently running. Note that kunit_get_current_test() does not work if KUnit is built as a module. This mirrors the existing restriction on kunit_fail_current_test(). Note that the definition of kunit_fail_current_test() still wraps an empty, inline function if KUnit is not built-in. This is to ensure that the printf format string __attribute__ will still work. Also update the documentation to suggest users use the new kunit_get_current_test() function, update the example, and to describe the behaviour when KUnit is disabled better. Cc: Jonathan Corbet <corbet@lwn.net> Cc: Sadiya Kazi <sadiyakazi@google.com> Signed-off-by: David Gow <davidgow@google.com> Reviewed-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-11-25 16:43:05 +08:00
bug/kunit: Core support for suppressing warning backtraces Some unit tests intentionally trigger warning backtraces by passing bad parameters to kernel API functions. Such unit tests typically check the return value from such calls, not the existence of the warning backtrace. Such intentionally generated warning backtraces are neither desirable nor useful for a number of reasons: - They can result in overlooked real problems. - A warning that suddenly starts to show up in unit tests needs to be investigated and has to be marked to be ignored, for example by adjusting filter scripts. Such filters are ad hoc because there is no real standard format for warnings. On top of that, such filter scripts would require constant maintenance. Solve the problem by providing a means to suppress warning backtraces originating from the current kthread while executing test code. Since each KUnit test runs in its own kthread, this effectively scopes suppression to the test that enabled it. Limit changes to generic code to the absolute minimum. Implementation details: Suppression is integrated into the existing KUnit hooks infrastructure in test-bug.h, reusing the kunit_running static branch for zero overhead when no tests are running. Suppression is checked at three points in the warning path: - In warn_slowpath_fmt(), the check runs before any output, fully suppressing both message and backtrace. This covers architectures without __WARN_FLAGS. - In __warn_printk(), the check suppresses the warning message text. This covers architectures that define __WARN_FLAGS but not their own __WARN_printf (arm64, loongarch, parisc, powerpc, riscv, sh), where the message is printed before the trap enters __report_bug(). - In __report_bug(), the check runs before __warn() is called, suppressing the backtrace and stack dump. To avoid double-counting on architectures where both __warn_printk() and __report_bug() run for the same warning, kunit_is_suppressed_warning() takes a bool parameter: true to increment the suppression counter (used in warn_slowpath_fmt and __report_bug), false to check only (used in __warn_printk). The suppression state is dynamically allocated via kunit_kzalloc() and tied to the KUnit test lifecycle via kunit_add_action(), ensuring automatic cleanup at test exit. Writer-side access to the global suppression list is serialized with a spinlock; readers use RCU. Two API forms are provided: - kunit_warning_suppress(test) { ... }: scoped, uses __cleanup for automatic teardown on scope exit, kunit_add_action() as safety net for abnormal exits (e.g. kthread_exit from failed assertions). Suppression handle is only accessible inside the block. - kunit_start/end_suppress_warning(test): direct functions returning an explicit handle, for retaining the handle within the test, or for cross-function usage. Link: https://lore.kernel.org/r/20260514-kunit_add_support-v11-1-b36a530a6d8f@redhat.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Alessandro Carminati <acarmina@redhat.com> Reviewed-by: Kees Cook <kees@kernel.org> Reviewed-by: David Gow <david@davidgow.net> Signed-off-by: Albert Esteve <aesteve@redhat.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-14 13:06:37 +02:00
kunit: support failure from dynamic analysis tools Add a kunit_fail_current_test() function to fail the currently running test, if any, with an error message. This is largely intended for dynamic analysis tools like UBSAN and for fakes. E.g. say I had a fake ops struct for testing and I wanted my `free` function to complain if it was called with an invalid argument, or caught a double-free. Most return void and have no normal means of signalling failure (e.g. super_operations, iommu_ops, etc.). Key points: * Always update current->kunit_test so anyone can use it. * commit 83c4e7a0363b ("KUnit: KASAN Integration") only updated it for CONFIG_KASAN=y * Create a new header <kunit/test-bug.h> so non-test code doesn't have to include all of <kunit/test.h> (e.g. lib/ubsan.c) * Forward the file and line number to make it easier to track down failures * Declare the helper function for nice __printf() warnings about mismatched format strings even when KUnit is not enabled. Example output from kunit_fail_current_test("message"): [15:19:34] [FAILED] example_simple_test [15:19:34] # example_simple_test: initializing [15:19:34] # example_simple_test: lib/kunit/kunit-example-test.c:24: message [15:19:34] not ok 1 - example_simple_test Fixed minor check patch with checkpatch --fix option: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Uriel Guajardo <urielguajardo@google.com> Reviewed-by: Alan Maguire <alan.maguire@oracle.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-03-11 07:23:13 -08:00
kunit: Use the static key when retrieving the current test In order to detect if a KUnit test is running, and to access its context, the 'kunit_test' member of the current task_struct is used. Usually, this is accessed directly or via the kunit_fail_current_task() function. In order to speed up the case where no test is running, add a wrapper, kunit_get_current_test(), which uses the static key to fail early. Equally, Speed up kunit_fail_current_test() by using the static key. This should make it convenient for code to call this unconditionally in fakes or error paths, without worrying that this will slow the code down significantly. If CONFIG_KUNIT=n (or m), this compiles away to nothing. If CONFIG_KUNIT=y, it will compile down to a NOP (on most architectures) if no KUnit test is currently running. Note that kunit_get_current_test() does not work if KUnit is built as a module. This mirrors the existing restriction on kunit_fail_current_test(). Note that the definition of kunit_fail_current_test() still wraps an empty, inline function if KUnit is not built-in. This is to ensure that the printf format string __attribute__ will still work. Also update the documentation to suggest users use the new kunit_get_current_test() function, update the example, and to describe the behaviour when KUnit is disabled better. Cc: Jonathan Corbet <corbet@lwn.net> Cc: Sadiya Kazi <sadiyakazi@google.com> Signed-off-by: David Gow <davidgow@google.com> Reviewed-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-11-25 16:43:05 +08:00
bug/kunit: Core support for suppressing warning backtraces Some unit tests intentionally trigger warning backtraces by passing bad parameters to kernel API functions. Such unit tests typically check the return value from such calls, not the existence of the warning backtrace. Such intentionally generated warning backtraces are neither desirable nor useful for a number of reasons: - They can result in overlooked real problems. - A warning that suddenly starts to show up in unit tests needs to be investigated and has to be marked to be ignored, for example by adjusting filter scripts. Such filters are ad hoc because there is no real standard format for warnings. On top of that, such filter scripts would require constant maintenance. Solve the problem by providing a means to suppress warning backtraces originating from the current kthread while executing test code. Since each KUnit test runs in its own kthread, this effectively scopes suppression to the test that enabled it. Limit changes to generic code to the absolute minimum. Implementation details: Suppression is integrated into the existing KUnit hooks infrastructure in test-bug.h, reusing the kunit_running static branch for zero overhead when no tests are running. Suppression is checked at three points in the warning path: - In warn_slowpath_fmt(), the check runs before any output, fully suppressing both message and backtrace. This covers architectures without __WARN_FLAGS. - In __warn_printk(), the check suppresses the warning message text. This covers architectures that define __WARN_FLAGS but not their own __WARN_printf (arm64, loongarch, parisc, powerpc, riscv, sh), where the message is printed before the trap enters __report_bug(). - In __report_bug(), the check runs before __warn() is called, suppressing the backtrace and stack dump. To avoid double-counting on architectures where both __warn_printk() and __report_bug() run for the same warning, kunit_is_suppressed_warning() takes a bool parameter: true to increment the suppression counter (used in warn_slowpath_fmt and __report_bug), false to check only (used in __warn_printk). The suppression state is dynamically allocated via kunit_kzalloc() and tied to the KUnit test lifecycle via kunit_add_action(), ensuring automatic cleanup at test exit. Writer-side access to the global suppression list is serialized with a spinlock; readers use RCU. Two API forms are provided: - kunit_warning_suppress(test) { ... }: scoped, uses __cleanup for automatic teardown on scope exit, kunit_add_action() as safety net for abnormal exits (e.g. kthread_exit from failed assertions). Suppression handle is only accessible inside the block. - kunit_start/end_suppress_warning(test): direct functions returning an explicit handle, for retaining the handle within the test, or for cross-function usage. Link: https://lore.kernel.org/r/20260514-kunit_add_support-v11-1-b36a530a6d8f@redhat.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Alessandro Carminati <acarmina@redhat.com> Reviewed-by: Kees Cook <kees@kernel.org> Reviewed-by: David Gow <david@davidgow.net> Signed-off-by: Albert Esteve <aesteve@redhat.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-14 13:06:37 +02:00
kunit: Use the static key when retrieving the current test In order to detect if a KUnit test is running, and to access its context, the 'kunit_test' member of the current task_struct is used. Usually, this is accessed directly or via the kunit_fail_current_task() function. In order to speed up the case where no test is running, add a wrapper, kunit_get_current_test(), which uses the static key to fail early. Equally, Speed up kunit_fail_current_test() by using the static key. This should make it convenient for code to call this unconditionally in fakes or error paths, without worrying that this will slow the code down significantly. If CONFIG_KUNIT=n (or m), this compiles away to nothing. If CONFIG_KUNIT=y, it will compile down to a NOP (on most architectures) if no KUnit test is currently running. Note that kunit_get_current_test() does not work if KUnit is built as a module. This mirrors the existing restriction on kunit_fail_current_test(). Note that the definition of kunit_fail_current_test() still wraps an empty, inline function if KUnit is not built-in. This is to ensure that the printf format string __attribute__ will still work. Also update the documentation to suggest users use the new kunit_get_current_test() function, update the example, and to describe the behaviour when KUnit is disabled better. Cc: Jonathan Corbet <corbet@lwn.net> Cc: Sadiya Kazi <sadiyakazi@google.com> Signed-off-by: David Gow <davidgow@google.com> Reviewed-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-11-25 16:43:05 +08:00
kunit: support failure from dynamic analysis tools Add a kunit_fail_current_test() function to fail the currently running test, if any, with an error message. This is largely intended for dynamic analysis tools like UBSAN and for fakes. E.g. say I had a fake ops struct for testing and I wanted my `free` function to complain if it was called with an invalid argument, or caught a double-free. Most return void and have no normal means of signalling failure (e.g. super_operations, iommu_ops, etc.). Key points: * Always update current->kunit_test so anyone can use it. * commit 83c4e7a0363b ("KUnit: KASAN Integration") only updated it for CONFIG_KASAN=y * Create a new header <kunit/test-bug.h> so non-test code doesn't have to include all of <kunit/test.h> (e.g. lib/ubsan.c) * Forward the file and line number to make it easier to track down failures * Declare the helper function for nice __printf() warnings about mismatched format strings even when KUnit is not enabled. Example output from kunit_fail_current_test("message"): [15:19:34] [FAILED] example_simple_test [15:19:34] # example_simple_test: initializing [15:19:34] # example_simple_test: lib/kunit/kunit-example-test.c:24: message [15:19:34] not ok 1 - example_simple_test Fixed minor check patch with checkpatch --fix option: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Uriel Guajardo <urielguajardo@google.com> Reviewed-by: Alan Maguire <alan.maguire@oracle.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-03-11 07:23:13 -08:00