Messages in this thread | | | Date | Wed, 11 May 2022 10:36:18 +0800 | Subject | Re: [PATCH 1/2] mm: fix missing handler for __GFP_NOWARN | From | Qi Zheng <> |
| |
On 2022/5/11 10:32 AM, Andrew Morton wrote: > On Wed, 11 May 2022 10:19:48 +0800 Qi Zheng <zhengqi.arch@bytedance.com> wrote: > >> >> ,,, >>>> --- a/mm/internal.h >>>> +++ b/mm/internal.h >>>> @@ -35,6 +35,17 @@ struct folio_batch; >>>> /* Do not use these with a slab allocator */ >>>> #define GFP_SLAB_BUG_MASK (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK) >>>> >>>> +#define WARN_ON_ONCE_GFP(cond, gfp) ({ \ >>>> + static bool __section(".data.once") __warned; \ >>>> + int __ret_warn_once = !!(cond); \ >>>> + \ >>>> + if (unlikely(!(gfp & __GFP_NOWARN) && __ret_warn_once && !__warned)) { \ >>>> + __warned = true; \ >>>> + WARN_ON(1); \ >>>> + } \ >>>> + unlikely(__ret_warn_once); \ >>>> +}) >>> >>> I don't think WARN_ON_ONCE_GFP is a good name for this. But >>> WARN_ON_ONCE_IF_NOT_GFP_NOWARN is too long :( >>> >>> WARN_ON_ONCE_NOWARN might be better. No strong opinion here, really. >> >> I've thought about WARN_ON_ONCE_NOWARN, but I feel a little weird >> putting 'WARN' and 'NOWARN' together, how about WARN_ON_ONCE_IF_ALLOWED? > > I dunno. WARN_ON_ONCE_GFP isn't too bad I suppose. Add a comment over > the definition explaining it?
OK, I will add a comment to it.
> >>> >>>> @@ -4902,8 +4906,8 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, >>>> * We also sanity check to catch abuse of atomic reserves being used by >>>> * callers that are not in atomic context. >>>> */ >>>> - if (WARN_ON_ONCE((gfp_mask & (__GFP_ATOMIC|__GFP_DIRECT_RECLAIM)) == >>>> - (__GFP_ATOMIC|__GFP_DIRECT_RECLAIM))) >>>> + if (WARN_ON_ONCE_GFP((gfp_mask & (__GFP_ATOMIC|__GFP_DIRECT_RECLAIM)) == >>>> + (__GFP_ATOMIC|__GFP_DIRECT_RECLAIM), gfp_mask)) >>>> gfp_mask &= ~__GFP_ATOMIC; >>>> >>>> retry_cpuset: >>> >>> I dropped this hunk - Neil's "mm: discard __GFP_ATOMIC" >>> (https://lkml.kernel.org/r/163712397076.13692.4727608274002939094@noble.neil.brown.name) >>> deleted this code. >>> >> >> This series is based on v5.18-rc5, I will rebase it to the latest next >> branch and check if there are any missing WARN_ON_ONCEs that are not >> being handled. > > Against git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm branch > mm-unstable, please. That ends up in linux-next, with a delay.
OK, will do.
-- Thanks, Qi
| |