From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.4 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55173C55178 for ; Tue, 27 Oct 2020 16:31:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AE5E420757 for ; Tue, 27 Oct 2020 16:31:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AE5E420757 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id ADF5E6B0068; Tue, 27 Oct 2020 12:31:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A90256B006C; Tue, 27 Oct 2020 12:31:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 97FB36B0070; Tue, 27 Oct 2020 12:31:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0225.hostedemail.com [216.40.44.225]) by kanga.kvack.org (Postfix) with ESMTP id 676066B0068 for ; Tue, 27 Oct 2020 12:31:20 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 06684824999B for ; Tue, 27 Oct 2020 16:31:20 +0000 (UTC) X-FDA: 77418245520.08.field52_04006662727d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id C47B61819E76B for ; Tue, 27 Oct 2020 16:31:19 +0000 (UTC) X-HE-Tag: field52_04006662727d X-Filterd-Recvd-Size: 4798 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Tue, 27 Oct 2020 16:31:19 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 9EACBAFF2; Tue, 27 Oct 2020 16:31:17 +0000 (UTC) To: Laurent Dufour , Michal Hocko Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, nathanl@linux.ibm.com, cheloha@linux.ibm.com, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , stable@vger.kernel.org References: <20201027140926.276-1-ldufour@linux.ibm.com> <20201027142421.GW20500@dhcp22.suse.cz> <11bdd295-3ef8-fbeb-2c76-2a109fa26f19@linux.ibm.com> <20201027150350.GZ20500@dhcp22.suse.cz> From: Vlastimil Babka Subject: Re: [PATCH] mm/slub: fix panic in slab_alloc_node() Message-ID: <7ef64e75-2150-01a9-074d-a754348683b3@suse.cz> Date: Tue, 27 Oct 2020 17:31:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 10/27/20 4:12 PM, Laurent Dufour wrote: > Le 27/10/2020 =C3=A0 16:03, Michal Hocko a =C3=A9crit=C2=A0: >> On Tue 27-10-20 15:39:46, Laurent Dufour wrote: >>> Le 27/10/2020 =C3=A0 15:24, Michal Hocko a =C3=A9crit=C2=A0: >>>> [Cc Vlastimil] >>>> >>>> On Tue 27-10-20 15:09:26, Laurent Dufour wrote: >>>> >>>> Could you be more specific? I am especially confused how the memory >>>> hotplug is involved here. What kind of flush are we talking about? >>> >>> This happens when flush_cpu_slab() is called when a memory block is a= bout to >>> be offlined, see slab_mem_going_offline_callback() called by the >>> MEM_GOING_OFFLINE's callback triggered by offline_pages(). >>=20 >> This would be a very valuable information for the changelog. I have to >> admit that a more detailed description would help somebody not really >> familiar with slub internals like me. Agreed, please include that. >> I still fail to see why do we get an inconsistent state though. I >> thought that no object is associated with an offlined page so how come >> we have an object without any page? >=20 > The inconsistent state came from the IPI interrupt calling flush_cpu_sl= ab() > being taken between reading c->freelist and c->page. Yes; also good to state explicitly. >> How does this allocation path synchronizes with the offline callback? >=20 > My understanding is that this is done by the call to this_cpu_cmpxchg_d= ouble() > done later, but I would let the slub experts detail that point. Yes, cmpxchg will detect that c->freelist changed. If we managed to read = both=20 c->freelist and c->page before the interrupt (and thus not crash),=20 cmpxchg_double will fail on the s->cpu_slab->tid part as flush_slab() wil= l also=20 bump the tid. >>>>> In commit 6159d0f5c03e ("mm/slub.c: page is always non-NULL in >>>>> node_match()") check on the page pointer has been removed assuming = that >>>>> page is always valid when it is called. It happens that this is not= true in >>>>> that particular case, so check for page before calling node_match()= here. >>>>> >>>>> Fixes: 6159d0f5c03e ("mm/slub.c: page is always non-NULL in node_ma= tch()") >>>>> Signed-off-by: Laurent Dufour With the expanded changelog, Acked-by: Vlastimil Babka Thanks! >>>>> Cc: Christoph Lameter >>>>> Cc: Pekka Enberg >>>>> Cc: David Rientjes >>>>> Cc: Joonsoo Kim >>>>> Cc: Andrew Morton >>>>> Cc: stable@vger.kernel.org >>>>> --- >>>>> mm/slub.c | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/mm/slub.c b/mm/slub.c >>>>> index 8f66de8a5ab3..7dc5c6aaf4b7 100644 >>>>> --- a/mm/slub.c >>>>> +++ b/mm/slub.c >>>>> @@ -2852,7 +2852,7 @@ static __always_inline void *slab_alloc_node(= struct kmem_cache *s, >>>>> object =3D c->freelist; >>>>> page =3D c->page; >>>>> - if (unlikely(!object || !node_match(page, node))) { >>>>> + if (unlikely(!object || !page || !node_match(page, node))) { >>>>> object =3D __slab_alloc(s, gfpflags, node, addr, c); >>>>> } else { >>>>> void *next_object =3D get_freepointer_safe(s, object); >>>>> --=20 >>>>> 2.29.1 >>>>> >>>> >>> >>=20 >=20 >=20