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 48F4BC3DA5D for ; Mon, 22 Jul 2024 09:01:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D04D06B0089; Mon, 22 Jul 2024 05:01:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CB5006B008A; Mon, 22 Jul 2024 05:01:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7CA86B008C; Mon, 22 Jul 2024 05:01:29 -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 96C016B0089 for ; Mon, 22 Jul 2024 05:01:29 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 315E41A153E for ; Mon, 22 Jul 2024 09:01:29 +0000 (UTC) X-FDA: 82366795098.15.B533BF2 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf01.hostedemail.com (Postfix) with ESMTP id AD13F40031 for ; Mon, 22 Jul 2024 09:01:25 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=AI5FTcEF; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.48 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=1721638840; 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=sfrNezr2LdM4yZxUO/Xqco51gCgFX0XYWHh6aVfIh5k=; b=bEueU1GijFFXRkZegvuN85mlocNZTl53EXJyz0XOdx6+7S71a7m971AK8fOI7+yXxrhXxc xmiDRv5k6y1FJPPYsbM3Oyb50rtnr7w6Qxdy0jzWiSTP1ZWbRfvHcFj9mfCRR58a6seNXz yL7KuLfWmK0kG4fPm3++o//P10qJD/0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721638840; a=rsa-sha256; cv=none; b=g7ttk4S/TWjjcBwWCdggSIuqwSTOtcOh+aOBfAoMgDRWemILL95lY/xFqwTH5VMD+Tjf6S 2Ndbx0Bj9XU5EIAVJflvgTz6lQLb0yhV6sZ+xFB5IMffVXM4BghU9Gr6StQYvdlZTu82Ub qqt+k5Gpjg57d0RdUEcgYaDiNfRIM7g= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=AI5FTcEF; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-52f04c1e58eso619706e87.3 for ; Mon, 22 Jul 2024 02:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721638884; x=1722243684; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=sfrNezr2LdM4yZxUO/Xqco51gCgFX0XYWHh6aVfIh5k=; b=AI5FTcEFfCs4kzsfv8yihnyOLDq3ySERouO7A52TAYHXzUQfnKcJ63mWgyc51n1SHR RvvvLUTwowDrGBHrfJLr+YlIRPnLvbHWMMwCJlXCcuaKvB6ojCPWV83hoKucidLEKa7D i+aM/JHl48RA1yxciq7zxnhK5xj1PSgMDcB4Ho02lql/P+cFuXSX2g291UsoC7uTqqde H4fES4hHboyk3dbwF5v8NqTnfMfqDzRS27O/4GO0yucBLBFu6Vsz2lU8UQ1XAbOzF222 Xk60hm5OHqP7U0fDb5bwSfis/ssHUk7WUwD0JPXgqnNTbMI61H865LHpqTSnAj+fBrUg U3Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721638884; x=1722243684; h=in-reply-to:content-transfer-encoding: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=sfrNezr2LdM4yZxUO/Xqco51gCgFX0XYWHh6aVfIh5k=; b=e7XQVwD7s3Ea6nLWD+UYgStM4BKSxzbQHA3yt21N35rwZD9+ICnVHGBwneYE71lqvc mes/IWB93UhHQD30Lzc1Bsl+0HsD53qWZYkoIoWgHtsKAR9X9L91TBOJE9lJamFHvSV0 Si7xVvViloUOF99VQr5Lz1jIa3FIjAMcdX+nikz/CjoX0SLOw5CexJn42JCUIJ07waDY gycLdIZlRkkokNcez3Z3ATCfA9Wi9J8tCzXuwF9rjenLy7SLcwQH4q3lh4l4S99uoLYp 0OqrMajnlTjBfeyV3eWgdHECApKQ5EMXqVBzunc2nNBLgXRrnCPkRjqpaCndwkDjxNCW u3VA== X-Forwarded-Encrypted: i=1; AJvYcCXyGt3o4hnABIithEFj8DZJCYm9rZPDQECZ/rgJP2sP+GbA6nB5a+ZNi964Ez9/6xjx3PUMRO5ivCtMHidvc6rmuj0= X-Gm-Message-State: AOJu0Yya8Zn8Q+sFofun2gx/V5ncurbprRM5QDOpOiY53mv3FIpBGpcH 3lFtKpn2804aFq06h6ApOMYR9uzDbejsOpjBPpZ1yVIG3rP3mvTOlSPyhKBYu9w= X-Google-Smtp-Source: AGHT+IFioTFjyuQc2rWx9/eZOKMLgznT1YhdkrpzzwydASkaqSVv2d9WHwkMuXSksLCOonAFz/8A3g== X-Received: by 2002:a05:6512:3409:b0:52e:976a:b34b with SMTP id 2adb3069b0e04-52efb53bcc4mr4086151e87.15.1721638883769; Mon, 22 Jul 2024 02:01:23 -0700 (PDT) Received: from localhost ([193.86.92.181]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7a3c7bda4csm394277166b.59.2024.07.22.02.01.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jul 2024 02:01:23 -0700 (PDT) Date: Mon, 22 Jul 2024 11:01:23 +0200 From: Michal Hocko To: Barry Song <21cnbao@gmail.com> Cc: Christoph Hellwig , 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> Subject: Re: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: AD13F40031 X-Stat-Signature: yi4inehuzjmsq89rwkj597ou4jk8piko X-HE-Tag: 1721638885-973058 X-HE-Meta: U2FsdGVkX19tWp0daI5kJudPzd1/XCcOnPApmQx98Lndi6SAIBLXnPQk+2cluJoeghsgDqIsffwiQelc34N7IASqEp6raguTAhcY2XYPzI0eo6bbBInDKK0qzm2vWp1mhnFrzYy1qQRpc2WjGKGNJE/HrWmYGmvNjHdCqhQIG71C1TArnkKpxv4gIXVhK6bralA5sbnwf8rk5Hp7DpfBMNhH9NQIV15R6itynSiZ8u8E2h++rCkwEMjXfMLKa/JWgig+HqvkDIfp/opEP7MTeNDLRPwHJ9OOz4si92Rn5utJ7VBIvuQHPF/mc5VCSzyckvn5aiXC91a46qPou85ShO2bcQT0LX2FfSQ1yGrB5O4zp0I/bwECpcTgHDzh89c6YrI2e0rkG4Fc0kisN5L/CI1Sa7ih+dtXCkQa9erMBwhSxIOxwNOuUh+5QH09QxfJfMTbxXmgVC0wS9V+UWWoIlwTCVPOseUEzBe2CpeiDVu2tXREkSfVZOGwqfWOrXYAcSDxOOnWMFcjToIL5WVGk5PCsf76jJ4Zd8d/xpeVoxOBvfCqAuG2QhjLfPmjZo0sZ7QvnJ/uygqPqPkH60Xhd0J19ZPRvq5A5jCnfUyi8Zt+OVupoqh/U7zGYiZ1mjsFDVx3KIUIc+HaG8Msxj3tp6mn+WIx1TCHO8DWEDzBAhH4DKy+81ktnXscLGc14IXD/8yUCMLuLr/B4/AqbbBa574RqAW1sDFh69ePSpxjcRTJ7LRwfbDpJxbNRZUD/tVoufHZUtVlQkRkILtprW5nrc52EHUa6DqCnHQyd5PpVTQJuEvddDHcnk0IJh4p7Q18LDFQEHBXl8hq6mn3wTClTeeaPqqbOGFVz0Gndil0SAbW0v9W9jHFM0+tOCZE4ho/CeT9ZKcoIqMEUgLXFVgZWNJSXNmYOnm5I40ywGPWA3n3X6TQaI1XBWVCXtDimdsnv9OvgZl30zDyhwb2w46 1ygnMzb8 eYt2dAsZfxmp0tbsdNJTg+79AxGibq1ivxBtqmnmwvECFTttIJbgW5jTPgUbxIHLpeimzbKlT+B+jEvi5cqBQgNhrxjPAxU9HZ0B3aW36q6pDDbp40e2m9kTb8XrbEXB0n97aToZxGlNLsOJrtQRlFNgHkdPTmlW9AUtcCt431uquifKIvcO1yxr2/YPX6ZdbmMe9JVOFeVsQVJo9ib8TnVimIZTJ1yMrUh/K4Mo/Dwu6sJWDULtYeQKVo2nWhFTyN8ROGpDBObboE/5t+zzBgHLdbfEUbFTXnuyvvrYXIR00GLs/qnHJ+ZmejilS8eNbNs+0AImp1vtMJtiOQqaWEO7cLGFCXDIeHqdCjLL7P/Ecn0wPDJV2tqdBHTbQ+85tXMbuo14K2gt/al3ZReu8EEbqWjWGT0gkP14c9ucWAAsLn3A6bpBGLa6kaFfeRS72zb/ybb9WTHBdlEl11W/FQlnawMmISVEnQIniO41M7GGTi/Cx06TTlOo2W9NsDGo8fCqAwGuiKBuMOCubWZ91Rf8YtljmzjzAx4a5I5PkjN4cIEmlwUMWkheecYfTByRtMDDyTP96XwrTCua8jCR3XGhPHu3MaQSmwtigpyplx91HfiV+cGqKd6vyr7+idPwTC7F89TMxTX5JpehhT19lMgqK/jE/PFFHHaTP 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 Mon 22-07-24 20:09:37, Barry Song wrote: > On Mon, Jul 22, 2024 at 7:26 PM Michal Hocko wrote: > > > > On Sun 21-07-24 10:14:03, Barry Song wrote: > > > On Fri, Jul 19, 2024 at 7:53 PM 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_flags. > > > > > 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 allows, > > > > > 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. > > > > This would require duplicating many of our allocations APIs. > > > > > 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_RECLAIM)) > > > #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. > > > > I really dislike any of __GFP_$FOO to have side effects like this. > > Please let's not overdo this. > > Okay, but my point is that if GFP_NOFAIL is inevitably blockable, why > not enforce this and let users understand that it is definitively > blockable? ust like when we call alloc_pages(GFP_KERNEL), we know > it might sleep. __GFP_$FOO are usually low level. GFP_$FOO are high level and they combine several subflags to have a specific meaning. So this would need to be GFP_NOFAIL. Btw. the same applies to __GFP_NORETRY and __GFP_RETRY_MAYFAIL. Whether changing existing users of those flags is worth is a different question. -- Michal Hocko SUSE Labs