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: <87bkdsh1nf.ffs@tglx>
Date:   Sun, 24 Sep 2023 02:10:12 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        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,
        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 24 2023 at 00:50, Thomas Gleixner wrote:
> On Tue, Sep 19 2023 at 14:30, Thomas Gleixner wrote:
> That's way better because it describes the scope and the task will
> either schedule out in lock() on contention or provide a sensible lazy
> preemption point in preempt_lazy_enable(). It also nests properly:
>
>       preempt_lazy_disable();
>       lock(A);
>       do_stuff()
>         preempt_lazy_disable();
>         lock(B);
>         do_other_stuff();
>         unlock(B);
>         preempt_lazy_enable();
>       unlock(A);
>       preempt_lazy_enable();
>
> So in this case it does not matter wheter do_stuff() is invoked from a
> lock held section or not. The scope which defines the throughput
> relevant hint to the scheduler is correct in any case.

Which also means that automatically injecting it into lock primitives
makes suddenly sense in the same way as the implicit preempt_disable()
in the rw/spinlock primitives does.

Thanks,

        tglx