2022-05-03 00:26:12

by John Ogness

[permalink] [raw]
Subject: Re: [next] i386: kunit: ASSERTION FAILED at mm/kfence/kfence_test.c:547

On 2022-05-02, Petr Mladek <[email protected]> wrote:
>> My proposal would be to fix the tracepoint like so:
>>
>> | --- a/kernel/printk/printk.c
>> | +++ b/kernel/printk/printk.c
>> | @@ -2002,8 +2002,6 @@ static void call_console_driver(struct console *con, const char *text, size_t le
>> | {
>> | size_t dropped_len;
>> |
>> | - trace_console_rcuidle(text, len);
>> | -
>> | if (con->dropped && dropped_text) {
>> | dropped_len = snprintf(dropped_text, DROPPED_TEXT_MAX,
>> | "** %lu printk messages dropped **\n",
>> | @@ -2178,6 +2176,8 @@ static u16 printk_sprint(char *text, u16 size, int facility,
>> | }
>> | }
>> |
>> | + trace_console_rcuidle(text, text_len);
>> | +
>> | return text_len;
>> | }
>>
>> This fixes the KFENCE and KCSAN tests.
>>
>> Unless I hear objections, I'll prepare a patch explaining why we need to
>> fix the tracepoint.
>
> It makes perfect sense to me.

This is the easiest place for it. However, it should be clear that in
the context of trace_console_rcuidle(), the message is not yet visible
to any readers. The message _will_ get committed and definitely _will_
become visible at some point. But it is not (yet) visible at _this_
point. Maybe that is OK for what it is being used for.

If trace_console_rcuidle() must be called at the point of visibility for
readers, it becomes more complicated.

John


2022-05-03 09:41:49

by Marco Elver

[permalink] [raw]
Subject: Re: [next] i386: kunit: ASSERTION FAILED at mm/kfence/kfence_test.c:547

On Mon, 2 May 2022 at 11:20, John Ogness <[email protected]> wrote:
>
> On 2022-05-02, Petr Mladek <[email protected]> wrote:
> >> My proposal would be to fix the tracepoint like so:
[...]
> >> This fixes the KFENCE and KCSAN tests.
> >>
> >> Unless I hear objections, I'll prepare a patch explaining why we need to
> >> fix the tracepoint.
> >
> > It makes perfect sense to me.
>
> This is the easiest place for it. However, it should be clear that in
> the context of trace_console_rcuidle(), the message is not yet visible
> to any readers. The message _will_ get committed and definitely _will_
> become visible at some point. But it is not (yet) visible at _this_
> point. Maybe that is OK for what it is being used for.
>
> If trace_console_rcuidle() must be called at the point of visibility for
> readers, it becomes more complicated.

I think that wasn't the original intent, so fixing it up to actually
happen on printk() is probably the sanest thing. I sent the patch
trying to explain:
https://lore.kernel.org/all/[email protected]/

Thank you both for the valuable pointers!

-- Marco

> John