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 7C7C6C04FFE for ; Thu, 9 May 2024 02:30:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0EE886B008A; Wed, 8 May 2024 22:30:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 09F006B008C; Wed, 8 May 2024 22:30:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E80D36B0092; Wed, 8 May 2024 22:30:25 -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 C8DF56B008A for ; Wed, 8 May 2024 22:30:25 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 79C7A1C189A for ; Thu, 9 May 2024 02:30:25 +0000 (UTC) X-FDA: 82097278410.26.8E5F491 Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by imf30.hostedemail.com (Postfix) with ESMTP id B933780007 for ; Thu, 9 May 2024 02:30:23 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ov+oysDK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.48 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=1715221823; 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=8f3ST9sz5MmD3ot+TRhiheKYqbtjUEokeBRH5FJqtOQ=; b=GO7P3BBB0fI8W4l6BRDqrlnWt3HiqcGmDTvZLlw7vSDu5CXyMkfH6d4Lz4PAmxtwr5x0gH iUvRMTAFhfaYGQxFYf/iYuiMggGiNxpR5CzOtVzbQhpdUWQkSCrVVsQoD8UHaBZBU8p0cf OobbjXvPc2H9gxguiijpXOgji5DzTpk= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ov+oysDK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715221823; a=rsa-sha256; cv=none; b=Nd5yinRDTeZwAdNdRTf5IYV3/t0zV8Ab1k6eYc1DnuUo2KUziNkj5EgRRCA0ux1SBskY5P JRNVf0Xx8QFwxNuGZJ1eipdJRUDgMqc72cqGQrcn5H+19PuyWMohTgisKIdenhy3VHDtLq KGWDK1Wfiq5h9aYrlwzNa0wV0vp77+E= Received: by mail-vs1-f48.google.com with SMTP id ada2fe7eead31-47eee2a2a87so128425137.0 for ; Wed, 08 May 2024 19:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715221823; x=1715826623; 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=8f3ST9sz5MmD3ot+TRhiheKYqbtjUEokeBRH5FJqtOQ=; b=Ov+oysDKuqbLvQEQ+Ye2fLURvWOKIlTRLIXMrcg8VhnthprerKhYR44jzc2KL6blE9 OzFBweAGGWciOyJLF859UDLuJRoORCUum3MT1FBDLwT8rTZTxkgIAJQ+kg/AKWdjeFgv pEtP0G+VjuSbeCHSg2LNDnHzWYRMvtAk09Pg7StEmD/Bnoo6oO0vRLEcfjjpNai7FL1l 4RQmtQgTnQRUUIyDfjWe7+1syVhL16YiyVn+xcykBYwUOoXuU0LfW6QXSrWCwRzvHQlC nFGQZ9J1j32ytq6x1tL5DkV0Kp+W0FhYvjj7y1IdM4kQv3JpG/bkL13pnVXdj2iRYssw WnMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715221823; x=1715826623; 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=8f3ST9sz5MmD3ot+TRhiheKYqbtjUEokeBRH5FJqtOQ=; b=CUfSZO7SJReNR6byDhJHrCwX6gRdv3oqlSd5eSKywClhrH4tmPGp7XTNtOhpJjA1QE bDUvVI8qnP8sryQNXSp2KzKqWdGIa289CXkjYDoDvN00Et3NBcejX3/nWtXc6t0JXOJn FnqXdlWhxBFOkN7hSNrXHsAwPriSscMO3S3pOvujn7CztWdko8h4Dk7mYiEWUO5hebqH m+zPRLnAH6sozaU/OL3KtUvbV389PEpXvfp7zt3DS2AIiiouTF9QEBpQjTOwUqauBnQV fkyRucO7uXtz4iu4cmrBFGOHtSz8nzCzmT4OZlrDc/1w4De9dyh4AHfSS9LLXtLKWmkP AozQ== X-Forwarded-Encrypted: i=1; AJvYcCVAUlrKo0aHPBVo351Qa7mB+dCG40O7yRGkmVDhQWRqX+6CV04zaCOzTMxNiwFhpn93DhlmQJu7L1nkkZbd+a7qmPg= X-Gm-Message-State: AOJu0YytGC68lTxX2sT/DVgG6MQkXOPJIMDejLOJVT14ysmQwtGo80n4 dgokcwO20iH1Y8cYKSVEEQcToWDN23KK2vquC4rNA+Q9TEIXdVW3g+vdYkqsZrJunC4fx6HND68 SCBZuBfASkjLNqxSOoHWLi7ukvdU= X-Google-Smtp-Source: AGHT+IHrVCSOY/tgNQtQg4/q8JJRFNZ5PXD3ffeHGcX5tUkSULJUHdOJ7WF7p+y4uRYQ290+hKjZLR59Tas/7hb9RU4= X-Received: by 2002:a67:f405:0:b0:47c:1251:cf25 with SMTP id ada2fe7eead31-47f3c2dff19mr4302499137.12.1715221822798; Wed, 08 May 2024 19:30:22 -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:30:11 +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, Michal Hocko , vasily.averin@linux.dev 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-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: B933780007 X-Stat-Signature: ka8scbujp7y44zs3ui3bfpe11gzyxjem X-HE-Tag: 1715221823-445319 X-HE-Meta: U2FsdGVkX18Q03hQTs0yGeBLydNBmDLrIpHs/tbS9oLJ0U4XOrKF9nT/1HAprPZkDv9qY/7PNGYlQvgnUJG+Gu/B4GDvw8ouvXCZqfvlersRQ/9sKHImbaHG1MgaYkGwRk+Fo0UWdwJ2TdvNx16jxdfk5Gl5uP2y15Lpg4sdHQRQJnkd9KKdxd7Bk/pEZi2/m2fT8zpQzEC2CkXuh4kdBGLwGV+Ncprn4Q+5J9GO7q5sauwHOjVTQQWT+AnigEonUTAP9Dc6sQyRt0wr31ZhdIvdlmUuf9ppDzbdaLuIJ/aVVePbyHPFNkdVt8m4jauKrIhce1aKD74BY7FLOpne579LoHFo3WZjHjkkp4TOTfpYWUut44cLzW6R+Q4StjZQ8fmwUKBsCnkKj0mxeTJV8Z1TkbhGQfX5OwCF6pBJ+KuaEVF4tWNVcGL+jb1C1WXYmvP8j80CNuf0CkSYCk9Py8Ab7nNN3/lAxzIxHvCDABURtif+3Dk12Zx/y5JcmHopaEGHpXm3LVXs7mLiu8GLpIyW6w4zHMT727A8t/3puvr5NIsBphcSrqxV82CqiBg/GFZ0YVIEMM3WMQFkzFAbHXBEPz7SybhTbpeGbT9m8hyfAjjVd0UBrT7+UefzuRf4yrebMEGu3PTsz10LPUq1x+A7jRrxLrbW3Zucvx6n28SGdYiAHJacnqw9Se6uFALD61ju9kOVfoCq+LLMcvalOG3uD+b8st6LY4nTnyjtLp6T6lwFYagQTQJOqziUhEre6+J/7Pth8bzaJZb4o/gJG2QbwZAdFm1syuMMP6EkO/MTp+sCRyZR+23cr1JoxmR6IanELs+oEdK9mB2N10WqEcE7cY2dFsGEg0oePi0tQRNPV2rYkxMXoG+j/rS6NjYRr1Sihbkxu/uk+1Eb3cs+xvy1gKI0OG0/TOcgkgRJpQk9sGkeijUHjO6x/QhM1rWyouivoyJoHpqEtE4q27C moocWidn 9iKq2zF3cKKjpB1iM7d3L5aFeIDXzXrIBJnavD+6PB6CdcC1cFNZl+ijPsJmIHSXOW1kt5dgIY3zo3pWXU2YdQKFMBcrfcQflXPFwQ591eFdKdjs64sQKvnHtzLn0Zx0GF8h11wFYmQwzbHA6DpygXlqb4qkUgkBtaI7VK6mWkRTWRbIBcdgqldUY7MtgsAjROPflD8wsMnfCk28Qc5tsWFR5Jl1fxmkTutIW+RCtWzkNfyYZb6tlPkut0Z+diQU6+vbuMmWpPNDBKXF7yHc1HcA/L6oqoIk2AQV+Q7dkgXHkZ0uczgWiX4hxiCMdLSS1OraHIoO4w+1SYwrE2OhbcKE4e6rLS9h16/QigXzmcvVxH71I83NV7BoH6jmJpReYuad5BqLWS1dTJbgFDVSOzFka11KzpWJsbuKUQdkHJT2jU9TmlbKAehq9PI7Zc9l6U6/kI6d5jtZDWW7C4kr+Xf5Y8OBtr9zND6BDZdT2xd4aeTc= 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:26=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrote= : > > On Thu, May 9, 2024 at 2:20=E2=80=AFPM Barry Song <21cnbao@gmail.com> wro= te: > > > > 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_pag= es() > > > 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(cur= rent)) > > > 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: vma= lloc > > does not guarantee successful allocation, it has never been called = with > > __GFP_NOFAIL and threfore either should not be used for any rollbac= ks or > > should handle such errors correctly and not lead to critical failur= es. > > " > > > > 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. Sorry for my oversight. Fixed the email of Vasily. > > > > > > > > > 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,nodemas= k=3D(null),cpuset=3D/,mems_allowed=3D0,global_oom,task_memcg=3D/apps/uid_10= 198,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 p= age *), 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