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 CE343C10F1A for ; Thu, 9 May 2024 03:48:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 633086B00A1; Wed, 8 May 2024 23:48:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E32B6B00A3; Wed, 8 May 2024 23:48:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 483A96B00A4; Wed, 8 May 2024 23:48:37 -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 239DD6B00A1 for ; Wed, 8 May 2024 23:48:37 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C493EA0528 for ; Thu, 9 May 2024 03:48:36 +0000 (UTC) X-FDA: 82097475432.16.E6B9B31 Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) by imf27.hostedemail.com (Postfix) with ESMTP id 07FC340005 for ; Thu, 9 May 2024 03:48:34 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="mkJA/r4+"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.171 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=1715226515; 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=L2kbdYwZr/StZkaW0rQUvJuzVp6hX8mt1IHQedQnonc=; b=5CCfHylFBPNvnMzQ2/v+UHhjj1DRb1k8C9OB4DEdqwp7Sp1t+YrOxszH/189mR69rDOrVA jtt0pfo2Am0fmoeMSufiSMvAnfKrMmylkA+lQadrcasB4vgi1mWZplQQFqGm7Ytx4It5G/ +Ai0chp6h5ONBsiPtOsmDPna6AAHoVI= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="mkJA/r4+"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.171 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715226515; a=rsa-sha256; cv=none; b=gBAkhjspv/x9qG+Q7dVbLqKVswyioavmzYKarcCkyp+y8E7VNJSSV7O7XVsbWpnbFNBJs0 yJiTKW564ElYq8dN+IHDi4ij8cYOAKzs3jWFQd8yIbTcylTlw7TxbwTZUgv2g9aTPby9Ss k2ECAWJhZJDEmod6pbldXgunpOgO/ko= Received: by mail-vk1-f171.google.com with SMTP id 71dfb90a1353d-4df1ec345f6so182027e0c.0 for ; Wed, 08 May 2024 20:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715226514; x=1715831314; 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=L2kbdYwZr/StZkaW0rQUvJuzVp6hX8mt1IHQedQnonc=; b=mkJA/r4+B87rkrtYFIqRYgPYqMhcODw20L1I0r3QftiNjn3N2aJTT7H0t41hIQHK5G W6LifBKLWS67YYtDQwO6bBcnk3uVFEs2k8Vyk4M1rAGAl6jjYRXoysmStftnW6gkoK1L TVXde6APwMvLAZF2pazn8MRwbbtB+Q21sQpdZ2LWteAzpS7e7S0835WGQXCZhwb1XwTv TdkP54E13t0X7cjwAi+CTE18+f8hqAEKg2T/iOmIl/uyzAc14RD636zHTEqRKWa6yu/V 0nWh/Mu6UDRnUeu3DTAF77RlxtJ8iKgJQ+hJB5kBmeocp406tHArF09BbtmO/0UNJlRJ W+Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715226514; x=1715831314; 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=L2kbdYwZr/StZkaW0rQUvJuzVp6hX8mt1IHQedQnonc=; b=Ozx5HBNHcIuTyajuIxqDW3f+X1e8uMqXpd8486fK1CQ0VmP0unYKsjEPiB3gLEQ0I8 zlURv7X0YUcGsrai2dzP3HWyNWJkwYgEDI2RFgz2PLW1WqLa3nMS/jhuvycu9Mqrvb09 L9PNUtmHMNMfjq5yXa45xXaRx4j9eLAucOe51TyMEEbW7ijQRwe9AZ7dVOkqBSu1Y222 IUhv2C7x/7uPCY91ezmguiG/qC/ULW2nU8RajvhdixH9TDjJoMFHakivobctwD/H7eZX m5KVqZiJ/hnBulgWGNbc7GZ36Ax8HKsvTxSg0CLYjFlLeF1CfRj2XsoIwc78locRqDPJ mkAw== X-Forwarded-Encrypted: i=1; AJvYcCVgVD+64ti3O6YvLR6Xqn7ZlrIk40K3I8x/2Lzbde0zwNVmhPqDkYDKLs3N7eA6M5aA3gHMgd09E1UyUUhP1rG/lR0= X-Gm-Message-State: AOJu0YxqWKgecHh6fFzx/1XOwzxb4E07Fc6LI6mMZzFCzZ5CSBQyupVg Sk5J21AK95zsLGhRQc1FHi08a/bRm6kcxmNkeNlYfhwABx26e22MYRkKsupbK2RGKTVfmXmfdd3 j8w3yFKJpZup8Zvg4nC7b2/xLAD0= X-Google-Smtp-Source: AGHT+IFC/lgzjrVqZw+SleZf89wRJcsCNPreGa0RhO3+/VS3jdtugrLVI+7JH7JXPY94dD6KKU/3DGMnS1vtCndIKEQ= X-Received: by 2002:a05:6122:3c8c:b0:4d8:690d:c02a with SMTP id 71dfb90a1353d-4df69193916mr4166973e0c.6.1715226513923; Wed, 08 May 2024 20:48:33 -0700 (PDT) MIME-Version: 1.0 References: <20240508125808.28882-1-hailong.liu@oppo.com> <20240509033328.q2gwgaurpeg2mqqi@oppo.com> In-Reply-To: <20240509033328.q2gwgaurpeg2mqqi@oppo.com> From: Barry Song <21cnbao@gmail.com> Date: Thu, 9 May 2024 15:48:22 +1200 Message-ID: Subject: Re: [RFC PATCH] mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL To: Hailong Liu 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: 5ufhuw9cpjd6s3aqknestkq5gmtgtgoo X-Rspamd-Queue-Id: 07FC340005 X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1715226514-909683 X-HE-Meta: U2FsdGVkX18ZIt1jScfeKoI8NUd3nagxSbJaLB0rjQlp8hB5KZCzkiZelPJJSLX9Tj/nNEBYg7Atz4QK028eE9I7j09ADTibmVA67hrjiqv+rQ6ZFnxzUGHKH39tCDd4E220MoD7iv8ribPtLsbeRpgwl+gzxZ8T8/U8gpHXHGunY8vs/AwoX4+qqh1jMjfw7BTKezU4/Y2Znw+1MM4BtiQZfMaQpbDw62LIC+q3VStE10HUHgthJrrtbsFZlvClpDlOuUb5BBn2krPNkaRhBWaA/6UM7P4H0QVEFRA6qfkw8BY/Ne4/bmUIXpoIVZyoFeKk+gZQK11jwhFVsu/nRZrfUwa2LvKYmbY7KgMxf8pBblnaZrofJi0xgAR9BcZT1NBJtPh5M7L9b8iaPh4yWyePd3cqL9ovPEKMJwbK+zCcmISLtOjngtn8OMsMfNMxDKajKUVXxB884aLl5+xAwKTHaHy1VM+VzGq1cnBx6wYxYAMNSjJiAYbcw3sEEMPMLM4yVKLnDk/eDVtbtB5YvHO5ROkxwzOmzmxFMD3bDv2vnNzOrrgXWoiE0UA7bgMNm1MnadY7gj1XW9VZjYuJ3bW5Cf7v1kdgecVWYdQ8fiXzeSrYCo5yRkO+RqtckGKA3783Vhd11NSkRwXIoRjNo3LkgCTsoatqe+ULK/5KFTvg9K4kMfNKDv1ClK0RKe8FOguWxoMkA8444+x1L5OaCn/yh9f5V5hL4e8jPIv2L5PeAbYIn9EBoUEW5fp5l3LvjXoZRjmEvpYG1wMhvLHbqM3coUki7EZqyCnKyz+Pli5NNhr2wRdmoiRdDrmybW2srF0HhNqcuH+x/UYLLVWtndS5sGXdShuJu45frUxjEGdIdStPw/c1ATt46htIupSbkp8RT5OX36SrpljRPe/Agdsie0D7TttzFC+fHvWnT6R13CiiN2QaXlI71FP7eIyuvcid3qvkHLjwmgDFloz j5qZruUQ rvi8+B+8MYGBA9Jee9u3IY+4LcxZ/3LgbE1kCwD8XZQkr+cgreUxK8fqCDX6vpF4+oEZxJTGcqLShUdNUatFgA/T6gDrh+nN+6zhrDh+iHuk7MEmEOT5h1u8CjMqvlKTQBQZsVjXhKxEyyfrhoO4dB4t5fYTb3E7daNUcAJxmRozX4VArp/3YWc1CtevQBqMBxa8gyk3LThdklD3wZ+QpnG0rHkaQf/XWpFWDGF6KWMGUgdfXSf0yV/OVIEJD3bPMTWRcXQHJzCarEEs9VZQfK/A24y6ZioNkvgHWAPsg0jbBYKum4UhdMUowNhReiHOFEmH4ufxVdKjqQ7TW4bfz/oXkmoWF73lABllv70fgsycItKto8el5ekkh7Z2i9hefXTcORmPg+5FKdoz7U8bjnZN2pNAY29mZwXgLwtwjjJGj8kWMp5/cmd5ADQ2zSBB4sdFlJiZXPyPeqH38vA6Zp/JikwNLeWklPpNTYxxiAw2oFdBCKZhkWLUD4Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 3:33=E2=80=AFPM Hailong Liu w= rote: > > On Thu, 09. May 14:20, Barry Song 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_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 ? > > if order =3D 0, nofail would not be set true in bulk allocator. in such a= case, > it is still possible to break early > > > > > 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? > > IMO, if we encounter this issue, it should be fixed by the > caller, not here. I agree. but could we WARN_ON a large kvmalloc(NOFAIL) allocation? > > > > > > > Thanks > > Barry > > -- > > Best Regards, > Hailong.