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 0907BC04FFE for ; Thu, 9 May 2024 02:20:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2246F6B0082; Wed, 8 May 2024 22:20:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D4A86B0083; Wed, 8 May 2024 22:20:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09CCC6B0085; Wed, 8 May 2024 22:20:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id DDCD36B0082 for ; Wed, 8 May 2024 22:20:18 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2AA681411FC for ; Thu, 9 May 2024 02:20:18 +0000 (UTC) X-FDA: 82097252916.06.AE0898E Received: from mail-vk1-f177.google.com (mail-vk1-f177.google.com [209.85.221.177]) by imf03.hostedemail.com (Postfix) with ESMTP id 601F720007 for ; Thu, 9 May 2024 02:20:15 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LXeojE5e; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.177 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=1715221215; 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=16ufiicew0m3mWhNX+CcZ/zKAVzfqZM1+hj2NNR8WOI=; b=l1dEGh+8frXZTqTMut+2TgKKbcFzw/lwV0R4R7aeGMerx5JuN+LdAaF+I2ZY0qlNASAvJ6 CWdeDZWctDDb0HSR+VKFJifHkOOCj+T6/R+Bkwpv5603pYMGRClXPzvQOp/Wa95/5stknO 3m3RvrELaiofAb6BWY9sR9NnIJOpIaM= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LXeojE5e; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.177 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715221215; a=rsa-sha256; cv=none; b=l5WI9ePTl8nRI28VRBecZwR7LraiXrvQ3I9J86fWZ2gTBnCNBeKAe3E9GkHIVADUXuZ6vh 2Yq5hY+8cUcRbRL4uiRLrJxQKXnP/GQQZWreR24v3rt63kov2rIZd1P4Z8qpQWKqXI32yY ofkkx4o2tFzD2i34MYcPf9ByXqvgeGg= Received: by mail-vk1-f177.google.com with SMTP id 71dfb90a1353d-4df400d6875so165741e0c.0 for ; Wed, 08 May 2024 19:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715221214; x=1715826014; 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=16ufiicew0m3mWhNX+CcZ/zKAVzfqZM1+hj2NNR8WOI=; b=LXeojE5esBxlthr2elDoTbSD/8CbLCBqQaYDDEYo5GFFTLYh+YpxoWBSLahI/zI3+x WO6UIXLFdHJinUMD1LIo5xxncLxV1Um1k+NubMQt4q1tS2GcARf4VpRi74NZm6bXx/SQ nWO7bNylz0Q14MhVaAbm0QaeTyjd+AreAdW3HfVFWwSzj0f9MCNMt2P6/ZwCh6mudesg orBkrcnPaA6LkGogZY7sLDWe1V4x/0fjStkco/pSOIDM/v5Q8vo/uWJ4GYcuGVrQ+yC5 ekyAbOJid25Lag7zALOZ4n7THfEZPlnyp6GXJz1iSse5bYtQkZYUcbVq0pIgohgNHTJ4 YMdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715221214; x=1715826014; 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=16ufiicew0m3mWhNX+CcZ/zKAVzfqZM1+hj2NNR8WOI=; b=vuVRv6FtmusIO+FRWU0skd/LWuaVblBL3NfrCBvextjqnvGc0yd2tUlV/oP+1HHwKF Inr1VcWbnrjnQ8kN+91kMyztI6rF+Z/FgdetSNUxIwKich9Kkf4Tq/xjLq3lfB9+cOKJ LudVd9GNF6+Kens1NgqxYlV0JUtL7BzOvD9xPx+xPR5bqBPt/VQFYj3i25QRrqB2Cl27 qbBNyUkZrtzCbVo2ZXQ5Ute1NCWbPWz6vsDxIc6yOroUv4E1GenDr4CYa6VB2d09YUWI U3Niz4GqSyOvog0nWxkEyvBfx8vw+0SJlmEpDWuYZ/Szk/7v/AwlfSiT38y+jJ/ZopdY cTOg== X-Forwarded-Encrypted: i=1; AJvYcCX/7NLpVak8isrIe9RxmGXXwXPVDYcW2EVL9hdig5Xb4Io+jpRrJF09WIb3jbcyMY+VwiIJ5WJKdgUDqbei1Yow5fU= X-Gm-Message-State: AOJu0YwemC4XjUsZuayWhrMnloPsv/rjU5++69szrRhQspPdkv1gcuKI hPYoSZbYfpcJb6jy1ZiJuo8RCelcfvwm3LpsYhMGaK78XWsKTqlTiVLFlr4U8pu4nvOMkLC6WyC 6cqxA3PIOwLbl/wz/vaW/SQi2FLU= X-Google-Smtp-Source: AGHT+IFfbbQmOoLrnvLxc0mIPwN7/ziRbLsk9SuYfrgRc1ypExGC2qC3Fn3TrpGCMdsA6LWVE1oXHUbBvhSCk0uloAo= X-Received: by 2002:a05:6122:25fc:b0:4df:7ba8:5c73 with SMTP id 71dfb90a1353d-4df7ba86309mr623903e0c.14.1715221214350; Wed, 08 May 2024 19:20:14 -0700 (PDT) MIME-Version: 1.0 References: <20240508125808.28882-1-hailong.liu@oppo.com> In-Reply-To: <20240508125808.28882-1-hailong.liu@oppo.com> From: Barry Song <21cnbao@gmail.com> Date: Thu, 9 May 2024 14:20:03 +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 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-Stat-Signature: n1z9g1mzj58ihzcxp6auoxnkmmjs99rm X-Rspamd-Queue-Id: 601F720007 X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1715221215-377807 X-HE-Meta: U2FsdGVkX19DGGmVhESZ3RT9et2sD8C9nOzEEm88prd4pfKl4FHLVopqXC+x/5d57/EuRt9r7CSetnJs36XxjTl+TaQsE1PltDRrtG/+Kc08zDh81EutXAhPOkH6p8zn928QsPfEqj7lfFo4cJEzCIvTPaksvuJHn+aiZpvgEHt9zVA8XHw4IvE6e+K0SLlYdCGYOYQlVA0i8mHSJ8PwQRBOisUDCflGLLaqYTyUavoQBPvcMX40UVUbCyAsuEfk56Dbl01BKQQbWfU9nPNlJTor3Z8NLN3mczqcs4f1IXM8EvlyTLYm+EdFa2O7GrufYOO7QRvT1lP3rsSyiKcr0ETXm0ow89QZomZlIXW08iDAzOJsZ3W/m/9J5QzvZzURNJeWD85BwGlYUNwvCTdGQLIYB7HZsY1pppMuvw+7EibfmGKcGuQIZkgXdVjIwKSGjwl2QziE5TbCrS2xoQtNE4Hkl5x8KpRhHMRQweKO9Q3wqQGV4cBwzfg3Av3GXtTpxua6dsd+BKAEQ1+KCozjH2KeBEDtvQajF2vBQQ1H1beBsNyQb4uaAyl/x9+Au9VGWgBE8P6tdtDd1CmHkn/mzrUmz/rNKWnkrmEtsiHMuJZsHBfzI1SDkd3eTP1uapivEV04A2WOD7+Jsp2BGBKbrrTnVxmVSM5N/Z1R1tI/8kZf8gYK7Z/QZUWbunBt51nl9hjpPKdDMTSsbxp8MToZ4Xr6+oycT8uXuEfPDyExe/fjzcarCQRnxJB4M1X+NdiRgOm1kAhf3jkPbVTSUb3etfTGBvSf8OffbXdY/CvTGzu7En4HshZ2GWWbku0m7EYULMcY4W0wziD04fkmUV1bWY4FpR0hWQqImR2/s/rmB0I8V9R/pqLobJ8/kBR24MC5r5YLzriQzRhHflZQPMLgwm4dkpL13cC+1AbZMJylJvNnD5NHptA3axWxtw1Fa+a9bDNdoocXOOJLjhs4irU nFBfrIbp 2tAr3QZ06h+q/w88eg0PYDTKoWUReRfgMyOinld1TeJBJ2HPGYxaCLB5DTM9tpXIiFVA8kvG1iVGFrZtzRmL+R8x6P/PBUJjNTLkDbgQGWD7b3xnO4XkujUS7Erv3GQ3mjDViOQmfaYk1IDcWizTlCmq0hgdUZi4LIAF6dPBLgdnWn8hljjT7rooGFtUkcWH2Xc9Gn0wPgDU4Wh1VDxkg7UpgYG16w5K8LHy/uplGvLCx87qgCGiBuzDzosYAJXnPqBXsxSvOBtPdImMbwINvltSMs/N4jn2+0seGWzmQs+4Zs5j/k4jbp1Am5Qahxo9pnlObsfWYOdl3ucz+YPZojs9xa6yG8BEkA821rfsXvKhuWkS5Rgl1NsV35UJBwKY4tMPxcfHhW3FikttrmxuvppeQyLcXZE55BDx7maUm402ARqR12LkseVzEHZVTQVPyLM7kS/Lr29ftOJU= 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 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(current= )) > 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: vmalloc does not guarantee successful allocation, it has never been called with __GFP_NOFAIL and threfore either should not be used for any rollbacks o= r should handle such errors correctly and not lead to critical failures. " If a significant kvmalloc operation is performed with the NOFAIL flag, it r= isks reverting the fix intended to address the OOM-killer issue in commit dd544141b9eb. Should we indeed permit the NOFAIL flag for large kvmalloc allocations? > > 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_10198,= 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 page = *), 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