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 1338FC3DA49 for ; Thu, 18 Jul 2024 06:58:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 398B26B0082; Thu, 18 Jul 2024 02:58:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 348746B0083; Thu, 18 Jul 2024 02:58:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E99A6B0085; Thu, 18 Jul 2024 02:58:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 001C16B0082 for ; Thu, 18 Jul 2024 02:58:50 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8C13C1619D6 for ; Thu, 18 Jul 2024 06:58:50 +0000 (UTC) X-FDA: 82351970820.10.BD28C40 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf06.hostedemail.com (Postfix) with ESMTP id 8026A180014 for ; Thu, 18 Jul 2024 06:58:47 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=cxEmme3P; spf=pass (imf06.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721285886; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=lMEYJj/J3SyhZI2PrlNA1b9OpD8GfvaDKRiiGo09ULA=; b=hhOrqNiWoiPxill17Q69t6qE+/miWFapdTyahjjK2w975hrkxbCz0PJCnIgTJIXh/1iv1O j2SJ6TjA1VlpQwH1GnAUOxmWOq1vyBtBhGLrswKxTc8TDflsRpmgLNmOq9Uh4LlE7nPNR1 jJj9ynLR6IZOUcdg5X30pttFUmoYrYo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721285886; a=rsa-sha256; cv=none; b=qbeOWjSQw5FgZEjmyCbxGQApLtPSRRW7X13K267BIBDFlUNga7QbFBxyFbuk67T5Ke79FX MF+Lv1yw0ElOlApBUk9vAcX7eKtawJBAlNjCC7Wr3xJYNot17KsiSU2feq2XBYowwJeKK9 +PZNQ38tODs6rySY3yvPo1JV6TDMXmw= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=cxEmme3P; spf=pass (imf06.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-52e9b9fb3dcso574643e87.1 for ; Wed, 17 Jul 2024 23:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721285926; x=1721890726; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=lMEYJj/J3SyhZI2PrlNA1b9OpD8GfvaDKRiiGo09ULA=; b=cxEmme3P3UetyfoRljhfXaRBu0zjyHDcASymtzLPAxFq1hmQTfrvUp+OZAkZqsWmvh 39rnjgfeLzlXTQWQW1P/GHK5rWrsCqgqaRFIHxaRsTEtWE9PJFHRfaqGgz8sXw75rT6n D8lO58/IbAZ5PFiplaAFRGRomqOD6S8FP80oecKmVj1g6OUPh+bCR8lZXJsWqbzNU/G0 20Xfn1Zmc51DKkXJT5rpAc0v9xk559CE+RRff8b7EldpVKFh4EiCmOKRr3PdACyojUyy xM6LoDicuDUhDSL9c7o1kWjjyZrzpZQl944lyOc6K9Bk0EdD4RsV5ug3m9y1YRQdu61y hUNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721285926; x=1721890726; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lMEYJj/J3SyhZI2PrlNA1b9OpD8GfvaDKRiiGo09ULA=; b=XWc2sBDfiicxOZD6G+xRp7kbdUxGpdwtAuA3fhbB98Ah3C2Q90OJGUZ61TK6JxFV3z MugVHDOSJ9waNEtrfajwjoyyZDNUw+NsMs06vPkYpm6gbh7BcyoLf0GuDsQCsst8cUDv 0tROTTOVv2/6crCFTW665EvaC7Y6DtG4xTXR0fyo2NQAJ3QvjP+0QIaJCePxl9F+bx5M aT3zI9DW+6nlnqILvE+WLdKWd0K6XMfPcS2Hi43rTqXu/GctcAF4i/UgBMK1rCCHS7v2 Wh00y1hhVoEvjwHM4CAUKBUiuxDsrxPUndzcAjS6KcmiQHOQASQPnbMWYt37rxNudKM/ AXAg== X-Forwarded-Encrypted: i=1; AJvYcCVMjHREa3d2KXqrDyj9oVU9pfvgSDfufyyEai1leTy4w27Ag3N5tFZOwCuIr4V8YiK/Kuf3XTA68JY08HbuuYoZcoA= X-Gm-Message-State: AOJu0YyW5ZhGkICu8I80j3mtp589HxYePyLh6FyW7g9seVZccMVcqkEx VtsQ6F7WwKgmoRq5c/WSS8NF7NYYYiw4dq9xLYCf6WqUWjw6/SnU5MH/Ht816NE= X-Google-Smtp-Source: AGHT+IG8sXtDntR68No1fAwFCcKMwB4dOLoWMm7F2ZS03+iZtWUDSYxkpd+I9bMq11K9KbGmAOT4dQ== X-Received: by 2002:a05:6512:3e24:b0:52c:cb8d:6381 with SMTP id 2adb3069b0e04-52ee539c29fmr2594516e87.13.1721285925617; Wed, 17 Jul 2024 23:58:45 -0700 (PDT) Received: from localhost (109-81-94-157.rct.o2.cz. [109.81.94.157]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-59b24a770e6sm7977107a12.11.2024.07.17.23.58.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jul 2024 23:58:45 -0700 (PDT) Date: Thu, 18 Jul 2024 08:58:44 +0200 From: Michal Hocko To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, linux-mm@kvack.org, Barry Song , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com> Subject: Re: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL Message-ID: References: <20240717230025.77361-1-21cnbao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240717230025.77361-1-21cnbao@gmail.com> X-Stat-Signature: kcqocnnm68gkn56kzz86s7rcpnpn6i8a X-Rspamd-Queue-Id: 8026A180014 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1721285927-289301 X-HE-Meta: U2FsdGVkX19lo3dgRdLmOkwBtQA6d8Mo9Feax55P4ui3box7JeLSzKOpyZSMw92t55CBUDDuINMFrBMGoE2W1jnRTD2GlLGXUK+/yqxZwm4/QQGt8B7A16O5IWQihuZbclWBTNU4QGjLYFYDmpF65KAckoGiZHL7AD6y0xaawfl0JBygwq7ipulHkdTME2UrJP5vKKfpa6jj9BN3Jjqu22btVGtqmBiTd1jZSVT98231UgaqonpDZRLsuNDVNfMAWXRrSFBo0JCf46kusjSUN7X8gym/Pxq2hgzQgQA+XFbkwRFLmN64Mg+AzReVkrvLDjI+eX1t8pI/ivs4qNIO2ZCdGOlze+iJEOMEPwYu5JVbuvVYGfszLvg80Hodlp0F9399oKleg3SRakexbFWTbaSyzFKPCdBfA6XZAM1xE7GkfDJC4o4dEURwye536zb6stVvxWLRcM4PMpSOBbvrqpxN3lmw1afOdbgQ/kEHzKKaYJDwOdRGOfoBhWrrtHtRO8KXDcQomqb4/8oBCiR3Wnc29dgD5sVdyhvXw6Trr/Rl8blTMLRTIuGRZLm4V7Ogrmha3J+RQnsGnvtdRs+sDbeOQIqTxpZzXS5T2FqE3zUBDJGc+pILlNaIvPNnULfNsJKJDinAEjzQlFhLlDuhudLTNyu1XQgq882GC3rShq+KU0zf5sTGSM1cjnf2pqAI8/23QvNOh3txMdYJFkxjmd9B5t3G9JLr46j8JaaA7YAJUShopcNRXwFnULnsAnhSf2gQL6rooeWo46AFCtFKI5ii1X8UWN+92YNZeieFa0bDqtdns5PTDZW0fJKd9Z6fcB0832fYheSNk06eqh18S48Hn5lG2QvpA7Qjwu6517UnU2ZWEQP5K3GfRHXYuSqrq/xCnZJzRHpiKudd90/z3DmGfFS1to1kS3XNb/na2+PZkS2B0kQIBqgGnXiNLcP209mssVeFCuJyLJ04Dvq ONfTWsBJ aLOcna4X3HKkveoOTzhp0M2FxwnubYTAa53gKdmDal3qInSLH53rXeoH9iq9y4MTGPj7+jWhOCv4S/DN9mNgowK4ZTCFnbdco7KCuHOyXKTSPcNCHbekwKXaa+15uzIG6hX43Sf459gYbBNGYHr37D5z57XMnyjFPbwanbEgKzzlyI0VgQKnOfI5XK8q4k6rRkhwxhOvUXl7wQuIFEI6B4Pa49PzpOjrL8Uy613oIuvYLmyRI+t4w4dyRSa4xIN4k5TkTMPzB8UY0eChAqmKKaQ9k0vBD1VtWfPOllx/EMpZ+zUfHSWkejHBFLdc1mY9V5F6jJnpbs5bHsmOEwiHCyLI6Yg63bctDyQjtGTeNv9qcFHAAUZmZboNUAls/z/qyRl6984Mz/35sgVwLj2RJxfsYiXf7RGJFWdtOHh7jBvK58JxtfhG7uRtu1c/VoTJRB8lWjVFE2mfHIdOFzQwlx13SuPork6I0XmtsWa/KE3XO1N0bb/+lPsZhyRRzhPIG+/FmtSbP7Lla5ahMj3OEDqJJxX/kizTwbsfW+NpgFR6da75XA+kS7NA8xaDsRCuPaOXkrw8c5miVLdre2BQLbYinczyX/TIY6Y+tZNvyr/0Tj7YbWdSs4tbOLxY+ypALbW1f8N2JK8KGf9UfsjV8J1pmBuSDqhffX0DU+JGpssfBTO75Q0MA2qo8CUPAsby9rolHJY7EPf3GjtP0f0ENpR2ShlZk9oQuPKiJCGuEQqFBuMqqXCJ5EqwgUX0zSYgubbgozHvdyjezXUpC8DvQMpyM7rY6YLp6EmdmDceRgmaJC6M= 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 18-07-24 11:00:25, Barry Song wrote: > From: Barry Song > > Overflow in this context is highly unlikely. However, allocations using > GFP_NOFAIL are guaranteed to succeed, so checking the return value is > unnecessary. One option to fix this is allowing memory allocation with > an overflowed size, but it seems pointless. Let's at least issue a > warning. Likely BUG_ON() seems better as anyway we can't fix it? WARN_ON is effectively BUG_ON with panic_on_warn so if this happens to be in a user triggerable path then you would have an easy way to panic the whole machine. It is likely true that the kernel could oops just right after the failure but that could be recoverable at least. If anything I would just pr_warn with caller address or add dump_stack to capture the full trace. That would give us the caller that needs fixing without panicing the system with panic_on_warn. Btw. what has led you to create this patch? Have you encountered a misbehaving caller? Realistically speaking k*malloc(GFP_NOFAIL) with large values (still far from overflow) would be very dangerous as well. So I am not really sure this is buying us much if anything at all. > Cc: Michal Hocko > Cc: Uladzislau Rezki (Sony) > Cc: Christoph Hellwig > Cc: Lorenzo Stoakes > Cc: Christoph Lameter > Cc: Pekka Enberg > Cc: David Rientjes > Cc: Joonsoo Kim > Cc: Vlastimil Babka > Cc: Roman Gushchin > Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> > Signed-off-by: Barry Song > --- > include/linux/slab.h | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/include/linux/slab.h b/include/linux/slab.h > index a332dd2fa6cd..c6aec311864f 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -692,8 +692,10 @@ static inline __alloc_size(1, 2) void *kmalloc_array_noprof(size_t n, size_t siz > { > size_t bytes; > > - if (unlikely(check_mul_overflow(n, size, &bytes))) > + if (unlikely(check_mul_overflow(n, size, &bytes))) { > + WARN_ON(flags & __GFP_NOFAIL); > return NULL; > + } > if (__builtin_constant_p(n) && __builtin_constant_p(size)) > return kmalloc_noprof(bytes, flags); > return kmalloc_noprof(bytes, flags); > @@ -794,8 +796,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))) { > + WARN_ON(flags & __GFP_NOFAIL); > return NULL; > + } > > return kvmalloc_node_noprof(bytes, flags, node); > } > -- > 2.34.1 -- Michal Hocko SUSE Labs