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: <CAHk-=whMkp68vNxVn1H3qe_P7n=X2sWPL9kvW22dsvMFH8FcQQ@mail.gmail.com>
Date:   Sun, 10 Sep 2023 11:32:32 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Ankur Arora <ankur.a.arora@...cle.com>
Cc:     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, rostedt@...dmis.org,
        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 Sun, 10 Sept 2023 at 03:01, Ankur Arora <ankur.a.arora@...cle.com> wrote:
>
> Seems to me that associating an allow_resched flag with the stack also
> has similar issue. Couldn't the context level change while we are on the
> same stack?

On x86-64 no, but in other situations yes.

> I guess the problem is that allow_resched()/disallow_resched() really
> need to demarcate a section of code having some property, but instead
> set up state that has much wider scope.
>
> Maybe code that allows resched can be in a new .section ".text.resched"
> or whatever, and we could use something like this as a check:

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.

At the same time I really hate that, because I was hoping we'd be able
to use this to not have so many of those annoying and random
"cond_resched()" calls.

I literally merged another batch of "random stupid crap" an hour ago:
commit 3d7d72a34e05 ("x86/sgx: Break up long non-preemptible delays in
sgx_vepc_release()") literally just adds manual 'cond_resched()' calls
in random places.

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.

Of course, that was probably always unrealistic, and those random
cond_resched() calls we just added probably couldn't just be replaced
by "you can reschedule me" simply because the functions quite possibly
end up taking some lock hidden in one of the xa_xyz() functions.

For the _particular_ case of "give me a preemptible big memory copy /
clear", the section model seems fine. It's just that we do have quite
a bit of code where we can end up with long loops that want that
cond_resched() too that I was hoping we'd _also_ be able to solve.

                   Linus