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 9E7FCC3DA7F for ; Wed, 31 Jul 2024 10:58:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1CB176B0085; Wed, 31 Jul 2024 06:58:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 154D76B0088; Wed, 31 Jul 2024 06:58:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F0F956B0089; Wed, 31 Jul 2024 06:58:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D28D86B0085 for ; Wed, 31 Jul 2024 06:58:05 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 39C02C025F for ; Wed, 31 Jul 2024 10:58:05 +0000 (UTC) X-FDA: 82399748130.09.2736A7D Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) by imf08.hostedemail.com (Postfix) with ESMTP id 68897160008 for ; Wed, 31 Jul 2024 10:58:03 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=b6AvhVyN; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.174 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722423442; a=rsa-sha256; cv=none; b=QilsiEeyqo2LJo+Ys5uSnaNNDCwuJEL0gH0MY0hF0rctMgWrvbHVSOaUv+9kP8/dfejSwe H7jfJLvYAgKP39D6/Vb/qoiST9sNt/iV5HJAyqt17J1OtBmPP84cVkbN12j03k4ojEJjMj LlCOzuKdRpvx2yrnrjikAlBGnwCZH1I= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=b6AvhVyN; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.174 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=1722423442; 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=ZI2fOIWNIi8brIbdWyl5BAEku9ydAOxY7gLMn3uZQ7w=; b=BIpJcqCu7Nmylw/NFbB1ShCrfqE4kxUgoi8T693KOc7eJisfI5MNf9lSKggxokTQlnE/TV 5a9S+5oBgJ13CuxUGMRvmCsZEd0Q8+t/GJC0j+lK+xZV8C9LL/GL3oSgBF7p5CLpjP+h8N N1j2svmqgWhSxJqCGNxCel6L3vFxkjg= Received: by mail-vk1-f174.google.com with SMTP id 71dfb90a1353d-4f521a22d74so1833377e0c.2 for ; Wed, 31 Jul 2024 03:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722423482; x=1723028282; 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=ZI2fOIWNIi8brIbdWyl5BAEku9ydAOxY7gLMn3uZQ7w=; b=b6AvhVyNFAq5wPLuffN065kvBas3Tuoz+t73E+KKQZD63woae3Bv0ZyjgtFPqNSwWt fhoyAqId6AfkyoFV25Cl4Iy+Q9xhP3ML5E00MD17RU49Hd3kPQ04cbbGFlMm0qjf5dxv hUFXglGS/YfOpvrBrpTFiXn7w4bS5daKXQkgkpRImwxatTXpO7skYLp2x9XiDxQeT5qx PykqChEj0TUfnihgdidGX3N3u3zKqlrc2hMkQF6KWr4ez9DvaPbS07UJhcsBw8UwzSKc OScmKRlbYeEb/a3UVoODAWcCOE9gE+Sov5lSpoak2ofrMCAYJbPh/Fy1yCYjBk1G+NtD ncOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722423482; x=1723028282; 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=ZI2fOIWNIi8brIbdWyl5BAEku9ydAOxY7gLMn3uZQ7w=; b=PiJ9CDVPnGV8w6+co+BZXbMulvgsgAaMtV7C2/m5f8ppfZ4xa7DYXXvIYvstaFfsBQ tXzFj0meM1GTu7jnouxJ979i4ncNBWTaNvdG/lZm6xKjg9ksVxA/EPHhuTjoMV6jce+J xNmqI1/E4jqnxpB8EKWudrGzpVl4Rz3MEmEbvGe8p/f9SUmgd2d24YMTt7Kj1FJ8piRs ZssDKytNp1PVMVj9myQ8invXsyF9hFGCxo5kQ4+1VGmIEULQZnUlTmdCG3o4xB9RVysb utKLAkkHAPqz2wg4Fb++fxtS5tP8grPa4NYnN84lC9j4+tpMs+OyCAE9BTF4jY7uKyhp kj4A== X-Forwarded-Encrypted: i=1; AJvYcCU3QYkl6LBJ6b81Hq+41t1OQNY5jutTbTAMon9nvJhvV5s/wvAMlZGZQdBR+wGsPnsLd3L7r1fEs0rWIsLc1DKXkZM= X-Gm-Message-State: AOJu0YyUdBYD64vOsL5LwV0CPcvfmdjWwWCvxp8o3NJfK7HQrv/KJEYP FCorXvbX5O7xZna5AOMBiFOO9SLE+dLTlZhrY9tTGy9X1ZDrFgGxg/93i5YWdMSjBrV0AWnONje Kv5DDn2KeSSe9JxKmqI0IunTCmCk= X-Google-Smtp-Source: AGHT+IGLSySmlzUKevAJ5A1uSyXIxhv6Bs7IiI7BS9LrrJGdKas4ZhUKG/XVHehibb0M38m7WTz/cJjJo/NDW7/4bIY= X-Received: by 2002:a05:6102:6d0:b0:493:c1f0:d46f with SMTP id ada2fe7eead31-493fad1516bmr17713978137.22.1722423482432; Wed, 31 Jul 2024 03:58:02 -0700 (PDT) MIME-Version: 1.0 References: <20240731000155.109583-1-21cnbao@gmail.com> <20240731000155.109583-4-21cnbao@gmail.com> <9f1d0f2b-ee22-48b7-ba60-d7b886572670@I-love.SAKURA.ne.jp> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Wed, 31 Jul 2024 18:57:51 +0800 Message-ID: Subject: Re: [PATCH v2 3/4] mm: BUG_ON to avoid NULL deference while __GFP_NOFAIL fails To: Vlastimil Babka Cc: Tetsuo Handa , akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, hailong.liu@oppo.com, hch@infradead.org, iamjoonsoo.kim@lge.com, lstoakes@gmail.com, mhocko@suse.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, torvalds@linux-foundation.org, urezki@gmail.com, v-songbaohua@oppo.com, virtualization@lists.linux.dev, Kees Cook Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 68897160008 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: w4o5n9qsnebxbyokc3qesio4811f1aha X-HE-Tag: 1722423483-526427 X-HE-Meta: U2FsdGVkX19URotyTKXWCXA48C0bTWVrQhUjewi9ms9pESLsx4jM9xLxY7wuXIA5rC0xKEcduRKIdbmgx23/K+yLntlQ3PrxaRObuk0L6RxnvunxSzjQaXaaZiMt3oj762UXNTE86bT26FqoZzh1RzfbJNtIl5a78pG7LmLrhzkjMnVSIhmTFjbvBhnxOEdoZPV6mK8OnRAdqZixAj2mnysMuNTJFSpTO091e2pPcg/n3OszPSTlDusg/tnwQ0iFV1CmKvAer95/MBuHEQz+3LMPInOtEKmTo73BylxppTIYF5Y+focmeSYnx/pwENJLCFxWU21wVHFggv0wtQrjDpe4uhzwlaHCwzYcmvM/Zr8zrKjyM+4Wj3M12QelK5qtyzmxFI/2CyPzeo7etEWldRkdplw1muPEnuEc06QDbt2b9SqwdF5djL/EFOKGo9xxNxXCBDLEhYao4jpknf4i3Mfc1m6J+84TM3/O/mnWcZdJJeTgwUduQpFofY+UzVLi6twuWZv0flt9K5JiHFMRpbS2ese1vPtu1ySiJnpLM10gDLfc25OOdV9t+STEDe09uYBImSqrNTQVLrTTd6zcXkBETcwzg/Q/Mi9HUMnJS1NLlmXUzmVPJI3lsx/wJSiDMPoJaLIGwkuHT32GeI0p77fDqJHRU8U81hUC7CHuf7Tt+DMCaTTpu3f6f5/Nr9By2CZcmaRXdRHNBM+1xxedX+z1VnQf1f4wryhHsb85pw20i77Yj0/gfTmnFIO3swpTD5rbCCYF1jDa2p32JTlVvWgN48kEIy19ZxQnxOQvdiT7tVEH9ELeaF6122vv81nNpWVhCO+shnTo5nYmdDbuemhseRRpa/nbSFgYmemA1G74+cp7MK8itUa/QR0Ae2o+Xl2eoOekJK/0fCveF5q9Wtfe7ckVCA6BgYFkfASbrKgH9u7ft9oaPuphrZ1mfdZjNuuPAIgjOW5Ba30n8pK 9Xt1Ukw3 idAzc5PG8WwpAZde7peiJ9ljXbAsUwQ8N/1+ky2xqH8jT1NUgeDjjWON6xRbp4Kie+gpHWvRRuLtw1VviAh7MhtQ4qg8BfJOS/oAtH7naymbwZbZqavrNP99iUFsj8t14/tvEore2FYoJVUrGoOGYycqnUdfQlILCaFwjzTpZYldwXyRMEYqVUdZEjxPe1zY+2hY19vwTbZqIof99Q2AiWL0KkyP9mE0eCebdTHSqIXX2XMX8BtBUHEPgbfXMYvGl+5s/mqzJ44vRn8NLzcwLM7VmyXkgN7vTSISVx1/N1XG9/A7dikRWEZLtt7a8GvATafr47+xGJn6MGBaY3AcEP020oqkSMBCA+F0ptnjcv6qmi1lEadqex7gj2OzxeyeUNcTuZnKaUOOincKH+YPh+P9o/a2U7znR83g3 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 Wed, Jul 31, 2024 at 6:48=E2=80=AFPM Vlastimil Babka wr= ote: > > On 7/31/24 12:44 PM, Tetsuo Handa wrote: > > On 2024/07/31 19:29, Vlastimil Babka wrote: > >>> @@ -827,8 +827,10 @@ kvmalloc_array_node_noprof(size_t n, size_t size= , gfp_t flags, int node) > >>> { > >>> size_t bytes; > >>> > >>> - if (unlikely(check_mul_overflow(n, size, &bytes))) > >>> + if (unlikely(check_mul_overflow(n, size, &bytes))) { > >>> + BUG_ON(flags & __GFP_NOFAIL); > >> > >> Shouldn't we produce some kind of warning also in the no-NOFAIL case? > >> Returning a NULL completely silently feels wrong. > > > > Doesn't embedding macros like BUG_ON() into inline functions needlessly= bloat > > the kernel size? I think we can call a non-inlined function (that is ma= rked > > as EXPORT_SYMBOL()) for emitting warning. > > Hm yeah we could probably make the whole function non-inline as it result= s > in a call anyway. Although this might save some code footprint, we will result in two calls for users of kvmalloc_array_node_noprof() with both Tetsuo's and your proposal?