Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5159849imu; Sun, 25 Nov 2018 18:03:02 -0800 (PST) X-Google-Smtp-Source: AFSGD/WlD7haSHb1z/Igv7NuSAQWfTu7eGk0+nqe4SAUwp/G2J+1W+6Fnzh2dfF4vMZzUGfCAHTx X-Received: by 2002:a62:59c9:: with SMTP id k70mr10887383pfj.243.1543197781962; Sun, 25 Nov 2018 18:03:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543197781; cv=none; d=google.com; s=arc-20160816; b=cpY28trQZGoIJrIqgPmDLA2tjPwzsyaxgAByEfcWK9vy+PwEC9KQR4AA1OHAVsiGJR 3VfjlPC2Xm1omG8YqPq4KeUtYGV+uSLN4vUsRoAIqQsIFsH/i0fydEva0bOH8/z3TbF5 o90nRQ3HbBhERBVjJTTSWyPDMts4ZF4pfJX0CiNthEpASaaBi6ftTM+L0Pmo6LM4CEYq cN5us7vqZP9PoBENy2OzOZz1qzkSIkohL27ELotCWwmX3E6xF2NdQGA1/TBlS4aN6dQt s/VtO4ysZKV2ZmbhZxXBxA20tnXNLH8enxy4pQV/n1adu/A5Us6a0afw6jfYyEkVPhXr ONLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=kek+oZ6K3t/3VHkMYHtyuoVBR/cg4/3cOlsVuML8ags=; b=hNuBKKofxGlFV/EDFn/Vq3pxLwyGQwOpPJmlgNZStykDs9Ynt2Rm4s2kQpwLMPfDi0 Z90uLM0hSw507lkx8X7/IXsyxe0DMNyreKQJqfy86Aigu2+WJgLeBcsHtd/keCW6CarH JbjI5sl4O1rPMoow0pBV5e5gSA6dM8+xaC/CokIGDgkTfq8s6wB5S/VGXG2x0bn2PXVv a/x94LGna49kWv0VXvWADg63Fapzyj2szJ8E4yQED1v79/UaGgS+rMZnEbCNtgauQ+rD +tJRUqaRiLGwjXfL6yZGjS1GGAng42jtmO4gtzmbCuW18ES4zGWJfZ47/TjOslCvXXRE dwhA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=jUcYuk9E; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u3si57636566pgj.300.2018.11.25.18.02.46; Sun, 25 Nov 2018 18:03:01 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=jUcYuk9E; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726194AbeKZMwn (ORCPT + 99 others); Mon, 26 Nov 2018 07:52:43 -0500 Received: from mail-io1-f66.google.com ([209.85.166.66]:37471 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726079AbeKZMwm (ORCPT ); Mon, 26 Nov 2018 07:52:42 -0500 Received: by mail-io1-f66.google.com with SMTP id a3so12640438ioc.4 for ; Sun, 25 Nov 2018 18:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kek+oZ6K3t/3VHkMYHtyuoVBR/cg4/3cOlsVuML8ags=; b=jUcYuk9E1QGX8XQ+k1YblCowJ+R0VQutr+cHDMn21JYNLzKdw2W5SvpqBFBWaiWq7i gsuzBdjbvBzr1Xjdh2xaaJK31x/D8jRUKBQlsH9WM7mNAAkRShOIedjoGERpVfQ/vJR0 PZeIcHtmhLeT1AkzWIKvH2J1rDGwg2jFMHJjeilGDl1P60hkjqvL/EmdUnE+g6U3fQfB 1423uyfrS8xSfFC9qVRbx5w4y1Mq4NBlBfSDeEDZT1MJPAvnJO3ItA9ZRkGAGqSoG8Ew azNcjMGzKPpJ+x502R/0Tjz9ymrzURqiArRxQMpMabPrcb0AaRJ732zwTuZW1hgz1pZO /HqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kek+oZ6K3t/3VHkMYHtyuoVBR/cg4/3cOlsVuML8ags=; b=SSG9q6rhfnI1z7TuQnYXzt0ULfju/sM+EDoT89bhQicjqF02YnE1bYNQCXS+d3yWYb vyWIxoTOLVndO4npLnX3e9I7dvr7ckS1/ky7l7ONgP09dW+eG0SdPCZJmFkluYFScvGY lzjJmzu2APgL0Cf6TlWZCDKGxY3Ucx6gNmXCPWDvJfobGJUM8zI4MbartLOniAdJde1A trHnBaoUqHbJ+wLSkljYRIOqzn+Tsn9F6FxQMwBSBTYSwmRJZhOzTydE5FTbmdtINeYf SVHBsV9QQX/+idktkSyCWog2dL4WqwnmD9XkWn2oglRo+zNiFITAto21cBODZKfkoHOH v08Q== X-Gm-Message-State: AA+aEWbWSXoEYchIORLHpJmOdSN5FYvUyKC5fLdGO+ADNPXDDD9d8thw /gg/26DS/EXDcKKxOLKRl7VhY9yuTz20yl3hx8Q= X-Received: by 2002:a5d:8c89:: with SMTP id g9mr19472878ion.111.1543197609129; Sun, 25 Nov 2018 18:00:09 -0800 (PST) MIME-Version: 1.0 References: <20181117013335.32220-1-wen.gang.wang@oracle.com> <5BF36EE9.9090808@huawei.com> In-Reply-To: <5BF36EE9.9090808@huawei.com> From: Wei Yang Date: Mon, 26 Nov 2018 09:59:58 +0800 Message-ID: Subject: Re: [PATCH] mm: use this_cpu_cmpxchg_double in put_cpu_partial To: zhong jiang Cc: Wengang Wang , Christopher Lameter , penberg@kernel.org, David Rientjes , iamjoonsoo.kim@lge.com, Andrew Morton , Linux-MM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 20, 2018 at 10:58 AM zhong jiang wrote: > > On 2018/11/17 9:33, Wengang Wang wrote: > > The this_cpu_cmpxchg makes the do-while loop pass as long as the > > s->cpu_slab->partial as the same value. It doesn't care what happened to > > that slab. Interrupt is not disabled, and new alloc/free can happen in the > > interrupt handlers. Theoretically, after we have a reference to the it, > > stored in _oldpage_, the first slab on the partial list on this CPU can be > > moved to kmem_cache_node and then moved to different kmem_cache_cpu and > > then somehow can be added back as head to partial list of current > > kmem_cache_cpu, though that is a very rare case. If that rare case really > > happened, the reading of oldpage->pobjects may get a 0xdead0000 > > unexpectedly, stored in _pobjects_, if the reading happens just after > > another CPU removed the slab from kmem_cache_node, setting lru.prev to > > LIST_POISON2 (0xdead000000000200). The wrong _pobjects_(negative) then > > prevents slabs from being moved to kmem_cache_node and being finally freed. > > > > We see in a vmcore, there are 375210 slabs kept in the partial list of one > > kmem_cache_cpu, but only 305 in-use objects in the same list for > > kmalloc-2048 cache. We see negative values for page.pobjects, the last page > > with negative _pobjects_ has the value of 0xdead0004, the next page looks > > good (_pobjects is 1). > > > > For the fix, I wanted to call this_cpu_cmpxchg_double with > > oldpage->pobjects, but failed due to size difference between > > oldpage->pobjects and cpu_slab->partial. So I changed to call > > this_cpu_cmpxchg_double with _tid_. I don't really want no alloc/free > > happen in between, but just want to make sure the first slab did expereince > > a remove and re-add. This patch is more to call for ideas. > Have you hit the really issue or just review the code ? > > I did hit the issue and fixed in the upstream patch unpredictably by the following patch. > e5d9998f3e09 ("slub: make ->cpu_partial unsigned int") > Zhong, I took a look into your upstream patch, while I am confused how your patch fix this issue? In put_cpu_partial(), the cmpxchg compare cpu_slab->partial (a page struct) instead of the cpu_partial (an unsigned integer). I didn't get the point of this fix. > Thanks, > zhong jiang > > Signed-off-by: Wengang Wang > > --- > > mm/slub.c | 20 +++++++++++++++++--- > > 1 file changed, 17 insertions(+), 3 deletions(-) > > > > diff --git a/mm/slub.c b/mm/slub.c > > index e3629cd..26539e6 100644 > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -2248,6 +2248,7 @@ static void put_cpu_partial(struct kmem_cache *s, struct page *page, int drain) > > { > > #ifdef CONFIG_SLUB_CPU_PARTIAL > > struct page *oldpage; > > + unsigned long tid; > > int pages; > > int pobjects; > > > > @@ -2255,8 +2256,12 @@ static void put_cpu_partial(struct kmem_cache *s, struct page *page, int drain) > > do { > > pages = 0; > > pobjects = 0; > > - oldpage = this_cpu_read(s->cpu_slab->partial); > > > > + tid = this_cpu_read(s->cpu_slab->tid); > > + /* read tid before reading oldpage */ > > + barrier(); > > + > > + oldpage = this_cpu_read(s->cpu_slab->partial); > > if (oldpage) { > > pobjects = oldpage->pobjects; > > pages = oldpage->pages; > > @@ -2283,8 +2288,17 @@ static void put_cpu_partial(struct kmem_cache *s, struct page *page, int drain) > > page->pobjects = pobjects; > > page->next = oldpage; > > > > - } while (this_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) > > - != oldpage); > > + /* we dont' change tid, but want to make sure it didn't change > > + * in between. We don't really hope alloc/free not happen on > > + * this CPU, but don't want the first slab be removed from and > > + * then re-added as head to this partial list. If that case > > + * happened, pobjects may read 0xdead0000 when this slab is just > > + * removed from kmem_cache_node by other CPU setting lru.prev > > + * to LIST_POISON2. > > + */ > > + } while (this_cpu_cmpxchg_double(s->cpu_slab->partial, s->cpu_slab->tid, > > + oldpage, tid, page, tid) == 0); > > + > > if (unlikely(!s->cpu_partial)) { > > unsigned long flags; > > > >