Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <72a045663bf8f091ae11dd328d5e085541d54fcd.camel@gmx.de>
Subject: Re: [rfc/patch] mm/slub: restore/expand unfreeze_partials() local
 exclusion scope
From:   Mike Galbraith <efault@gmx.de>
To:     Vlastimil Babka <vbabka@suse.cz>,
        Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>
Cc:     linux-rt-users@vger.kernel.org,
        Mel Gorman <mgorman@techsingularity.net>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Sun, 25 Jul 2021 17:02:22 +0200
In-Reply-To: <76dedfc3-0497-1776-d006-486b9bfd88da@suse.cz>
References: <87tul5p2fa.ffs@nanos.tec.linutronix.de>
         <8c0e0c486056b5185b58998f2cce62619ed3f05c.camel@gmx.de>
         <878s2fnv79.ffs@nanos.tec.linutronix.de>
         <6c0e20dd84084036d5068e445746c3ed7e82ec4b.camel@gmx.de>
         <7431ceb9761c566cf2d1f6f263247acd8d38c4b5.camel@gmx.de>
         <f9935c4c-078c-4b52-5297-64ee22272664@suse.cz>
         <f16b78bd3bb8fecf734017d40274e4c3294554ab.camel@gmx.de>
         <240f104fc6757d8c38fa01342511eda931632d5a.camel@gmx.de>
         <69da2ecd-a797-e264-fbfa-13108dc7a573@suse.cz>
         <84a7bd02cf109c6a5a8c7cc2bfc2898cb98270aa.camel@gmx.de>
         <5be1a703-9a0a-4115-1d69-634e5e8ecefd@suse.cz>
         <bd121f5db01404774dbecc70bd7155f8431d8046.camel@gmx.de>
         <76dedfc3-0497-1776-d006-486b9bfd88da@suse.cz>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.2 
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sun, 2021-07-25 at 16:16 +0200, Vlastimil Babka wrote:
> On 7/25/21 4:09 PM, Mike Galbraith wrote:
> > On Sat, 2021-07-24 at 00:39 +0200, Vlastimil Babka wrote:
> > >
> > > If not, then I would expect this to work (I don't think they ever ne=
st
> > > in the opposite order, also lockdep should tell us instead of
> > > -ENOBOOT?), but might be missing something...
> >
> > Yeah, like #ifndef CONFIG_PREMPT_RT at the bottom of the loop that our
> > useless damn eyeballs auto-correct instead of reporting :)
>
> Well doh, good catch.

I never did see it.  I got sick of saying "but but but", and did make
mm/slub.i, which made it glow.

> Hope fixing that helps then?

Yeah, though RT should perhaps be pinned across release/re-acquire?

Actually, local locks should rediscover the recursion handling skills
they long had so such RT specific hole poking isn't necessary.  There
previously would have been no ifdef+typo there for eyeballs to miss and
miss and miss.

	-Mike