linux-kernel - Re: Linux 6.3-rc2

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wi8xQw6eTRncbJfWWYHHi0UBG2B_AfHrzZbPr=k0V_WYQ@mail.gmail.com>
Date:   Mon, 13 Mar 2023 11:21:44 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Guenter Roeck <linux@...ck-us.net>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 6.3-rc2

On Mon, Mar 13, 2023 at 8:53 AM Guenter Roeck <linux@...ck-us.net> wrote:
>
> Warning backtraces in calls from ct_nmi_enter(),
> seen randomly.

Hmm.

I suspect this one is a bug in the warning, not in the kernel,
although I have no idea why it would have started happening now.

This happens from an irq event, but that check is not *supposed* to
happen at all from interrupts:

         * We dont accurately track softirq state in e.g.
         * hardirq contexts (such as on 4KSTACKS), so only
         * check if not in hardirq contexts:

but I think that the ct_nmi_enter() function was called before the
hardirq count had even been incremented.

> Sample decoded stack trace:

Hmm. That WARNING backtrace doesn't actually seem to follow the stack
chain, so it only shows the irq stack, not where the irq happened.

> Seen if CONFIG_DEBUG_LOCK_ALLOC=y and CONFIG_CONTEXT_TRACKING_IDLE=y.
> It seems that rcu_read_lock_sched_held() can be true when entering an interrupt.
>
> The problem is not seen in v6.2, but occurs randomly on ToT with various
> arm emulations.

Strange. I must be wrong about this being a race on the warning
itself, because that warning has been there for a long long time.

Adding in some people who might have more of a clue. I'm thinking
Frederic and Paul might know what's up with the context tracking, but
I don't see why this would be arm-related or have started recently.
But I do note that PeterZ did some rcuidle tracing cleanups that do
end up affecting arm too.

So adding PeterZ too.

Original email with full details at

   https://lore.kernel.org/lkml/d915df60-d06b-47d4-8b47-8aa1bbc2aac7@roeck-us.net/

for added peeps.

Anybody?

                     Linus