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 9CE61C04FFE for ; Thu, 9 May 2024 02:27:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2260D6B0085; Wed, 8 May 2024 22:27:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D5A46B0089; Wed, 8 May 2024 22:27:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C5226B008A; Wed, 8 May 2024 22:27:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E36AD6B0085 for ; Wed, 8 May 2024 22:27:02 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 68FB6A0188 for ; Thu, 9 May 2024 02:27:02 +0000 (UTC) X-FDA: 82097269884.07.8D5554E Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by imf30.hostedemail.com (Postfix) with ESMTP id AB29980002 for ; Thu, 9 May 2024 02:27:00 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=j71IAaRA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715221620; 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=0/IwJci/M1L70wMnZgMt9ntgAysQtlzkD6PVneKqaMA=; b=Q9KnPQj2anEk3H52DRylq30Tjy2BhoxmDYAFlUqofXlowiCKQ/m7eAAex3+vL19UHIArqz aDPoz8cPyMOJpkINFdTVqrIuZYoq1DJtmJF8/a7LGsnL6VyOwvqDUSAxbY5fu1pjvRw6MI +Jm0D0My8B4REOBEfcuuI0lLprb0GAw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715221620; a=rsa-sha256; cv=none; b=ZriQi1uwhUQYmermNFCZRjpAvDdHs0E5ZvZ1azAK1DxvFPJhqYjrBz5YGZkEW/A80yrYT+ 2ZYpVqph5XSlPAQBHiAFHhovly2q+rfWvACUbpTftylJ9hgLiUWEcqpjms7+gR1ZhQO5zv Sb6PkgWCHkgiI/E3ugT27g+T6t6XBnc= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=j71IAaRA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=21cnbao@gmail.com Received: by mail-vs1-f52.google.com with SMTP id ada2fe7eead31-47eee2af758so766486137.1 for ; Wed, 08 May 2024 19:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715221620; x=1715826420; 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=0/IwJci/M1L70wMnZgMt9ntgAysQtlzkD6PVneKqaMA=; b=j71IAaRAE/JMliOgKzeFAeQTdJZeR8yF2Gk19NrLwEjx1uqEROf1GQsXNXEz92K1sX 7I536OSJ34o6kVREq8wYfPIJviSxgeargFfSPI0orgh27s4m79HvK9rTLtCuxRp8XiQu dYkRI9aWHvX/VxKYUNUDK3Yiq9rOtQEW1rAKAxw5Bj/OcfsPX9WKO33dPhYONhTX9uQB SqJAzT6zFtykZ3ANsxEyR2l+K/11iHdGuPWH8a5MZtIrxbFUXGpxSJrhKXUPvOxTgFKd XFDh5jPJ78vEgrSNeXr9/YbNq5UIpHAskMpjyxp4ib4LeX2tNY/LHSyu1aZxUESGzbHb zaQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715221620; x=1715826420; 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=0/IwJci/M1L70wMnZgMt9ntgAysQtlzkD6PVneKqaMA=; b=vh/d5VZMwwpSI/Inf4+xjuf+bk9aJHUwGxZa94XvGOWeaswGdU8lVtmFiLVp0KzBSQ oKvwEtT7oTPubNN/2b0itWg2UbuNX6YOE9pZIHNXsqBb2ALr9jync/rrauF0oGR9YQV3 yL6Ppic80FWC0zdetwzJCCI5gpZOTMwVF/fQDzK1CxLpwU+a1ysD4WmdygB34bVjk3t3 oq0724uXnc+VlpNgaIufZW84fgJXV6BB2X/nJcZX3LPqWl//ZG4jzUPjj++qfwDEEfBl Zc7wrpIPNlhdBkxjeBRDbsMu0ZcEgrjXRoEhZIF9MamCVjIIyLp2OHrwSZLI7DvV3Ktf qbSA== X-Forwarded-Encrypted: i=1; AJvYcCURN911bxjeVMFQ9e5JpoTicbVw/T/839LTOxCNu16R8NS9eeGgwi/7akWjVuZDMDSg+E7RhnbYQqpGpdRv1IFf29k= X-Gm-Message-State: AOJu0YyImAftgbCP3t5++h0GjA1CoFo38ktCcgnFJoC2cCGVI0Jq1vQQ axynCg6M66LdlrdKXxuKr6VLuEUS09/OKsECn0pQoTnK2FwrzG4oofaglzedzec7zwojvkRRwQr bayx3q/d8MyuNimKAMMNVb54RG40= X-Google-Smtp-Source: AGHT+IH+r1spgSsCipDIm7+FpmeR1lk49mezHcRkGEJ+f7hMQE4y8KEZHFZJKNa6mgPzazvCWogF2p+vjW2sq64SBJw= X-Received: by 2002:a05:6102:508e:b0:47b:b044:4ba3 with SMTP id ada2fe7eead31-47fb6c4184dmr1323440137.12.1715221619746; Wed, 08 May 2024 19:26:59 -0700 (PDT) MIME-Version: 1.0 References: <20240508125808.28882-1-hailong.liu@oppo.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Thu, 9 May 2024 14:26:48 +1200 Message-ID: Subject: Re: [RFC PATCH] mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL To: hailong.liu@oppo.com, asily.averin@linux.dev, Michal Hocko Cc: akpm@linux-foundation.org, urezki@gmail.com, hch@infradead.org, lstoakes@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, xiang@kernel.org, chao@kernel.org, Oven Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: AB29980002 X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: cj664fwjfx8rm94sc8d5s6gne7f77cus X-HE-Tag: 1715221620-602813 X-HE-Meta: U2FsdGVkX1/pVSMCPT//105vo43mistXnnvP5F+iaAeqliWJPsPdzQIU/hoVypvL+GvWUeexo/yErnBr2HK1pyZemMqVN5+jVyrgL+r+uA5wdAT+Qmy0pte+lBCNlxbLomf8wVwQK+g/UrfGGhnY769vGfkfy92O1zbQOLg/7kcEjsGhVTStRMh2ZRZyFxBr6xdQMfdm4xXlkQRql2ovI3kYQdmvpGBoC5K9sZ6oNKEyqqFACe3L191AwZgopl9Qct8G61Jy8tGTUbfIOBwkD7Uc65/8wfR/o9VPAXGqLovugAIbvEK1bfH0oHyEApRkAWAOqhVC6Ks3YxW+8CfXB+tOxBLM/2E/2reJ1foGb8Hgg+qAkPojKUqewCyczqZ5MCd3ellXUEWlnEy4suKUxCqVGQbYSX/DomYMgIN5n33/QLnLKR33QjGiojvNa8jqusXS3xHlKRshHCWydTqKrJRYLACestDbUdzh4NxaFrNAX4VIb/ITq5xzPC9ECHKfeNCv1YLlwOuYxtRPY7ozGY80bBwpwBmNo/l5Xa5YSn8t8Kty1U3YXYuF+CwMKzBlNq9wWmUgCwNQ3CE9I7kdMxvxrnA9xL+1ztrIQPxRJrdbSmd35Xl5rcej3jccEkWSOoMgeoMbScpvN6ZqPHhyO3tscINP9LlkFoIBsdkgJOJfoc1mC8Tbdnl6uZifHFVOh0bbnVyFm8FDYScO8ODrIpZrxNxMet21xbaLg95j9E+0NORucZZJULABOXc9kcor9FRlhFoC8tuCyvhJ56BTsmdDMAKPKdYisTtlyT2EwrF9sD08AzNxl7I9Dd69Om5kzt3nO91g2FhV0rSdLmCeZ48F076VqygZEAPNI+a2ZXRY89oLFgaWfHX85ElLkreyk8PIZOyzYkCjNpk/9ZmbA8zE8Q0fNmOgFfredqVPf0yo0rZ03Ee+qmsDX/fvMj+WOCKrVaE8DI5DoyYW37f gSygmlMW Db7unCkOhYTXrFX2jzIc2mTAh0QolAcenMwl05sXpFAZirrcTnwuUltxmjzUa1n/TLggL4PMasNK07gQb4srdWefvyduYVh/9454hRLhGGT30nwNEIeBXaGOcIKlRLwFyXKVnjHImygtHbBA+W15nzQH45EGpcfLfmETw3aBrQ+D1oNeTryEaDg1YV2sA5Igm+VHFp/6n1cju9SmILtvbWOEGjKczErOPeg7em9pFhD6EYTgdAxIITHFB/sar0W2WJQ3jNYo907LgwJD6DbGHNF641Hm9QRdU4gjsVy7HcKaJKp+LUeQrwtROKJwm5aV5ks2YaF869NtkYHT0IVm3uNuiP6mxQUHNdGPOX6A9EH32mf880+rBSqU5mVTWh0gBEMhD4LSDK0v80MSyqLbcmmdOEv+8E9ebAdT9qqIsCdR4HPhjNiHRWI/g9TU+vZDkoS1Bb7naf5G4KhBJgNcc7srYxe8zAR3O/4tMS9CJlT2+4/4= 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: List-Subscribe: List-Unsubscribe: On Thu, May 9, 2024 at 2:20=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrote= : > > On Thu, May 9, 2024 at 12:58=E2=80=AFAM wrote: > > > > From: "Hailong.Liu" > > > > Commit a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc") > > includes support for __GFP_NOFAIL, but it presents a conflict with > > commit dd544141b9eb ("vmalloc: back off when the current task is > > OOM-killed"). A possible scenario is as belows: > > > > process-a > > kvcalloc(n, m, GFP_KERNEL | __GFP_NOFAIL) > > __vmalloc_node_range() > > __vmalloc_area_node() > > vm_area_alloc_pages() > > --> oom-killer send SIGKILL to process-a > > if (fatal_signal_pending(current)) break; > > --> return NULL; > > > > to fix this, do not check fatal_signal_pending() in vm_area_alloc_pages= () > > if __GFP_NOFAIL set. > > > > Reported-by: Oven > > Signed-off-by: Hailong.Liu > > --- > > mm/vmalloc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index 6641be0ca80b..2f359d08bf8d 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -3560,7 +3560,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid, > > > > /* High-order pages or fallback path if "bulk" fails. */ > > while (nr_allocated < nr_pages) { > > - if (fatal_signal_pending(current)) > > + if (!(gfp & __GFP_NOFAIL) && fatal_signal_pending(curre= nt)) > > break; > > why not !nofail ? > > This seems a correct fix, but it undermines the assumption made in > commit dd544141b9eb > ("vmalloc: back off when the current task is OOM-killed") > > " > This may trigger some hidden problems, when caller does not handle > vmalloc failures, or when rollaback after failed vmalloc calls own > vmallocs inside. However all of these scenarios are incorrect: vmall= oc > does not guarantee successful allocation, it has never been called wi= th > __GFP_NOFAIL and threfore either should not be used for any rollbacks= or > should handle such errors correctly and not lead to critical failures= . > " > > If a significant kvmalloc operation is performed with the NOFAIL flag, it= risks > reverting the fix intended to address the OOM-killer issue in commit > dd544141b9eb. > Should we indeed permit the NOFAIL flag for large kvmalloc allocations? + Vasily, Michal. > > > > > if (nid =3D=3D NUMA_NO_NODE) > > --- > > This issue occurred during OPLUS KASAN test. Below is part of the log > > > > -> send signal > > [65731.222840] [ T1308] oom-kill:constraint=3DCONSTRAINT_NONE,nodemask= =3D(null),cpuset=3D/,mems_allowed=3D0,global_oom,task_memcg=3D/apps/uid_101= 98,task=3Dgs.intelligence,pid=3D32454,uid=3D10198 > > > > [65731.259685] [T32454] Call trace: > > [65731.259698] [T32454] dump_backtrace+0xf4/0x118 > > [65731.259734] [T32454] show_stack+0x18/0x24 > > [65731.259756] [T32454] dump_stack_lvl+0x60/0x7c > > [65731.259781] [T32454] dump_stack+0x18/0x38 > > [65731.259800] [T32454] mrdump_common_die+0x250/0x39c [mrdump] > > [65731.259936] [T32454] ipanic_die+0x20/0x34 [mrdump] > > [65731.260019] [T32454] atomic_notifier_call_chain+0xb4/0xfc > > [65731.260047] [T32454] notify_die+0x114/0x198 > > [65731.260073] [T32454] die+0xf4/0x5b4 > > [65731.260098] [T32454] die_kernel_fault+0x80/0x98 > > [65731.260124] [T32454] __do_kernel_fault+0x160/0x2a8 > > [65731.260146] [T32454] do_bad_area+0x68/0x148 > > [65731.260174] [T32454] do_mem_abort+0x151c/0x1b34 > > [65731.260204] [T32454] el1_abort+0x3c/0x5c > > [65731.260227] [T32454] el1h_64_sync_handler+0x54/0x90 > > [65731.260248] [T32454] el1h_64_sync+0x68/0x6c > > [65731.260269] [T32454] z_erofs_decompress_queue+0x7f0/0x2258 > > --> be->decompressed_pages =3D kvcalloc(be->nr_pages, sizeof(struct pag= e *), GFP_KERNEL | __GFP_NOFAIL); > > kernel panic by NULL pointer dereference. > > erofs assume kvmalloc with __GFP_NOFAIL never return NULL. > > > > [65731.260293] [T32454] z_erofs_runqueue+0xf30/0x104c > > [65731.260314] [T32454] z_erofs_readahead+0x4f0/0x968 > > [65731.260339] [T32454] read_pages+0x170/0xadc > > [65731.260364] [T32454] page_cache_ra_unbounded+0x874/0xf30 > > [65731.260388] [T32454] page_cache_ra_order+0x24c/0x714 > > [65731.260411] [T32454] filemap_fault+0xbf0/0x1a74 > > [65731.260437] [T32454] __do_fault+0xd0/0x33c > > [65731.260462] [T32454] handle_mm_fault+0xf74/0x3fe0 > > [65731.260486] [T32454] do_mem_abort+0x54c/0x1b34 > > [65731.260509] [T32454] el0_da+0x44/0x94 > > [65731.260531] [T32454] el0t_64_sync_handler+0x98/0xb4 > > [65731.260553] [T32454] el0t_64_sync+0x198/0x19c > > > > -- > > 2.34.1 > > Thanks > Barry