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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1B77CFB424 for ; Sun, 6 Oct 2024 13:01:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B03FD6B0284; Sun, 6 Oct 2024 09:01:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A8CF26B0285; Sun, 6 Oct 2024 09:01:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 906B76B0286; Sun, 6 Oct 2024 09:01:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6FB036B0284 for ; Sun, 6 Oct 2024 09:01:14 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C6DFA1C6D0E for ; Sun, 6 Oct 2024 13:01:13 +0000 (UTC) X-FDA: 82643188026.18.E75C043 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf28.hostedemail.com (Postfix) with ESMTP id E9151C0028 for ; Sun, 6 Oct 2024 13:01:11 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VZxCdz3y; spf=pass (imf28.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728219604; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YsbmwdYmbEYG1d12bOYA50NdOqIUXNRGrBdplvigFAQ=; b=yyi5roDZPhAHtJQ+o3ADwjorztbISTPswtFprYq9me8WsG3CEKaPZ/HIC1FVjvjN+mKT2e pWbq0/k1GO3UP3peRQcP0ksLlOQq0LrtmynR7aIwR5Kd5RwPShzWwCJ2/CMNOYJxu53nCO C4d6lUGdKRazeCRnTXXfmmgcCdRCJQ0= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VZxCdz3y; spf=pass (imf28.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728219604; a=rsa-sha256; cv=none; b=a9RepssHZglI27Rlp0g1A7PZdxUvlyfu7hdwS9WNuGh1PeG8yW6oz618lGc8yVf4HePHkO PtV69LsIwIlF2h53wFWhO37TObx15pd87RREG7pi7iZt22YufC31YlnQ2EOFe1kw1kyGiE fqU6cERxqD2rbi2KrMJKI4AgW3SFGB0= Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-5398a26b64fso3394722e87.3 for ; Sun, 06 Oct 2024 06:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728219670; x=1728824470; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=YsbmwdYmbEYG1d12bOYA50NdOqIUXNRGrBdplvigFAQ=; b=VZxCdz3y+sw4R+lZB2TYJIV0/VlW6LqQZ0cH8xGLkxM7EvHwG84C5uI25FdVtGpxhp dTbQbI3Bv7N159N5LZ47MwPX3HQa16DAgN7UwBOUjcLyAI3Lpe1KFfE9FbimjkLIarWZ bDJUBmaDSeQFX7fAaZ3JfCWzW7uwzn+EV7tIDE+DYFAoY5BD7X9LAxN5aMYTbQbaQwqQ CYuYGgR/VMWydqCOyuPp91UV0eYt+aCFgQn80nJN2K4knHVb3lhJtNrihnHFTEo5ZpdL b8r+2IyASY26OWVedp5VP1+rCVvERcDdkkiDaAozl7ssBrScHNTCJSwMWVMy+Y6UZ/O2 5QrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728219670; x=1728824470; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YsbmwdYmbEYG1d12bOYA50NdOqIUXNRGrBdplvigFAQ=; b=wQSukTF7P4Yqecbga0BaabeS6iXjY1giVQVMPBtoD1MAuFtCx8qItfG98gye5/FosM ljJ0Wor5IAOkJrEYcOrhb1KnBw0Qq8xVVIHwkPQ0uh5qYzoJfC4tzI5JQXkhigTK+9Vc DlpbbqfIzepwVlCCehTuiFtR+AiFUcZ5LjsDgKz44xnD6aCovcXhKgnDmfczH3HSJPew jvuU5yoSJfqZIoxL/bUigaZfMOh+s9Is1sP3o5zaBCwaSvLhkUoCnfAVrQNL9ACsPPMX Lf+ZqUGC1LoW/QuxJVSz42NcKh162FPbnK/EzG5QVN86MjJPnSAhV/QIBeEtF4ySusqT bcgw== X-Forwarded-Encrypted: i=1; AJvYcCWm18jTZoB+zhNelcCCPsZ/XI76X6suYnxOUF9V3tmoVgFWFA0gCrVD7xp1NFsMcI55wP+Ppn4o+w==@kvack.org X-Gm-Message-State: AOJu0Yz+EySWLYrH9+zgfAkEs3p4HFggR0/caE6BHP2+fJG344H4mmyn d48p5h5b5tfV962YmKeT0nob2v6VrsLUkTamr9Y4SKjc6RGgvUOi74w35VD85TiZxbzVefLDgSQ fthjYXEmVrML8efBPHjy1CHcAuos= X-Google-Smtp-Source: AGHT+IGsR/AY7mIlLnkAKMntgnao9Z+Uo6jDWTVDiCuKICpSLi1+jzFVyrEXm9euaeI4qtsCpEWjIVrC3YlgwHezfkM= X-Received: by 2002:a05:6512:2810:b0:533:43e2:6ac4 with SMTP id 2adb3069b0e04-539ab9f0ccdmr3561856e87.49.1728219669664; Sun, 06 Oct 2024 06:01:09 -0700 (PDT) MIME-Version: 1.0 References: <20241006044755.79634-1-yuan.gao@ucloud.cn> In-Reply-To: <20241006044755.79634-1-yuan.gao@ucloud.cn> From: Hyeonggon Yoo <42.hyeyoo@gmail.com> Date: Sun, 6 Oct 2024 22:00:57 +0900 Message-ID: Subject: =?UTF-8?Q?Re=3A_=5BPATCH=5D_mm=2Fslub=3A_Avoid_list_corruption_when_remo?= =?UTF-8?Q?ving_a_slab_from_the_full_list=C2=A0_=C2=A0?= To: "yuan.gao" Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, vbabka@suse.cz, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: E9151C0028 X-Stat-Signature: 6m5ra44mx1kacy44qaccwaipzuyy36o8 X-HE-Tag: 1728219671-280210 X-HE-Meta: U2FsdGVkX1/P3V9Uya3ZMGgZrnWsU1amixO2Mnr5rBXxmEijdoN++Ec6Vbvo1Gn3CqklTu1R0vIkwtpj1W5ymli7hOj99IqVVp07bPWXANklTm6+ihqAvVssC4pQKCKxikJ6q77B9DPrucOAXUuUXJTZk8DDoiCdNdYHBc2pX6xYZeRO8xFaXWgFsFeJABPvSNC9hr7y1B0iE19/vu6y/o7sGy4STRWzPe/C3GXbh+Zb7hxqGbdSNqSD+M/0pAyYGly6GMdxFrpfwViIoWmnXK+H8z/xWuZf0PHv42Bus9is1y0GJFuSlwufwo/Z1sDoP/EJPDZ2GhM91c+zKQ7Zj5oTpitkD+kR5bLMQ+MirwLv/L4g43c/CWHj85en8vRt6ETbWIQWb5i3L36F1H5Hs6b/WL1gNAztYcJC+eb5rS/xmRwR0t97muhdB531SaMfvtW7+3E1gf4qNa7aiSsxdpfUIPzAbhMh99QCHdjQ5ce5HfIawZpth9n1bBi2aSg4evmtuiBCTSv0e5Cc1pOUGYSCxpkf4hxqQETk1wd+Pm9vwpwhE2TftvC+7UAeSRsa8atKU7VTL7VqrCYA6GpYsWsDciWEGXuQRwrsHbYZTaXntz6F0KkW4zVH+kbldHUoIHBkkvDoTzLYzlxUmgIqT8nAULuwluv86bCzc8uVstqkUSa2mO49QKnmwmeUkJtQt0yGaM0MaCoi8F0OxWxbw/qKrBYyXqoz7hdnQ6xVIgvYUGU1BxzoR79obzJeRl2Mm3XSW0qoW34dTMxMmn1b1OAnHegDLQb1/KAHS8rZMdoZuDGiyTDWosGRr20VUGk57zzoYhPdts6DN1gT1i6k5eqTK4AS12aY2CJwsq5gVzuECueAOK1kteFvejOYbRwmvh5ao7V7lO75YnZSe4jNbUvPQ21K007J62paRHvbqeBDrqGIWqpprARSWvHDaTE97mJGJ2kDzPu7F0Dhzb0 gYUFhtf9 rGv/5lupJ8aRtJfqujUfaaFxi3lZ3ZOeLlwKlLLpiWgdeyo2Aw4IJ9qf/8C2qJTGMhxut5brr13vili6f8rF6BmJK7h6zdv1qP+Odfzmq9ZQTZX1ClqFR1ZMd5ZtVE6xd7QRAIiVFI/rFvl9jA2jfPiKa/lctcH7NWNySXX53Nlm9ywO0JH+GNuZ/kpMU4xG1OhScw4gbQiKETNG4X+v9TTwbeesLVocmit+4itg/cOwrr/2RYvzBwnSZR58yzZPHSSzd++BD+WNuxFsA/Nej6EraAzILQ62erkzDjtGEZYis6TlGGRIr4uUcU/OFGkWuydJavRwqxqV6jFrB9rGrlBPEh+IX+8W6BX93oJyzNCKuf9/mU3LOaiEfRdPt4GddGrTYyIpGm1D2XfeDpnP0xPCdzA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001010, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sun, Oct 6, 2024 at 1:48=E2=80=AFPM yuan.gao wrote: > > Boot with slub_debug=3DUFPZ. > > If allocated object failed in alloc_consistency_checks, all objects of > the slab will be marked as used, and then the slab will be removed from > the partial list. > > When an object belonging to the slab got freed later, the remove_full() > function is called. Because the slab is neither on the partial list nor > on the full list, it eventually lead to a list corruption. Good catch! Thanks for investigating the cause and fixing it. > So we need to add the slab to full list in this case. While I believe that behavior is not intended by alloc_debug_processing(), I can't think of a better fix here without adding some complexity. The approach looks fine to me. > --- > mm/slub.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/slub.c b/mm/slub.c > index 21f71cb6cc06..a99522b9efc0 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -2746,6 +2746,8 @@ static void *alloc_single_from_partial(struct kmem_= cache *s, > > if (!alloc_debug_processing(s, slab, object, orig_size)) { > remove_partial(n, slab); > + if (slab->inuse =3D=3D slab->objects) > + add_full(s, n, slab); Shouldn't this be (folio_test_slab(slab_folio(slab))) instead of (slab->inuse =3D=3D slab->objects)? Oh wait. the kernel also should not call remove_partial() for non-slab foli= os. So I think it should be: if (!alloc_debug_processing(s, slab, object, orig_size)) { if (folio_test_slab(slab_folio(slab))) { remove_partial(n, slab); add_full(s, n, slab); } } By the way, SLUB always messes with struct page fields even when it is not a slab, and I think SLUB should avoid modifying those fields before confirming it is a slab. (specifically, calling alloc_debug_processing() before updating ->freelist, ->inuse fields) That is beyond the scope of this patch, but do you want to address it in the next version of your patch series? Cheers, Hyeonggon