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 7EFBCC3DA4A for ; Mon, 29 Jul 2024 11:50:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E106F6B00BB; Mon, 29 Jul 2024 07:50:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DBF066B00BE; Mon, 29 Jul 2024 07:50:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C610D6B00BF; Mon, 29 Jul 2024 07:50:50 -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 A5E6A6B00BB for ; Mon, 29 Jul 2024 07:50:50 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 589FCA39F1 for ; Mon, 29 Jul 2024 11:50:50 +0000 (UTC) X-FDA: 82392623460.22.A1CE1F0 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by imf13.hostedemail.com (Postfix) with ESMTP id 7460D2000E for ; Mon, 29 Jul 2024 11:50:47 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=TNv0F80l; spf=pass (imf13.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.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=1722253795; 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=rIAQEHHkyBJQhspmcQ3i+mn3+W1JL08Gv46aDz1iGa8=; b=PFzau7sU/2o9DexW5ZFnTnVtgmWKpnqmWZNq2PYBgCkdHPfnjVIOCMsSH67UWL0YjwhQ81 KT6BGYzutFBZ+YPQgeGd/w6dr+dDQCFthbHvVhwe9QStUtD2DP/RQrmm5i7PuuLKyGRy6j qQO2oh56C2bV+gcg2WuVi6csaokbPxk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722253795; a=rsa-sha256; cv=none; b=CGIIs/NXjRrg2GApYOCEOLY5AF0Cl8J/VoguSzWZ2cDfC1mMM6IcLWjeDo4eESvyPkhToz oGzfKyQkM5kYMQVhWZE3B4dR7lbzrn+e36FBgur2vfeYVi7X0zEigDpj7BDSEzmqW7lCKM /gJLog0RCU8u2hPZpW1bc16+S7Ghj+8= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=TNv0F80l; spf=pass (imf13.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4280b3a7efaso16048545e9.0 for ; Mon, 29 Jul 2024 04:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1722253846; x=1722858646; 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=rIAQEHHkyBJQhspmcQ3i+mn3+W1JL08Gv46aDz1iGa8=; b=TNv0F80lGeB1zo5859A42xXZEsPZhHnkGjCDNRGOwp1lWZwxHoDmkJTVjXxIAQYjl0 hnhCaH/YLELG7AAOlk+m/k6qMCra/bNRq5tA5m466vg+VAsvBQgvDNZQweGoNEI6TDzf uWTm/O+ekR07+IZTT7hrqTs6TmeWkKdrO7sy6TAgxU4/S4EJk9Qxyajfy6ip7XVXt3/d 4fwABC4NBzj3TwTMSK/C3YY2VcvwKLRg5+v776pR9wdBglEJFrwbbcOkphfEVsfA7Wrv Lc6EuRQd1v3zmzzogtyheOF4V2CgU7yqsBur8yaosaT+M5Lb5bQkGEdjWZZDphRCeCuT fbNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722253846; x=1722858646; 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=rIAQEHHkyBJQhspmcQ3i+mn3+W1JL08Gv46aDz1iGa8=; b=V9TZeY4fmV1ACDip0dMY4DVUNTuhmfb82Y2BYsgLZJ85IV13Kn9uBxVqrGxZFv7AeH 9Iaaf9MFQBB8L7GoagwzETUqs3TBHwck+eO2StBxCgmcZLwcoDve1j1lXvjgEQ/yDGOr c70eHTPuoKLzaizxEcsE/CvNrhzWeP1CQaYsf6zLnROTBcF0GLvrjXIAoMlSDv6VvlYc 9O1MhgCdVJ9j8xv8yN0iaaGr1DOgwd1oRf7HjYMB4/ox86n6F7bL7idTAg5D2vXT0bo0 rA1h+Fppw2XUJcA/Y4gSCNVN4TOsHWfQPK4ZaOwWLsm+FGigbJfmfIA1xozM8tqCT+AQ RDLg== X-Forwarded-Encrypted: i=1; AJvYcCUS+ztWCYILi0bstIp6bbNvExpkkm3N7w4ocVjuccjmkeXfJKvHoNyWUJUwXYqiFHOIFRcSatuT7rFUkHHjUoitWkM= X-Gm-Message-State: AOJu0Yz4eCGjeLKdKegEe0shkDRDgLUL+nATbh0Anpjb/FHfabHn2+uU CudthbwKYCVF7CgjzBffnuPmIAhTC6NnEcAXpqw1g3w2a51qvEt9pUkkjymmazE= X-Google-Smtp-Source: AGHT+IFTIg6oHrd/ToypjKjcKs3tnNa2XWpb4cIs4Dkl4KzITSykcMA/gcRN2x6qJs+XzLC2L+YGxA== X-Received: by 2002:a05:600c:3b99:b0:427:ac40:d4b1 with SMTP id 5b1f17b1804b1-42811e12d36mr55021055e9.27.1722253845798; Mon, 29 Jul 2024 04:50:45 -0700 (PDT) Received: from localhost (109-81-83-231.rct.o2.cz. [109.81.83.231]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42805730d5bsm180974675e9.8.2024.07.29.04.50.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jul 2024 04:50:45 -0700 (PDT) Date: Mon, 29 Jul 2024 13:50:44 +0200 From: Michal Hocko To: Davidlohr Bueso Cc: Barry Song <21cnbao@gmail.com>, akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, hch@infradead.org, iamjoonsoo.kim@lge.com, lstoakes@gmail.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com, v-songbaohua@oppo.com, vbabka@suse.cz, virtualization@lists.linux.dev, hailong.liu@oppo.com, torvalds@linux-foundation.org Subject: Re: [PATCH RFC 5/5] non-mm: discourage the usage of __GFP_NOFAIL and encourage GFP_NOFAIL Message-ID: References: <20240724085544.299090-1-21cnbao@gmail.com> <20240724085544.299090-6-21cnbao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 7460D2000E X-Stat-Signature: esui6551jb4x7fdsnpg7pxo9oofnguik X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1722253847-614631 X-HE-Meta: U2FsdGVkX18+//hThQ8ZgC4zHKftKHEmFhhf8EKFH+EYRQjE2QdMb/EvdzIuTFPctODGKuT4/X1qR+oiU642ZVLC3V4kHQGtjIq2FO/wJRfft1g+pmcusiddbl1AHlIqwKUWcWO0AxitbKCtfokm8CiDZT9vTDVJ/a9x0WVdn0MdstvQhypTCk/nr+BIzsVzo57y7Mu3gjgX/YHE9PobPfHVc+rYbJMjfan9k5LHR3X/jlaWrEULuYN0liXFSD5O5m8RtPDPiafcNyF7ArlXxP4vvJ2jiHXlCfS3nj04UvtT+wE1uFo1viZSjygotQMUJmFFiQG2SPNB2meGag15XJJvBjasKGe3hkCTXIg7IOwNU29drcyJc/q4UtfwsRBmNARovy5N5vOWCa7qlyQwmpFHWe3UTzxINv1D6W20JV64+pSZb5wxX0av9dpx2e9Y7pb+gPGCCpVhzUm1kNWoZ3grOMRm61yZ8xT/Exossc5Ay5r51T4VaMOSKH8AQJfQy8446APpWnLsypDrOotxRSz4Cmr+crRUtSIi60NhT67HMD6sIStg3y7cmSS0NICzPLTCNa2jw1OoZAs6VpqzqyX5OWp5dQDCfaJJ+QPwbYOYENm5QhqHwEsUhjNrmob4wNTLuPGY2O0CsK2pdHAB03p590bY1zRY2jbjcBlWzn7LhqCRu/wuiwHjciTZo5dRFFaZRCOtQCPRCQVrmmnmi4tbzy+iWPF1/X7i2NXeC9JH/XALmnF2oyvCv3penE4K02NC2+AANZLMOQB4WT8AQiA4NtamhnzZE/HGIvvQnhNxfUCGHq4FnjB7cKLc+6OqbchP+voWRv7s3ZSrjbblDAQkZ+J02Ce8NxvwZvOK9n3x5SMkducj9xd3rSlCF6ma4ThefYRxQ7vL4fxw4nvc8FWDCcPjpP6NWRZvkC1102qlK/JW3MRvOgS8JFTH4GaV2Vug6AxjjHRxLtmM7+Q SGsrxchH gaJ6Rh0i6guDvf1YdrsuIIga1YpONrQLzB/AeqnLbG2E1m4AheUvv1sNdygIUVV9P5zhZyVuLC51htikkcmtbGx0wCVO1vrJxQdPz4JmlWqPG8BuoMuBI138zG7r6r25UOgRARD+dyzRwTivcwq5DLtwI/bl8oIxILk4bwr4GmU8KHJCrSbw2PnLrxMUQG9+/5GYSx07HffSuBMkOYLXWCigIja1EAe4aRVsFaDoCvqMTL+RYhSn3Vpclv2te+cWcwfz9upLkNd+kb1oeHxKbK/eJFOM2g4fO1lJkE2bAxRyRwv1FWCyriX6GgSUJah7bYCiMKRNc1b2tlXqDJ5825bY1PFk8O2pKlTyZHf3maE1v81un6AOJvuGCt3G+maB70aROwEFsZlSDyCMie3gc852Aq0nH9mkfc3wFn5JjIKV2cpUpKWXnia4hkdZQ3P9MhBitSH9I4mzBWgbfbWbrOyYTLfgdczIREuk4UWy1ZiS6omyIPV/aelVjKq6C+Iuc6MZXRqkhuT92QGc= 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 26-07-24 14:08:18, Davidlohr Bueso wrote: > On Thu, 25 Jul 2024, Michal Hocko wrote:\n > > On Thu 25-07-24 13:38:50, Barry Song wrote: > > > On Thu, Jul 25, 2024 at 12:17???AM Michal Hocko wrote: > > > > > > > > On Wed 24-07-24 20:55:44, Barry Song wrote: > > > > > From: Barry Song > > > > > > > > > > GFP_NOFAIL includes the meaning of block and direct reclamation, which > > > > > is essential for a true no-fail allocation. We are gradually starting > > > > > to enforce this block semantics to prevent the potential misuse of > > > > > __GFP_NOFAIL in atomic contexts in the future. > > > > > > > > > > A typical example of incorrect usage is in VDPA, where GFP_ATOMIC > > > > > and __GFP_NOFAIL are used together. > > > > > > > > Ohh, so you have done the migration. Please squash those two patches. > > > > Also if we want to preserve clean __GFP_NOFAIL for internal MM use then it > > > > should be moved away from include/linux/gfp_types.h. But is there any > > > > real use for that? > > > > > > yes. currently i got two, > > > > > > lib/rhashtable.c > > > > > > static struct bucket_table *bucket_table_alloc(struct rhashtable *ht, > > > size_t nbuckets, > > > gfp_t gfp) > > > { > > > struct bucket_table *tbl = NULL; > > > size_t size; > > > int i; > > > static struct lock_class_key __key; > > > > > > tbl = alloc_hooks_tag(ht->alloc_tag, > > > kvmalloc_node_noprof(struct_size(tbl, buckets, > > > nbuckets), > > > gfp|__GFP_ZERO, NUMA_NO_NODE)); > > > > > > size = nbuckets; > > > > > > if (tbl == NULL && (gfp & ~__GFP_NOFAIL) != GFP_KERNEL) { > > > tbl = nested_bucket_table_alloc(ht, nbuckets, gfp); > > > nbuckets = 0; > > > } > > > > > > ... > > > > > > return tbl; > > > } > > > > Ugh. OK this is a weird allocation fallback strategy 2d22ecf6db1c > > ("lib/rhashtable: guarantee initial hashtable allocation"). Maybe the > > code should be just simplified and GFP_NOFAIL used from the begining? > > Davidlohr WDYT? For your context Barry tries to drop all the > > __GFP_NOFAIL use and replace it by GFP_NOFAIL which enforces > > __GFP_DIRECT_RECLAIM so that people cannot request atomic NOFAIL. > > Why is it so weird? Because it is really hard to figure out what it is supposed to mean. If the caller uses __GFP_NOFAIL then it is (should be) impossible and if NOFAIL is not used then why does it need to check for (gfp & ~__GFP_NOFAIL) != GFP_KERNEL? this could be GFP_NO{IO,FS} but also GFP_ATOMIC. So what is it supposed to mean even? > Perhaps I'm missing your point, but the fallback > introduced in that commit attempts to avoid abusing nofail semantics > and only ask with a smaller size. > > In any case, would the following be better (and also silences smatch)? > Disregarding the initial nofail request, rhashtable allocations are > always either regular GFP_KERNEL or GFP_ATOMIC (for the nested and > some insertion cases). > > -----8<----- > diff --git a/lib/rhashtable.c b/lib/rhashtable.c > index dbbed19f8fff..c9f9cce4a3c1 100644 > --- a/lib/rhashtable.c > +++ b/lib/rhashtable.c > @@ -184,12 +184,12 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht, > static struct lock_class_key __key; > tbl = alloc_hooks_tag(ht->alloc_tag, > - kvmalloc_node_noprof(struct_size(tbl, buckets, nbuckets), > - gfp|__GFP_ZERO, NUMA_NO_NODE)); > + kvmalloc_noprof(struct_size(tbl, buckets, nbuckets), > + gfp|__GFP_ZERO)); > size = nbuckets; > - if (tbl == NULL && (gfp & ~__GFP_NOFAIL) != GFP_KERNEL) { > + if (tbl == NULL && (gfp & GFP_ATOMIC)) { I have really hard time to follow what that is supposed to mean. First GFP_ATOMIC is not a mask usable for this kind of tests as it is __GFP_HIGH|__GFP_KSWAPD_RECLAIM so GFP_KERNEL & GFP_ATOMIC is true. If you want to explicitly ask for a sleepable allocation then use gfpflags_allow_blocking but fundamentally why you simply do not do if (!tlb) tbl = nested_bucket_table_alloc(ht, nbuckets, gfp); Why does gfp flags play any role here? -- Michal Hocko SUSE Labs