From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8363D153BF9 for ; Fri, 30 Aug 2024 21:45:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725054349; cv=none; b=HAntK2BpyUqAo1s1UYyljLeTDIDB5ZceDVC1wKU4110aOExULkVuaYk7wTzeaAZGRBKXNwekBNXZlevLEdrf2TjQyu2IXFeudyXWII2UJVYhovqnhTaXYbpPLHh4LcZL/vWk2wDtN+3oHMBLv7S3i03MHJaGIRY8x3P5VY4h5c4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725054349; c=relaxed/simple; bh=tT9SntABoUORGdrFntLQeYZdhuZnTLS8L3T1BnaWb/I=; h=Date:To:From:Subject:Message-Id; b=KiPYb9Pgpa/inE/WpDUHT2SQArRB2F/uQY1IElw/vz8YrR02TYS5nVGB8Qu0X8/DdZLI/FQcv06NtbO9RgAv/FS9KOFKALlZjaL39g8+bizx44JHyxr8F+FcxA5+ik4EbFK7lHK94LUHmMCE4eTh2BUfxXkZTK4LnBLsYmWK7lw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=aAQ/0RyK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="aAQ/0RyK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE377C4CEC2; Fri, 30 Aug 2024 21:45:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1725054348; bh=tT9SntABoUORGdrFntLQeYZdhuZnTLS8L3T1BnaWb/I=; h=Date:To:From:Subject:From; b=aAQ/0RyK4s1AzPnyxTCh1Hm7eUCX7RPAJXZAPqHXHDoUlgJMysKnrpugw07G/9dD2 KP0HgDdyYFKVv/ZtPMHdKrIpkGSXSPth4L/3mM1VI4ec7GiBbAaupxjSjgFJZ2cwa1 wDOvK83tlqIALpSfLmb6L4DjM5G43tI3N7aM4PtE= Date: Fri, 30 Aug 2024 14:45:48 -0700 To: mm-commits@vger.kernel.org,xuanzhuo@linux.alibaba.com,xieyongji@bytedance.com,vbabka@suse.cz,urezki@gmail.com,torvalds@linux-foundation.org,roman.gushchin@linux.dev,rientjes@google.com,penberg@kernel.org,mst@redhat.com,mhocko@suse.com,maxime.coquelin@redhat.com,lorenzo.stoakes@oracle.com,laoar.shao@gmail.com,kees@kernel.org,jasowang@redhat.com,iamjoonsoo.kim@lge.com,hch@lst.de,hch@infradead.org,hailong.liu@oppo.com,eperezma@redhat.com,david@redhat.com,dave@stgolabs.net,cl@linux.com,42.hyeyoo@gmail.com,v-songbaohua@oppo.com,akpm@linux-foundation.org From: Andrew Morton Subject: + mm-warn-about-illegal-__gfp_nofail-usage-in-a-more-appropriate-location-and-manner.patch added to mm-unstable branch Message-Id: <20240830214548.CE377C4CEC2@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The patch titled Subject: mm: warn about illegal __GFP_NOFAIL usage in a more appropriate location and manner has been added to the -mm mm-unstable branch. Its filename is mm-warn-about-illegal-__gfp_nofail-usage-in-a-more-appropriate-location-and-manner.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-warn-about-illegal-__gfp_nofail-usage-in-a-more-appropriate-location-and-manner.patch This patch will later appear in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Barry Song Subject: mm: warn about illegal __GFP_NOFAIL usage in a more appropriate location and manner Date: Sat, 31 Aug 2024 08:28:23 +1200 Three points for this change: 1. We should consolidate all warnings in one place. Currently, the order > 1 warning is in the hotpath, while others are in less likely scenarios. Moving all warnings to the slowpath will reduce the overhead for order > 1 and increase the visibility of other warnings. 2. We currently have two warnings for order: one for order > 1 in the hotpath and another for order > costly_order in the laziest path. I suggest standardizing on order > 1 since it's been in use for a long time. 3. We don't need to check for __GFP_NOWARN in this case. __GFP_NOWARN is meant to suppress allocation failure reports, but here we're dealing with bug detection, not allocation failures. So replace WARN_ON_ONCE_GFP by WARN_ON_ONCE. Link: https://lkml.kernel.org/r/20240830202823.21478-4-21cnbao@gmail.com Signed-off-by: Barry Song Suggested-by: Vlastimil Babka Cc: Christoph Hellwig Cc: Christoph Hellwig Cc: Christoph Lameter Cc: David Hildenbrand Cc: Davidlohr Bueso Cc: David Rientjes Cc: "Eugenio Pérez" Cc: Hailong.Liu Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Jason Wang Cc: Joonsoo Kim Cc: Kees Cook Cc: Linus Torvalds Cc: Lorenzo Stoakes Cc: Maxime Coquelin Cc: "Michael S. Tsirkin" Cc: Michal Hocko Cc: Pekka Enberg Cc: Roman Gushchin Cc: Uladzislau Rezki (Sony) Cc: Xie Yongji Cc: Xuan Zhuo Cc: Yafang Shao Signed-off-by: Andrew Morton --- mm/page_alloc.c | 50 +++++++++++++++++++++++----------------------- 1 file changed, 25 insertions(+), 25 deletions(-) --- a/mm/page_alloc.c~mm-warn-about-illegal-__gfp_nofail-usage-in-a-more-appropriate-location-and-manner +++ a/mm/page_alloc.c @@ -3039,12 +3039,6 @@ struct page *rmqueue(struct zone *prefer { struct page *page; - /* - * We most definitely don't want callers attempting to - * allocate greater than order-1 page units with __GFP_NOFAIL. - */ - WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1)); - if (likely(pcp_allowed_order(order))) { page = rmqueue_pcplist(preferred_zone, zone, order, migratetype, alloc_flags); @@ -4182,6 +4176,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, u { bool can_direct_reclaim = gfp_mask & __GFP_DIRECT_RECLAIM; bool can_compact = gfp_compaction_allowed(gfp_mask); + bool nofail = gfp_mask & __GFP_NOFAIL; const bool costly_order = order > PAGE_ALLOC_COSTLY_ORDER; struct page *page = NULL; unsigned int alloc_flags; @@ -4194,6 +4189,25 @@ __alloc_pages_slowpath(gfp_t gfp_mask, u unsigned int zonelist_iter_cookie; int reserve_flags; + if (unlikely(nofail)) { + /* + * We most definitely don't want callers attempting to + * allocate greater than order-1 page units with __GFP_NOFAIL. + */ + WARN_ON_ONCE(order > 1); + /* + * Also we don't support __GFP_NOFAIL without __GFP_DIRECT_RECLAIM, + * otherwise, we may result in lockup. + */ + WARN_ON_ONCE(!can_direct_reclaim); + /* + * PF_MEMALLOC request from this context is rather bizarre + * because we cannot reclaim anything and only can loop waiting + * for somebody to do a work for us. + */ + WARN_ON_ONCE(current->flags & PF_MEMALLOC); + } + restart: compaction_retries = 0; no_progress_loops = 0; @@ -4411,30 +4425,16 @@ nopage: * Make sure that __GFP_NOFAIL request doesn't leak out and make sure * we always retry */ - if (gfp_mask & __GFP_NOFAIL) { + if (unlikely(nofail)) { /* - * All existing users of the __GFP_NOFAIL are blockable, so warn - * of any new users that actually require GFP_NOWAIT + * Lacking direct_reclaim we can't do anything to reclaim memory, + * we disregard these unreasonable nofail requests and still + * return NULL */ - if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask)) + if (!can_direct_reclaim) goto fail; /* - * PF_MEMALLOC request from this context is rather bizarre - * because we cannot reclaim anything and only can loop waiting - * for somebody to do a work for us - */ - WARN_ON_ONCE_GFP(current->flags & PF_MEMALLOC, gfp_mask); - - /* - * non failing costly orders are a hard requirement which we - * are not prepared for much so let's warn about these users - * so that we can identify them and convert them to something - * else. - */ - WARN_ON_ONCE_GFP(costly_order, gfp_mask); - - /* * Help non-failing allocations by giving some access to memory * reserves normally used for high priority non-blocking * allocations but do not use ALLOC_NO_WATERMARKS because this _ Patches currently in -mm which might be from v-songbaohua@oppo.com are mm-extend-usage-parameter-so-that-cluster_swap_free_nr-can-be-reused.patch mm-swap-add-nr-argument-in-swapcache_prepare-and-swapcache_clear-to-support-large-folios.patch mm-swap-add-nr-argument-in-swapcache_prepare-and-swapcache_clear-to-support-large-folios-fix.patch mm-rename-instances-of-swap_info_struct-to-meaningful-si.patch mm-attempt-to-batch-free-swap-entries-for-zap_pte_range.patch mm-attempt-to-batch-free-swap-entries-for-zap_pte_range-fix.patch mm-override-mthp-enabled-defaults-at-kernel-cmdline-fix.patch mm-count-the-number-of-anonymous-thps-per-size.patch mm-count-the-number-of-partially-mapped-anonymous-thps-per-size.patch mm-add-nr-argument-in-mem_cgroup_swapin_uncharge_swap-helper-to-support-large-folios.patch mm-document-__gfp_nofail-must-be-blockable.patch mm-warn-about-illegal-__gfp_nofail-usage-in-a-more-appropriate-location-and-manner.patch