linux-kernel - Re: [PATCH v2 7/9] sched: define TIF_ALLOW

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: <20230911182012.7f1f35c1@gandalf.local.home>
Date:   Mon, 11 Sep 2023 18:20:12 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Ankur Arora <ankur.a.arora@...cle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org, x86@...nel.org,
        akpm@...ux-foundation.org, luto@...nel.org, bp@...en8.de,
        dave.hansen@...ux.intel.com, hpa@...or.com, mingo@...hat.com,
        juri.lelli@...hat.com, vincent.guittot@...aro.org,
        willy@...radead.org, mgorman@...e.de, tglx@...utronix.de,
        jon.grimm@....com, bharata@....com, raghavendra.kt@....com,
        boris.ostrovsky@...cle.com, konrad.wilk@...cle.com
Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED

On Mon, 11 Sep 2023 13:50:53 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> And it seems like it's actually server people who want the "no
> preemption" (and presumably avoid all the preempt count stuff entirely
> - it's not necessarily the *preemption* that is the cost, it's the
> incessant preempt count updates)

I'm sure there's some overhead with the preemption itself. With the
meltdown/spectre mitigations going into and out of the kernel does add some
more overhead. And finishing a system call before being preempted may give
some performance benefits for some micro benchmark out there.

Going out on a crazy idea, I wonder if we could get the compiler to help us
here. As all preempt disabled locations are static, and as for functions,
they can be called with preemption enabled or disabled. Would it be
possible for the compiler to mark all locations that need preemption disabled?

If a function is called in a preempt disabled section and also called in a
preempt enable section, it could make two versions of the function (one
where preemption is disabled and one where it is enabled).

Then all we would need is a look up table to know if preemption is safe or
not by looking at the instruction pointer.

Yes, I know this is kind of a wild idea, but I do believe it is possible.

The compiler wouldn't need to know of the concept of "preemption" just a
"make this location special, and keep functions called by that location
special and duplicate them if they are are called outside of this special
section".

 ;-)

-- Steve