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: <20230908225018.GB32012@noisy.programming.kicks-ass.net>
Date:   Sat, 9 Sep 2023 00:50:18 +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
Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED

On Fri, Sep 08, 2023 at 10:15:07AM -0700, Linus Torvalds wrote:
> On Fri, 8 Sept 2023 at 00:03, Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > Which on a PREEMPT_COUNT=n build will cause preemption while holding the
> > spinlock. I think something like the below will cause sufficient
> > warnings to avoid growing patterns like that.
> 
> Hmm. I don't think that warning is valid.
> 
> Disabling preemption is actually fine if it's done in an interrupt,
> iow if we have
> 
>         allow_resched();
>            -> irq happens
>                 spin_lock();  // Ok and should *not* complain
>                 ...
>                 spin_unlock();
>             <- irq return (and preemption)

Indeed.

> 
> which actually makes me worry about the nested irq case, because this
> would *not* be ok:
> 
>         allow_resched();
>            -> irq happens
>                 -> *nested* irq happens
>                 <- nested irq return (and preemption)
> 
> ie the allow_resched() needs to still honor the irq count, and a
> nested irq return obviously must not cause any preemption.

I think we killed nested interrupts a fair number of years ago, but I'll
recheck -- but not today, sleep is imminent.