Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run.
Due to KUnit tests not being intended to run on production systems, and
potentially causing problems (or security issues like leaking kernel
addresses), the kernel's state should not be considered safe for
production use after KUnit tests are run.
This both marks KUnit modules as test modules using MODULE_INFO() and
manually taints the kernel when tests are run (which catches builtin
tests).
Acked-by: Luis Chamberlain <[email protected]>
Tested-by: Daniel Latypov <[email protected]>
Reviewed-by: Brendan Higgins <[email protected]>
Signed-off-by: David Gow <[email protected]>
---
No changes since v5:
https://lore.kernel.org/linux-kselftest/[email protected]/
No changes since v4:
https://lore.kernel.org/linux-kselftest/[email protected]/
Changes since v3:
https://lore.kernel.org/lkml/[email protected]/
- Use MODULE_INFO() for KUnit modules.
- This is technically redundant, as the KUnit executor will taint the
kernel when _any_ KUnit tests are run, but may be useful if some
other tool will parse the 'test' property.
- Add {Acked,Tested,Reviewed}-by tags.
---
include/kunit/test.h | 3 ++-
lib/kunit/test.c | 4 ++++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/kunit/test.h b/include/kunit/test.h
index 8ffcd7de9607..ccae848720dc 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -277,7 +277,8 @@ static inline int kunit_run_all_tests(void)
{ \
return __kunit_test_suites_exit(__suites); \
} \
- module_exit(kunit_test_suites_exit)
+ module_exit(kunit_test_suites_exit) \
+ MODULE_INFO(test, "Y");
#else
#define kunit_test_suites_for_module(__suites)
#endif /* MODULE */
diff --git a/lib/kunit/test.c b/lib/kunit/test.c
index a5053a07409f..8b11552dc215 100644
--- a/lib/kunit/test.c
+++ b/lib/kunit/test.c
@@ -11,6 +11,7 @@
#include <kunit/test-bug.h>
#include <linux/kernel.h>
#include <linux/moduleparam.h>
+#include <linux/panic.h>
#include <linux/sched/debug.h>
#include <linux/sched.h>
@@ -501,6 +502,9 @@ int kunit_run_tests(struct kunit_suite *suite)
struct kunit_result_stats suite_stats = { 0 };
struct kunit_result_stats total_stats = { 0 };
+ /* Taint the kernel so we know we've run tests. */
+ add_taint(TAINT_TEST, LOCKDEP_STILL_OK);
+
if (suite->suite_init) {
suite->suite_init_err = suite->suite_init(suite);
if (suite->suite_init_err) {
--
2.37.0.rc0.161.g10f37bed90-goog
On 7/7/22 10:48 PM, David Gow wrote:
> Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run.
> Due to KUnit tests not being intended to run on production systems, and
> potentially causing problems (or security issues like leaking kernel
> addresses), the kernel's state should not be considered safe for
> production use after KUnit tests are run.
>
> This both marks KUnit modules as test modules using MODULE_INFO() and
> manually taints the kernel when tests are run (which catches builtin
> tests).
>
> Acked-by: Luis Chamberlain <[email protected]>
> Tested-by: Daniel Latypov <[email protected]>
> Reviewed-by: Brendan Higgins <[email protected]>
> Signed-off-by: David Gow <[email protected]>
> ---
>
> No changes since v5:
> https://lore.kernel.org/linux-kselftest/[email protected]/
>
> No changes since v4:
> https://lore.kernel.org/linux-kselftest/[email protected]/
>
David, Brendan, Andrew,
Just confirming the status of these patches. I applied v4 1/3 and v4 3/4
to linux-kselftest kunit for 5.20-rc1.
I am seeing v5 and v6 now. Andrew applied v5 looks like. Would you like
me to drop the two I applied? Do we have to refresh with v6?
thanks,
-- Shuah
On Fri, Jul 8, 2022 at 1:22 PM Shuah Khan <[email protected]> wrote:
>
> On 7/7/22 10:48 PM, David Gow wrote:
> > Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run.
> > Due to KUnit tests not being intended to run on production systems, and
> > potentially causing problems (or security issues like leaking kernel
> > addresses), the kernel's state should not be considered safe for
> > production use after KUnit tests are run.
> >
> > This both marks KUnit modules as test modules using MODULE_INFO() and
> > manually taints the kernel when tests are run (which catches builtin
> > tests).
> >
> > Acked-by: Luis Chamberlain <[email protected]>
> > Tested-by: Daniel Latypov <[email protected]>
> > Reviewed-by: Brendan Higgins <[email protected]>
> > Signed-off-by: David Gow <[email protected]>
> > ---
> >
> > No changes since v5:
> > https://lore.kernel.org/linux-kselftest/[email protected]/
> >
> > No changes since v4:
> > https://lore.kernel.org/linux-kselftest/[email protected]/
> >
>
> David, Brendan, Andrew,
>
> Just confirming the status of these patches. I applied v4 1/3 and v4 3/4
> to linux-kselftest kunit for 5.20-rc1.
> I am seeing v5 and v6 now. Andrew applied v5 looks like. Would you like
> me to drop the two I applied? Do we have to refresh with v6?
Just noting here that there'll be a merge conflict between this patch
(3/4) and some other patches lined up to go through the kunit tree:
https://patchwork.kernel.org/project/linux-kselftest/patch/[email protected]/
Not sure how we want to handle that.
Daniel
On 7/8/22 3:22 PM, Shuah Khan wrote:
> On 7/8/22 3:00 PM, Daniel Latypov wrote:
>> On Fri, Jul 8, 2022 at 1:22 PM Shuah Khan <[email protected]> wrote:
>>>
>>> On 7/7/22 10:48 PM, David Gow wrote:
>>>> Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run.
>>>> Due to KUnit tests not being intended to run on production systems, and
>>>> potentially causing problems (or security issues like leaking kernel
>>>> addresses), the kernel's state should not be considered safe for
>>>> production use after KUnit tests are run.
>>>>
>>>> This both marks KUnit modules as test modules using MODULE_INFO() and
>>>> manually taints the kernel when tests are run (which catches builtin
>>>> tests).
>>>>
>>>> Acked-by: Luis Chamberlain <[email protected]>
>>>> Tested-by: Daniel Latypov <[email protected]>
>>>> Reviewed-by: Brendan Higgins <[email protected]>
>>>> Signed-off-by: David Gow <[email protected]>
>>>> ---
>>>>
>>>> No changes since v5:
>>>> https://lore.kernel.org/linux-kselftest/[email protected]/
>>>>
>>>> No changes since v4:
>>>> https://lore.kernel.org/linux-kselftest/[email protected]/
>>>>
>>>
>>> David, Brendan, Andrew,
>>>
>>> Just confirming the status of these patches. I applied v4 1/3 and v4 3/4
>>> to linux-kselftest kunit for 5.20-rc1.
>>> I am seeing v5 and v6 now. Andrew applied v5 looks like. Would you like
>>> me to drop the two I applied? Do we have to refresh with v6?
>>
>> Just noting here that there'll be a merge conflict between this patch
>> (3/4) and some other patches lined up to go through the kunit tree:
>> https://patchwork.kernel.org/project/linux-kselftest/patch/[email protected]/
>>
>> Not sure how we want to handle that.
>>
>
> I can go drop the two patches and have Andrew carry the series through
> mm tree.
>
Sorry spoke too soon. Yes there are others that might have conflicts as
Daniel pointed out:
https://patchwork.kernel.org/project/linux-kselftest/patch/[email protected]/
thanks,
-- Shuah
On 7/8/22 3:00 PM, Daniel Latypov wrote:
> On Fri, Jul 8, 2022 at 1:22 PM Shuah Khan <[email protected]> wrote:
>>
>> On 7/7/22 10:48 PM, David Gow wrote:
>>> Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run.
>>> Due to KUnit tests not being intended to run on production systems, and
>>> potentially causing problems (or security issues like leaking kernel
>>> addresses), the kernel's state should not be considered safe for
>>> production use after KUnit tests are run.
>>>
>>> This both marks KUnit modules as test modules using MODULE_INFO() and
>>> manually taints the kernel when tests are run (which catches builtin
>>> tests).
>>>
>>> Acked-by: Luis Chamberlain <[email protected]>
>>> Tested-by: Daniel Latypov <[email protected]>
>>> Reviewed-by: Brendan Higgins <[email protected]>
>>> Signed-off-by: David Gow <[email protected]>
>>> ---
>>>
>>> No changes since v5:
>>> https://lore.kernel.org/linux-kselftest/[email protected]/
>>>
>>> No changes since v4:
>>> https://lore.kernel.org/linux-kselftest/[email protected]/
>>>
>>
>> David, Brendan, Andrew,
>>
>> Just confirming the status of these patches. I applied v4 1/3 and v4 3/4
>> to linux-kselftest kunit for 5.20-rc1.
>> I am seeing v5 and v6 now. Andrew applied v5 looks like. Would you like
>> me to drop the two I applied? Do we have to refresh with v6?
>
> Just noting here that there'll be a merge conflict between this patch
> (3/4) and some other patches lined up to go through the kunit tree:
> https://patchwork.kernel.org/project/linux-kselftest/patch/[email protected]/
>
> Not sure how we want to handle that.
>
I can go drop the two patches and have Andrew carry the series through
mm tree.
thanks,
-- Shuah
On Sat, Jul 9, 2022 at 5:24 AM Shuah Khan <[email protected]> wrote:
>
> On 7/8/22 3:22 PM, Shuah Khan wrote:
> > On 7/8/22 3:00 PM, Daniel Latypov wrote:
> >> On Fri, Jul 8, 2022 at 1:22 PM Shuah Khan <[email protected]> wrote:
> >>>
> >>> On 7/7/22 10:48 PM, David Gow wrote:
> >>>> Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run.
> >>>> Due to KUnit tests not being intended to run on production systems, and
> >>>> potentially causing problems (or security issues like leaking kernel
> >>>> addresses), the kernel's state should not be considered safe for
> >>>> production use after KUnit tests are run.
> >>>>
> >>>> This both marks KUnit modules as test modules using MODULE_INFO() and
> >>>> manually taints the kernel when tests are run (which catches builtin
> >>>> tests).
> >>>>
> >>>> Acked-by: Luis Chamberlain <[email protected]>
> >>>> Tested-by: Daniel Latypov <[email protected]>
> >>>> Reviewed-by: Brendan Higgins <[email protected]>
> >>>> Signed-off-by: David Gow <[email protected]>
> >>>> ---
> >>>>
> >>>> No changes since v5:
> >>>> https://lore.kernel.org/linux-kselftest/[email protected]/
> >>>>
> >>>> No changes since v4:
> >>>> https://lore.kernel.org/linux-kselftest/[email protected]/
> >>>>
> >>>
> >>> David, Brendan, Andrew,
> >>>
> >>> Just confirming the status of these patches. I applied v4 1/3 and v4 3/4
> >>> to linux-kselftest kunit for 5.20-rc1.
> >>> I am seeing v5 and v6 now. Andrew applied v5 looks like. Would you like
> >>> me to drop the two I applied? Do we have to refresh with v6?
> >>
> >> Just noting here that there'll be a merge conflict between this patch
> >> (3/4) and some other patches lined up to go through the kunit tree:
> >> https://patchwork.kernel.org/project/linux-kselftest/patch/[email protected]/
> >>
> >> Not sure how we want to handle that.
> >>
> >
> > I can go drop the two patches and have Andrew carry the series through
> > mm tree.
> >
>
> Sorry spoke too soon. Yes there are others that might have conflicts as
> Daniel pointed out:
>
> https://patchwork.kernel.org/project/linux-kselftest/patch/[email protected]/
>
> thanks,
> -- Shuah
>
Thanks everyone for pointing these out.
I've rebased the other series (the KUnit module support one:
https://lore.kernel.org/linux-kselftest/[email protected]/
) on top of this.
If they all go in via the kselftest/kunit tree, everything should be fine now.
Cheers,
-- David
On 7/8/22 9:35 PM, David Gow wrote:
> On Sat, Jul 9, 2022 at 5:24 AM Shuah Khan <[email protected]> wrote:
>>
>> On 7/8/22 3:22 PM, Shuah Khan wrote:
>>> On 7/8/22 3:00 PM, Daniel Latypov wrote:
>>>> On Fri, Jul 8, 2022 at 1:22 PM Shuah Khan <[email protected]> wrote:
>>>>>
>>>>> On 7/7/22 10:48 PM, David Gow wrote:
>>>>>> Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run.
>>>>>> Due to KUnit tests not being intended to run on production systems, and
>>>>>> potentially causing problems (or security issues like leaking kernel
>>>>>> addresses), the kernel's state should not be considered safe for
>>>>>> production use after KUnit tests are run.
>>>>>>
>>>>>> This both marks KUnit modules as test modules using MODULE_INFO() and
>>>>>> manually taints the kernel when tests are run (which catches builtin
>>>>>> tests).
>>>>>>
>>>>>> Acked-by: Luis Chamberlain <[email protected]>
>>>>>> Tested-by: Daniel Latypov <[email protected]>
>>>>>> Reviewed-by: Brendan Higgins <[email protected]>
>>>>>> Signed-off-by: David Gow <[email protected]>
>>>>>> ---
>>>>>>
>>>>>> No changes since v5:
>>>>>> https://lore.kernel.org/linux-kselftest/[email protected]/
>>>>>>
>>>>>> No changes since v4:
>>>>>> https://lore.kernel.org/linux-kselftest/[email protected]/
>>>>>>
>>>>>
>>>>> David, Brendan, Andrew,
>>>>>
>>>>> Just confirming the status of these patches. I applied v4 1/3 and v4 3/4
>>>>> to linux-kselftest kunit for 5.20-rc1.
>>>>> I am seeing v5 and v6 now. Andrew applied v5 looks like. Would you like
>>>>> me to drop the two I applied? Do we have to refresh with v6?
>>>>
>>>> Just noting here that there'll be a merge conflict between this patch
>>>> (3/4) and some other patches lined up to go through the kunit tree:
>>>> https://patchwork.kernel.org/project/linux-kselftest/patch/[email protected]/
>>>>
>>>> Not sure how we want to handle that.
>>>>
>>>
>>> I can go drop the two patches and have Andrew carry the series through
>>> mm tree.
>>>
>>
>> Sorry spoke too soon. Yes there are others that might have conflicts as
>> Daniel pointed out:
>>
>> https://patchwork.kernel.org/project/linux-kselftest/patch/[email protected]/
>>
>> thanks,
>> -- Shuah
>>
>
> Thanks everyone for pointing these out.
>
> I've rebased the other series (the KUnit module support one:
> https://lore.kernel.org/linux-kselftest/[email protected]/
> ) on top of this.
>
> If they all go in via the kselftest/kunit tree, everything should be fine now.
>
> Cheers,
> -- David
>
Thank you David. All patches applied now to linux-kselftest kunit for 5.20-rc1
thanks,
-- Shuah