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;
Subject: Re: [PATCH] mm, slub: add cpus_read_lock/unlock() for
 slab_mem_going_offline_callback()
To:     Stephen Rothwell <sfr@canb.auug.org.au>
Cc:     qiang.zhang@windriver.com, vbabka@suse.cz,
        akpm@linux-foundation.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
References: <20210816074605.30336-1-qiang.zhang@windriver.com>
 <ef944ea5-c3cb-24e5-1ff8-b8e1008fa6ed@redhat.com>
 <20210816181751.17f98cc2@canb.auug.org.au>
From:   David Hildenbrand <david@redhat.com>
Organization: Red Hat
Message-ID: <e9b22a8a-e5d2-955f-65b9-1e30efe24f81@redhat.com>
Date:   Mon, 16 Aug 2021 10:23:49 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20210816181751.17f98cc2@canb.auug.org.au>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 16.08.21 10:17, Stephen Rothwell wrote:
> Hi David,
> 
> On Mon, 16 Aug 2021 10:04:13 +0200 David Hildenbrand <david@redhat.com> wrote:
>>
>> On 16.08.21 09:46, qiang.zhang@windriver.com wrote:
>>> From: "Qiang.Zhang" <qiang.zhang@windriver.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