[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <00a7c04b109c01a7668abc2a8192a6b889765de5.camel@gmx.de>
Date: Mon, 19 Jul 2021 06:01:38 +0200
From: Mike Galbraith <efault@....de>
To: Vlastimil Babka <vbabka@...e.cz>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>
Cc: linux-rt-users@...r.kernel.org,
Mel Gorman <mgorman@...hsingularity.net>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: [patch] v2 mm/slub: restore/expand unfreeze_partials() local
exclusion scope
(a pox on whomever broke evolution text quoting yet again)
On Sun, 2021-07-18 at 23:19 +0200, Vlastimil Babka wrote:
>
> Hm you mention put_cpu_partial() but your patch handles only the
> unfreeze_partial() call from that function?
Indeed, and that's because when I poked that slub_get_cpu_ptr(), it
poked me back by real deal deadlocking on boot, so I posted the
restoration of previously existing exclusion points with the
unlock/relock to appease lockdep (big hairy wart) bit instead.
> If I understand the problem
> correctly, all modifications of cpu_slab->partial has to be protected
> on RT after the local_lock conversion, thus also the one that
> put_cpu_partial() does by itself (via this_cpu_cmpxchg).
Yup, that's what I concluded too, but box disagreed by not booting when
I did that, while seemingly being perfectly fine with the one in
put_cpu_partial() itself. I figured my slub_get_cpu_ptr() replacement
had failed due to list_lock/local_lock order woes that I didn't notice
until after box bricked on me, but despite the unlock/relock in this
patch, it still manages to be a -ENOBOOT.
-Mike
Powered by blists - more mailing lists