linux-kernel - Re: [next] i386: kunit: ASSERTION FAILED at mm/kfence/kfence

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANpmjNOgT_vvCtEOT8idcZdXgLcZrEwFvsj0GFctpCnNmq4eKA@mail.gmail.com>
Date:   Tue, 3 May 2022 09:42:49 +0200
From:   Marco Elver <elver@...gle.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Petr Mladek <pmladek@...e.com>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        lkft-triage@...ts.linaro.org, linux-mm <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Alexander Potapenko <glider@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Anders Roxell <anders.roxell@...aro.org>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Andrey Ryabinin <ryabinin.a.a@...il.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Evgenii Stepanov <eugenis@...gle.com>,
        Mark Rutland <mark.rutland@....com>,
        Peter Collingbourne <pcc@...gle.com>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Will Deacon <will@...nel.org>
Subject: Re: [next] i386: kunit: ASSERTION FAILED at mm/kfence/kfence_test.c:547

On Mon, 2 May 2022 at 11:20, John Ogness <john.ogness@...utronix.de> wrote:
>
> On 2022-05-02, Petr Mladek <pmladek@...e.com> 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/20220503073844.4148944-1-elver@google.com/

Thank you both for the valuable pointers!

-- Marco

> John