[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e9b22a8a-e5d2-955f-65b9-1e30efe24f81@redhat.com>
Date: Mon, 16 Aug 2021 10:23:49 +0200
From: David Hildenbrand <david@...hat.com>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: qiang.zhang@...driver.com, vbabka@...e.cz,
akpm@...ux-foundation.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm, slub: add cpus_read_lock/unlock() for
slab_mem_going_offline_callback()
On 16.08.21 10:17, Stephen Rothwell wrote:
> Hi David,
>
> On Mon, 16 Aug 2021 10:04:13 +0200 David Hildenbrand <david@...hat.com> wrote:
>>
>> On 16.08.21 09:46, qiang.zhang@...driver.com wrote:
>>> From: "Qiang.Zhang" <qiang.zhang@...driver.com>
>>>
>>> The flush_all_cpus_locked() should be called with cpus_read_lock/unlock(),
>>> ensure flush_cpu_slab() can be executed on schedule_on CPU.
>>>
>>> Fixes: 1c84f3c91640 ("mm, slub: fix memory and cpu hotplug related lock ordering issues")
>>
>> Which branch contains this commit? At least not linux.git or linux-next
>
> It is Andrew's mmotm which is included in linux-next but gets rebased
Maybe I am blind or need more coffee:
https://www.ozlabs.org/~akpm/mmotm/series
> often, so, for example, that SHA1 is no longer valid in linux-next
> today (is is now fd917c6407fb).
>
> This (unfortunately) make Fixes tags less useful for mmotm :-(
Right, and it somewhat makes sense, because Andrew will actually squash
patches before sending them further upstream.
Ideally, such fixes should be discussed in the respective patch series,
because before they go upstream, they are still under development.
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists