linux-kernel - Re: commit 3d5bfbd97163 versus -rt

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: <20210616080006.rrv3kdmuozqzchv6@spock.localdomain>
Date:   Wed, 16 Jun 2021 10:00:06 +0200
From:   Oleksandr Natalenko <oleksandr@...alenko.name>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Rasmus Villemoes <rasmus.villemoes@...vas.dk>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        linux-rt-users@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Esben Haabendal <esben@...nix.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Carlos Jimenez <javashin1986@...il.com>,
        Wolfram Sang <wsa@...nel.org>
Subject: Re: commit 3d5bfbd97163 versus -rt

Hello.

On Tue, Jun 15, 2021 at 01:09:59PM -0400, Steven Rostedt wrote:
> On Tue, 15 Jun 2021 18:24:20 +0200
> Rasmus Villemoes <rasmus.villemoes@...vas.dk> wrote:
> 
> > > ~ # uname -r
> > > 5.10.42-00001-g10216cf63a12
> > > ~ # grep -ow threadirqs /proc/cmdline
> > > threadirqs
> > > ~ # zcat /proc/config.gz | grep FORCED_THREADING
> > > CONFIG_IRQ_FORCED_THREADING=y
> > > ~ # dmesg | grep WARNING
> > > ~ #  
> > 
> > And as an extra data point, it also doesn't trigger on 5.10.41-rt42
> > configured without PREEMPT_RT but with threadirqs on the command line.
> 
> Sounds to me that there's a "spin_lock_irq*" somewhere in the path, because
> from what I can see, there's not much difference with the IRQ code between
> 5.10.41 and 5.10.41-rt42. But if you are seeing it only with PREEMPT_RT
> set, that tells me that without PREEMPT_RT, interrupts are disabled at that
> point, but not with PREEMPT_RT. The only thing I can think of that would do
> that is a spin_lock_irq*() taken (not a raw_spin_lock_irq*()).

This reminds me [1] and [2].

I'm carrying forward [3] in my domestic kernel build to cope with that.

/cc'ing people involved back then.

[1] https://lore.kernel.org/lkml/20201204201930.vtvitsq6xcftjj3o@spock.localdomain/
[2] https://bugzilla.kernel.org/show_bug.cgi?id=202453
[3] https://gitlab.com/post-factum/pf-kernel/-/commit/f7c99d74cca99d71179d63e827811f0df51bd8fc

-- 
  Oleksandr Natalenko (post-factum)