linux-kernel - Re: [patch 05/12] timekeeping_notify: use stop_machine

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: <87wmr9k8g1.ffs@tglx>
Date: Mon, 12 Feb 2024 16:29:02 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Marcelo Tosatti <mtosatti@...hat.com>
Cc: linux-kernel@...r.kernel.org, Daniel Bristot de Oliveira
 <bristot@...nel.org>, Juri Lelli <juri.lelli@...hat.com>, Valentin
 Schneider <vschneid@...hat.com>, Frederic Weisbecker
 <frederic@...nel.org>, Leonardo Bras <leobras@...hat.com>, Peter Zijlstra
 <peterz@...radead.org>
Subject: Re: [patch 05/12] timekeeping_notify: use stop_machine_fail when
 appropriate

On Fri, Feb 09 2024 at 12:30, Marcelo Tosatti wrote:
> On Thu, Feb 08, 2024 at 04:23:58PM +0100, Thomas Gleixner wrote:
> So while I understand your point that root can (and should be) 
> able to perform any operations on the system, this interface would 
> be along the lines of:
>
> "I don't want isolated CPUs to be interrupted, but i am not aware of
> which kernel interfaces can result in interruptions to isolated CPUs.
>
> Lets indicate through this cpumask, which the kernel can consult, 
> that we'd like userspace operations to fail, if they were going
> to interrupt an isolated CPU".
>
> Its the kernel that knows which operations might interrupt 
> isolated CPUs, not userspace.

Right, but you cannot just throw a CPU mask in and decide that it will
work for everything.

As I explained to you before, these interfaces cannot be treated in the
same way just because they might end up in a SMP function call.

You are definining a binary all or nothing policy which is the worst
thing you can do, because it prevents any fine grained decision and in
case an interface is needed for a particular operation it requires to
open up the gates for everything. Works for me and scratches my itch are
not really valid engineering principles.

Not to talk about the blind replacement of the SMP function call which
causes inconsistent state as I pointed out to you.

Thanks

        tglx