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 5244AC3DA49 for ; Sat, 20 Jul 2024 22:14:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F6BB6B0083; Sat, 20 Jul 2024 18:14:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A6406B0085; Sat, 20 Jul 2024 18:14:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56E1B6B0088; Sat, 20 Jul 2024 18:14:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 3A45A6B0083 for ; Sat, 20 Jul 2024 18:14:18 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CFD9CA3D61 for ; Sat, 20 Jul 2024 22:14:17 +0000 (UTC) X-FDA: 82361535354.07.759373D Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) by imf30.hostedemail.com (Postfix) with ESMTP id 1DA5F80005 for ; Sat, 20 Jul 2024 22:14:15 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=W+HVuLGI; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.47 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721513612; 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=UYfgBMzOefmoGfeX4rOFwmtbySogV7QOGOgPvAaJpN0=; b=dwja30xDEy4FfSzteGJ0D0cgb12fnpk5kpVHQp471v/+JPsaGWYOeVI6vtqdi5vQU8N6dW x1hWBgQkgJ5jCH44nlHEFZ10+8nQtXOcFa3fPyruF2RkR6Db31rE9bDKOqRE7qng7IqFDw lQmXagIBElpcC1QkoV62FBSDGaQugzg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721513612; a=rsa-sha256; cv=none; b=sD88jetpay6n/eJAq8hKcOunJIKgiInibWkMwKgV5XjAFbPIR3ntblMmKwx+s2QjJE0G/A cxBot5VfJX+TgIEvTmwuxkghhlaj8wGLUGVMf3sfKbY23xjOnDs+nOd+VUsvuMMvK13ERc 9a7VzrySg93tDFT3O7c9tblVRGWm1yI= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=W+HVuLGI; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.47 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ua1-f47.google.com with SMTP id a1e0cc1a2514c-80fc4fe7a8eso1452859241.1 for ; Sat, 20 Jul 2024 15:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721513655; x=1722118455; 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=UYfgBMzOefmoGfeX4rOFwmtbySogV7QOGOgPvAaJpN0=; b=W+HVuLGIXchYyPHDyCJ/Ff4P1pVrt3r72kFMMfd16+Vk3Pfq+2E+0liC+UXN/UdPEM luJPE4cJEK+akYMx7K+JJP2skBYj4drz7l8qk8GGRUzDC9JCc/X//7Z8CyhADDmpPnFx 68XbVc75WqsMpKL7f16iiOt13vCkc59/nwYlzi7R5vOvmtWENfgyxobX54v2lpNMfNCw InMXrsSfhXpEGZW6Pf7dLYCc6uV7b1kwY6jHoqdmSJtqzfnQoWNyfvWLGf32KYs0CjMY eOhNrvmK3zPlaJNGaFkpmIuAcZBMSMnl9DN4PftmFI9cYE529FdTdFQZngoVf/wXDvcw 2dFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721513655; x=1722118455; 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=UYfgBMzOefmoGfeX4rOFwmtbySogV7QOGOgPvAaJpN0=; b=Oz+UtRO9VV8CvZFqfWmiaXCtMg4fIjYodfYSii2Ey+WMlfamjzdQIjhgvJTs4FawTH oQoy+IP81htdU+lcpobFSdSUtt8b0bOM3cRniRuPtfZoH7LJeGqtpmHIKcLOru1qhn+K zhN9bJI9grk+Oa8rx03PXLl1YEsAGnuA/RwqmjHLs14creE+bbhbls5U0YfmRiwyqiz8 lCzXUk1OrFOQUHAddmCW76NdaQuucJHq3TBLnD9mbLn3afmofo7NiK5focr/uH8NWfsr zVYUT1/3XeuJLICFPJC0tOqn1A5iHnZ0Pk4FGXGQkWFryjEgmaQBZRA5fPFjNJ0J97oU ZF+w== X-Forwarded-Encrypted: i=1; AJvYcCUW0hG7RUuoZ25Odjz3kPEvh5DKcPmCPCD8WCk0Yn25TJCnwoaC+/LfquRk+nolVidIwVi3x0JAUXI+d+rpYW1T8aU= X-Gm-Message-State: AOJu0Yy9ZUaiwxIrQ+YYT2z/rPFarV3tvORlPSsAwtFUuHLGN8eWrctj 3DII1RniDEi7wIcGfE18JrpttullhOOMDeB+Yp52xO+8wZShEAMMM1y6GumQPFJg2Z5ALcqVx2g g0mj1wVil7IHbCqMPLxQPc6ESUfI= X-Google-Smtp-Source: AGHT+IHAX6py29JY5Pt2hRxkeNcppwEtUZ5M3YU15NnyYUqhFsSEl8kkqj5ZLGQcybAKfnRGnYlpBXmxbD+AWO23qY4= X-Received: by 2002:a05:6102:8017:b0:492:97c1:a78a with SMTP id ada2fe7eead31-49297c1a902mr475890137.13.1721513654883; Sat, 20 Jul 2024 15:14:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Sun, 21 Jul 2024 10:14:03 +1200 Message-ID: Subject: Re: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL To: Christoph Hellwig Cc: Michal Hocko , akpm@linux-foundation.org, linux-mm@kvack.org, Barry Song , Uladzislau Rezki , Lorenzo Stoakes , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 1DA5F80005 X-Stat-Signature: kaqzf8161ntgdynezht77axsuy35xcfr X-HE-Tag: 1721513655-132634 X-HE-Meta: U2FsdGVkX18bGzg7GD4FlcoLXIui1VI7DwIboGV8w8rZyixxkrkYokX9v2K7wPgdOorfP/A9xTsvqgtEFQ7ljEEfC4ZTVW61mF2BnqqZCVDuhtMYObUzZiXczawqDuN6Y0ZF9IFEvp7uESTxOoaijMKYsKstTGVSRJndtmi8Q9LWhhUiLS7jaqWD/GN3jKom8qdpeTqCSuHL3iYdfA+y56/GtB5ZY98i1furYCiglNCV4fnVugaE+pDpGOP/xJeTAG6OcwCtxeYGybVojV1i82EtbzuE8mHvSQVN787Zs7Hu9sCAQhjz3znUAlrbvRanjKroD0S8fcRcEn9Y3DYzpoHDYiiJOzBsxrI0wSG9ASpF2Tir4a+taxmi1+rXcs1d0hacWr+AG+ujth4jBOpv7iZwS3pWzOvTu2+6cncXH5Mt2t4i1kDK23IqjIGWiCRfdQY/ru9LJw6oIuVdQQ1Y1+w66R5W9kQwnIIOhy2ZGeszCm7GHlUsuWji55/8nuqv+YdRa4BGnCRXE7Blu7rKhs0+Npsq0kCiBVIEJg8tpSEAIynDCU0kHEh5gtdWCEHJ0+JGYdp4731kK98xV19C72VtykNpWMy+Wddn1/YENDtSEBi+UlNHw6+EXaebWJ2W88DGFnrBpTp4mzVpNo5D4FB9cWyj8np18M0BlYgZaoG4XEYaoXZrA68U/lRLdCr/20sRXnAneDW267QlWKFRRRhkokjwsRN+QZD/PQcO/mkayp50OABDI10cIwCH4JQzFXi0bukdtFkSd3d93M+iXPTl0RAK7DqNpZMUz2talPMsIchrVCZHygpXRw8dpulXryJPk6kqEpj6kaYK8lcT34grvtI4JxdGlaav6AvyTQgRfzYrgkop1pNdQF2WHaTK8EQednwjYLITr97VwBGChyoAW7DYd0j0twxzdI9ptHK7iHiLZUZ7spSwuuH55puT8hn59mBfjdWTIxV8NXH 6QCBPymA pwK/LgVHcH1FovM77SqxPL87sOtPcP/LJXG6Ev8SItoP1LeWrXSLI7BDFyhkJDycQvCcv1QP+/awF4wSRCRJPe6pAmpIhfUFuMvzC+i/1RQRiYVSgC+LKYtlxB1TQG3sMzpC+/ncDP2RndDn4WJa/pueOfGmXUw/5K/O91m2TV8xm1QlBZhcaCJvrSO2osQRriCwsk1KFQRfHsiP+gzjM3JbEccjR07oRn8dhnIeW8cGPR94TVeBeRhAbpdwyDivFgk8ceIAYjQbWArmCsUV1IRmWlFUKq+Ay3+yEZnTpbg6gqsh4xdBHDw7mwFWwoYw1evmPKLemij+H6auLz5aVwCTG5xwHnwmPB0EXVsljql/u640mOMfUN5b+Fzse8ZeUinM+mV+GCZXCy7Rw3gJeGzB5X5o4xlG5VL0Laqok1QdMOK/3Q6+XtV/hHuCibl6sIZtvUyFY1nZzdm6Par6DDE+ruU8dMPyXIel3 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 Fri, Jul 19, 2024 at 7:53=E2=80=AFPM Christoph Hellwig wrote: > > On Fri, Jul 19, 2024 at 07:43:38PM +1200, Barry Song wrote: > > I doubt this is going to work as users can use a variant to save gfp_fl= ags. > > On the other hand, isn't it necessarily a bug of vdpa, why can't it be = mm? > > > > if mm disallows GFP_NOFAIL, there must be a doc to say that; if it all= ows, > > we should never return NULL. > > Yeah. Maybe the right answer is to have separate _nofail variants that > don't take any flags and make GFP_NOFAIL an entirely mm-private internal > flags that is rejected by all external interfaces. That should also > really help with auditing the users. Just like Michal has consistently asserted that using GFP_NOFAIL with non-wait is against the rules, I think we should enforce this policy by: diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h index 313be4ad79fd..a5c09f9590f2 100644 --- a/include/linux/gfp_types.h +++ b/include/linux/gfp_types.h @@ -258,7 +258,7 @@ enum { #define __GFP_KSWAPD_RECLAIM ((__force gfp_t)___GFP_KSWAPD_RECLAIM) /* kswapd can wake */ #define __GFP_RECLAIM ((__force gfp_t)(___GFP_DIRECT_RECLAIM|___GFP_KSWAPD_RECLAIM)) #define __GFP_RETRY_MAYFAIL ((__force gfp_t)___GFP_RETRY_MAYFAIL) -#define __GFP_NOFAIL ((__force gfp_t)___GFP_NOFAIL) +#define __GFP_NOFAIL ((__force gfp_t)(___GFP_NOFAIL | ___GFP_DIRECT_RECL= AIM)) #define __GFP_NORETRY ((__force gfp_t)___GFP_NORETRY) Anyone misusing GFP_ATOMIC | __GFP_NOFAIL in an atomic context risks experiencing a crash due to sleep in atomic. This is a common consequence, as all instances of sleep in atomic should result in the same issue. > Thanks Barry