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]

Date:   Mon, 11 Sep 2023 17:04:10 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Ankur Arora <ankur.a.arora@...cle.com>,
        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, rostedt@...dmis.org,
        tglx@...utronix.de, jon.grimm@....com, bharata@....com,
        raghavendra.kt@....com, boris.ostrovsky@...cle.com,
        konrad.wilk@...cle.com, jgross@...e.com, andrew.cooper3@...rix.com
Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED

On Sun, Sep 10, 2023 at 11:32:32AM -0700, Linus Torvalds wrote:

> I was hoping that we'd have some generic way to deal with this where
> we could just say "this thing is reschedulable", and get rid of - or
> at least not increasingly add to - the cond_resched() mess.

Isn't that called PREEMPT=y ? That tracks precisely all the constraints
required to know when/if we can preempt.

The whole voluntary preempt model is basically the traditional
co-operative preemption model and that fully relies on manual yields.

The problem with the REP prefix (and Xen hypercalls) is that
they're long running instructions and it becomes fundamentally
impossible to put a cond_resched() in.

> Yes. I'm starting to think that that the only sane solution is to
> limit cases that can do this a lot, and the "instruciton pointer
> region" approach would certainly work.

>From a code locality / I-cache POV, I think a sorted list of
(non overlapping) ranges might be best.