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 5BF50C48BF6 for ; Mon, 26 Feb 2024 16:13:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C98DF44017B; Mon, 26 Feb 2024 11:13:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C4773440147; Mon, 26 Feb 2024 11:13:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF30644017B; Mon, 26 Feb 2024 11:13:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9B6D4440147 for ; Mon, 26 Feb 2024 11:13:25 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 443171A0922 for ; Mon, 26 Feb 2024 16:13:25 +0000 (UTC) X-FDA: 81834449970.07.A770620 Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) by imf26.hostedemail.com (Postfix) with ESMTP id 9E3C1140007 for ; Mon, 26 Feb 2024 16:13:22 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BQPsvERZ; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708964002; 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=TW2P7s5GOudhG2wB4Rb+S+Sqx8F90ikdbK5TGYSYqGw=; b=eQ/chp/LCwA42AgqwTt3hsDB03RNatD3rI4pjJVP6C4fpLI+2w/8yvr0+RyEpKXsTQ0Iaq FP+mXEQIM8mNXJcx2jrHB8+V1/0XseDD8vtcONOkCnxDVGcZwEa4EuwEhlfZCTFh0Vw3JX IARi9mKwrym3t8sMEgYmxUoZYdsYUH4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708964002; a=rsa-sha256; cv=none; b=aaA916CrxitrSKCxvKRCwXYh+J0pWre5Jgl0v4anBUoOlawUT55qGcRkgBbfb6AV8ozptJ NN36oGF5ZIG2UsWDD+hTz4GRwmg5tiPkAKgt8woze5RLJFnbdEQfWZwNZzKk90nsYAknEk VEmOxu2Jxj+gOzMMBtkWI2t89IGY9BY= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BQPsvERZ; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.219.171 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yb1-f171.google.com with SMTP id 3f1490d57ef6-dc74435c428so2769309276.2 for ; Mon, 26 Feb 2024 08:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708964002; x=1709568802; 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=TW2P7s5GOudhG2wB4Rb+S+Sqx8F90ikdbK5TGYSYqGw=; b=BQPsvERZvci0fnWmvJqZlEJtF5DszU+Gd1ojQLJzc8EdmdFM3JLSPzFt2vWEdMPSco qKEDqf4q4JxxDZLmQjA8epalr+78pL+H6sjZL4/pnUK1YkX8lbh71jkGhehmSb2qvhtd nzNJhGs6HlmGxqVjCSN+z5mPujpA98u+/Xyo7S5hhA1LULJ9EaaQrUntWHidzbs58NBi cuQ8UBDcsKrDd9F8I8DKUzsTbFLKQmckIWJcUqJtv/rbHwDMQLKPEFumaI71xoELrcn9 rpIHcVJlTO1u7cnWq4Cs4gy0xWJBSu+Aht9Utv3OE8Cf991e/mLLglFPUhaTgmmyG4XP AY9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708964002; x=1709568802; 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=TW2P7s5GOudhG2wB4Rb+S+Sqx8F90ikdbK5TGYSYqGw=; b=Oh1rLp1yFu2swOf+NHa7xgEDhlmQ4AtyGjBBoMafrVLARZVyizVQD590rnyYoMXaa+ L+74Oo+SM/9e8E61Pnq+HHVA0IawZPutN+J6sYT7dRh3rS+UNGYnrTt97VGmIkfB0TdY T7ezKizbHYm5aepR9gnY41bJ+ykR46au1FKyZjEMDeDqnnUw2LfZSF7uR2YK5fPiCzSm yvZsqTq6lN9Xi/cSN3SNtBgI2rSOr3KiK2TfyRYKZ+BWlgJTOEmG+EatHUXtFLM7C7pc HlqqPUr8A++IZMJ70vs2kxLimCYe+B9TfVkQ/97P9xlfFzVbDNbaC9Da/BHdYSks7A8o KgQw== X-Forwarded-Encrypted: i=1; AJvYcCUdHO0JfuEwlZ54rnUnEq091EDel0G0E1BWbBNajUUZj2O0flKn5VfyBSANOGghqpkxXAqdCJynd6CDcOBTxxp7Iu0= X-Gm-Message-State: AOJu0YxJJcx571Tn/yqBIs6QxovEAwYXQ2qqX+OJsTfe2chwP7rDxjRe geCbEcfyunGulcxS/U7iO2jgleWoaEUza41VQP/I5fg59a46Cv1AeBX4kaifHY5EHoPgThDosnx U+JWB+NTDHAYsFTdbdn6XC3nedMGRBj5YPYcx X-Google-Smtp-Source: AGHT+IE9eZNSED/rVpI8+NxOvuy5es9uemnJbcDcVT26wGQR0+v2/KDTMV/LlFJZ6uABBH6ioDdEsR937b/kK1g9ugY= X-Received: by 2002:a25:94c:0:b0:dc6:c617:7ca with SMTP id u12-20020a25094c000000b00dc6c61707camr4740121ybm.29.1708964001501; Mon, 26 Feb 2024 08:13:21 -0800 (PST) MIME-Version: 1.0 References: <20240224015800.2569851-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 26 Feb 2024 08:13:10 -0800 Message-ID: Subject: Re: [PATCH v5 1/1] mm: enumerate all gfp flags To: Michal Hocko Cc: Christophe JAILLET , akpm@linux-foundation.org, kent.overstreet@linux.dev, petr@tesarici.cz, keescook@chromium.org, pasha.tatashin@soleen.com, kernel-team@android.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: togqbkggzupdh11c8n3zdrni6p45iota X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 9E3C1140007 X-Rspam-User: X-HE-Tag: 1708964002-538466 X-HE-Meta: U2FsdGVkX18OTt9O8LHEuaLdXvDoJUjqeyn1Qzkl5YT3lyk3RIO6LtQqSWhnPFbyxcYL6X+suO2GzpdaVyVCtkyL9Vzyc3sQycJT7KPLo1ogQHXZPS+y+iTY77icSdGg32Fxkcp3iUBF00wFfvSL3jdi7C4m2tzaiiGodBb+6I0OhYInvz3ofx6UEctDRNuNKC/pdiz77Riu4Jq7RKKA3nvFRwZVCZtsyP7O44B1rYSOFuHNhf6f0JmzGt/2busippIgfe/p7ijLqAGHJWMxYRx4mcWR9U/wwkvBakrDiXGFsEj2FKEOE62CHzf3fzFU14Ju+vk65dLhhV+wO9sduWNjMypQCl+XzyAJmpZfCqCVrwkwBt4rXnsqovqwpomQerJjmSPi9j2zEu1fLRvnwwe2G4CfDbWbzaBjQUl203b8IR4i6Msyu7dlmZK6m0oGPqWnKPYvTRmXUAYHBG43iUsqVUFkpXO3JcK+q7vdZFx+jlMf0Z7BQB92jausHmuKSfQwnz2j8UrhWLp4Vic+KkyrOggjdz2Y6/DxPLUrkT31IGmCAOVhk4GPmrJBoDb+H4YrUfpA2j0jC3rxC97VXa2vdcoainqvjz3ZGEIEnJrtF/ePBZxe9iRs21psfEfhE/bjHrSfTLygkGunjvdEdvXGBwqzPIBomtLWuBljJw3wq6nLs+tE0py1tvhrwabA43HjnbjjfFbzT6Mx3u1MGrQs5KACzokZc/54LHdHgUj7+fmdBH2YhRI/NQ+FjctNZPOjWXhPMr46lbvcpH6950XwJhttvYL7g76l/MpDSEDOe+9/g4Ppb2GPKewpHo3K4XB2vUaNfMEAn2QgZHt/19Vxn4siNfRQrjXLKeZ2xRUgwroj3QuixWlqOAj338kWfyiqsvB5CkVcTOoUzSqCgog0J5TsjJn6/cJKpUGZaew9atNG3ZZNDurLlFgSjHvBlcIXtaahq3qXWvRa1H2 h0g== 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, Feb 26, 2024 at 12:43=E2=80=AFAM Michal Hocko wro= te: > > On Sun 25-02-24 01:12:46, Suren Baghdasaryan wrote: > > On Sat, Feb 24, 2024 at 7:03=E2=80=AFAM Christophe JAILLET > > wrote: > > > > > > Le 24/02/2024 =C3=A0 02:58, Suren Baghdasaryan a =C3=A9crit : > > > > Introduce GFP bits enumeration to let compiler track the number of = used > > > > bits (which depends on the config options) instead of hardcoding th= em. > > > > That simplifies __GFP_BITS_SHIFT calculation. > > > > > > > > Suggested-by: Petr Tesa=C5=99=C3=ADk > > > > Signed-off-by: Suren Baghdasaryan > > > > Reviewed-by: Kees Cook > > > > Reviewed-by: Pasha Tatashin > > > > Acked-by: Michal Hocko > > > > --- > > > > Changes from v4 [1]: > > > > - Split from the series [2] as a stand-alone patch, per Michal Hock= o > > > > - Added Reviewed-by, per Pasha Tatashin > > > > - Added Acked-by, per Michal Hocko > > > > > > > > [1] https://lore.kernel.org/all/20240221194052.927623-7-surenb@goog= le.com/ > > > > [2] https://lore.kernel.org/all/20240221194052.927623-1-surenb@goog= le.com/ > > > > > > > > include/linux/gfp_types.h | 90 +++++++++++++++++++++++++++-------= ----- > > > > 1 file changed, 62 insertions(+), 28 deletions(-) > > > > > > > > diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h > > > > index 1b6053da8754..868c8fb1bbc1 100644 > > > > --- a/include/linux/gfp_types.h > > > > +++ b/include/linux/gfp_types.h > > > > @@ -21,44 +21,78 @@ typedef unsigned int __bitwise gfp_t; > > > > * include/trace/events/mmflags.h and tools/perf/builtin-kmem.c > > > > */ > > > > > > > > +enum { > > > > + ___GFP_DMA_BIT, > > > > + ___GFP_HIGHMEM_BIT, > > > > + ___GFP_DMA32_BIT, > > > > + ___GFP_MOVABLE_BIT, > > > > + ___GFP_RECLAIMABLE_BIT, > > > > + ___GFP_HIGH_BIT, > > > > + ___GFP_IO_BIT, > > > > + ___GFP_FS_BIT, > > > > + ___GFP_ZERO_BIT, > > > > + ___GFP_UNUSED_BIT, /* 0x200u unused */ > > > > > > Hi, > > > > > > what is the need to have this ___GFP_UNUSED_BIT now? > > > > Hi! > > We can remove it but then all values will shift. That should be safe > > to do now but I prefer one patch to do only one thing. We can add a > > separate patch to do further cleanup of unused values. > > Agreed! > > > > > + ___GFP_DIRECT_RECLAIM_BIT, > > > > + ___GFP_KSWAPD_RECLAIM_BIT, > > > > + ___GFP_WRITE_BIT, > > > > + ___GFP_NOWARN_BIT, > > > > + ___GFP_RETRY_MAYFAIL_BIT, > > > > + ___GFP_NOFAIL_BIT, > > > > + ___GFP_NORETRY_BIT, > > > > + ___GFP_MEMALLOC_BIT, > > > > + ___GFP_COMP_BIT, > > > > + ___GFP_NOMEMALLOC_BIT, > > > > + ___GFP_HARDWALL_BIT, > > > > + ___GFP_THISNODE_BIT, > > > > + ___GFP_ACCOUNT_BIT, > > > > + ___GFP_ZEROTAGS_BIT, > > > > +#ifdef CONFIG_KASAN_HW_TAGS > > > > + ___GFP_SKIP_ZERO_BIT, > > > > + ___GFP_SKIP_KASAN_BIT, > > > > +#endif > > > > +#ifdef CONFIG_LOCKDEP > > > > + ___GFP_NOLOCKDEP_BIT, > > > > +#endif > > > > + ___GFP_LAST_BIT > > > > +}; > > > > > > Does it make sense to have something like: > > > BUILD_BUG_ON(___GFP_LAST_BIT > BITS_PER_LONG, "blah"); > > > > I suppose that would not hurt, except gfp_t is unsigned int, not long. > > Something like this would work I think: > > > > BUILD_BUG_ON_MSG(___GFP_LAST_BIT > BITS_PER_TYPE(gfp_t), "GFP bit overf= low"); > > > > except I'm not sure where to put this check. One of the __init > > functions in page_alloc.c would probably work but none seem to be > > appropriate. mm_core_init() perhaps? Other ideas? > > Would that check add much? We currently cannot use the full width of the > gfp_t because radix tree code needs to fit also its own tag into the > same word (see radix_tree_init). If the radix tree constrain is lifted > then we should add something like the above. Ah, good point. That check in radix_tree_init() is already more strict than this one. Looks like we are covered. Thanks, Suren. > -- > Michal Hocko > SUSE Labs