linux-kernel - Re: [git pull] vfs.git pile 3

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-=wiMFU1+pyG9AgbGSZfxNpoOzOEmjVyy87J6Q8aPKAJ7jQ@mail.gmail.com>
Date:   Wed, 3 Aug 2022 19:16:12 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Matthew Wilcox <willy@...radead.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [git pull] vfs.git pile 3 - dcache

On Wed, Aug 3, 2022 at 6:33 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> We don't care if the lock is held or not. The point of the matter is that
> spinlocks in RT do not disable preemption. The code that the
> preempt_disable_under_spinlock() is inside, can not be preempted. If it is,
> bad things can happen.

I think you're missing Willy's point - the use would be to verify that
the spinlock really *is* held, because that's what disables preemption
on non-RT.

But no, I don't think it's worth the pain to have to specify which
spinlock is held, because the spinlock might have been taken by the
caller and we don't even have access to it - or care - we just know
somebody did take it.

If we want extra debuggingm it might be something like just verifying
that yes, the preempt count (on a non-RT preemptible kernel) really is
elevated already.

> I wonder if raw_preempt_disable() would be another name to use?

NO!

The point is that normal non-RT code does *not* disable preemption at
all, because it is already disabled thanks to the earlier spinlock.

So we definitely do *not* want to call this "raw_preempt_disable()",
because it's actually not supposed to normally disable anything at
all. Only for RT, where the spinlock code doesn't do it.

             Linus