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-=wif4WMu-k9Pi9BoVRZwH6npjS6Km9DR9aROxANZzN2iRQ@mail.gmail.com>
Date:   Fri, 8 Sep 2023 10:15:07 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Peter Zijlstra <peterz@...radead.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, 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)

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've lost sight of the original patch series, and I assume / hope that
the above isn't actually an issue, but exactly because I've lost sight
of the original patches and only have this one in my mailbox I wanted
to check.

            Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ