All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: stable@vger.kernel.org
Cc: linux-hardening@vger.kernel.org, Kees Cook <kees@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ricardo Ribalda <ribalda@chromium.org>,
	Richard Fitzgerald <rf@opensource.cirrus.com>,
	Ben Dooks <ben.dooks@codethink.co.uk>,
	Eric Biggers <ebiggers@kernel.org>
Subject: [PATCH 6.18 3/4] default_gfp(): avoid using the "newfangled" __VA_OPT__ trick
Date: Thu,  9 Jul 2026 00:33:00 -0400	[thread overview]
Message-ID: <20260709043301.142931-4-ebiggers@kernel.org> (raw)
In-Reply-To: <20260709043301.142931-1-ebiggers@kernel.org>

From: Linus Torvalds <torvalds@linux-foundation.org>

commit 551d44200152cb26f75d2ef990aeb6185b7e37fd upstream.

The default_gfp() helper that I added is not wrong, but it turns out
that it causes unnecessary headaches for 'sparse' which doesn't support
the use of __VA_OPT__ (introduced in C++20 and C23, and supported by gcc
and clang for a long time).

We do already use __VA_OPT__ in some other cases in the kernel (drm/xe
and btrfs), but it has been fairly limited.  Now it triggers for pretty
much everything, and sparse ends up not working at all.

We can use the traditional gcc ',##__VA_ARGS__' syntax instead: it may
not be the "C standard" way and is slightly less natural in this
context, but it is the traditional model for this and avoids the sparse
problem.

Reported-and-tested-by: Ricardo Ribalda <ribalda@chromium.org>
Reported-and-tested-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reported-by: Ben Dooks <ben.dooks@codethink.co.uk>
Fixes: e19e1b480ac7 ("add default_gfp() helper macro and use it in the new *alloc_obj() helpers")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
 include/linux/gfp.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 09559f7126ac..647b3db8a757 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -14,8 +14,8 @@ struct vm_area_struct;
 struct mempolicy;
 
 /* Helper macro to avoid gfp flags if they are the default one */
-#define __default_gfp(a,...) a
-#define default_gfp(...) __default_gfp(__VA_ARGS__ __VA_OPT__(,) GFP_KERNEL)
+#define __default_gfp(a,b,...) b
+#define default_gfp(...) __default_gfp(,##__VA_ARGS__,GFP_KERNEL)
 
 /* Convert GFP flags to their corresponding migrate type */
 #define GFP_MOVABLE_MASK (__GFP_RECLAIMABLE|__GFP_MOVABLE)
-- 
2.55.0


  parent reply	other threads:[~2026-07-09  4:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09  4:32 [PATCH 6.18 0/4] Backport the one-arg k*alloc_obj() APIs Eric Biggers
2026-07-09  4:32 ` [PATCH 6.18 1/4] slab: Introduce kmalloc_flex() and family Eric Biggers
2026-07-09  4:32 ` [PATCH 6.18 2/4] add default_gfp() helper macro and use it in the new *alloc_obj() helpers Eric Biggers
2026-07-09  4:33 ` Eric Biggers [this message]
2026-07-09  4:33 ` [PATCH 6.18 4/4] slab: recognize @GFP parameter as optional in kernel-doc Eric Biggers
2026-07-09 13:07   ` Greg KH
2026-07-10 21:03 ` [PATCH 6.18 0/4] Backport the one-arg k*alloc_obj() APIs Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260709043301.142931-4-ebiggers@kernel.org \
    --to=ebiggers@kernel.org \
    --cc=ben.dooks@codethink.co.uk \
    --cc=kees@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=rf@opensource.cirrus.com \
    --cc=ribalda@chromium.org \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.