From: Al Viro <viro@zeniv.linux.org.uk>
To: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fix cast of gfp_t to ulong in __def_gfpflag_names
Date: Thu, 5 Dec 2019 02:08:19 +0000 [thread overview]
Message-ID: <20191205020819.GJ4203@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20191204175425.71855-1-luc.vanoostenryck@gmail.com>
On Wed, Dec 04, 2019 at 06:54:25PM +0100, Luc Van Oostenryck wrote:
> The macro '__def_gfpflag_names' is used to define arrays of
> struct trace_print_flags. This structure is defined as being
> a pair of 'unsigned long' - 'const char *'.
>
> However, the macro __def_gfpflag_names is used to for GFP flags
> and thus take entries of type gfp_t (plus their name) which
> is a bitwise type, non-convertible to usual integers.
> These entries are casted to 'unsigned long' but this doesn't
> prevent Sparse to rughtfully complain:
> warning: cast from restricted gfp_t
>
> The correct way to cast a bitwise type to a normal integer
> (which is OK here) is to use '__force'.
>
> So, fix the cast by adding the '__force' required for such casts.
Ugh...
> - {(unsigned long)GFP_TRANSHUGE, "GFP_TRANSHUGE"}, \
<plenty of such>
> + {(__force ulong)GFP_TRANSHUGE, "GFP_TRANSHUGE"}, \
# operator is there for purpose; as in
#define FOO(name) {(__force unsigned long)name, #name}
with those becoming
#define __def_gfpflag_names \
FOO(GFP_TRANSHUGE), \
FOO(GFP_TRANSHUGE_LIGHT), \
etc.
prev parent reply other threads:[~2019-12-05 2:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-04 17:54 [PATCH] fix cast of gfp_t to ulong in __def_gfpflag_names Luc Van Oostenryck
2019-12-05 2:08 ` Al Viro [this message]
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=20191205020819.GJ4203@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.vanoostenryck@gmail.com \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.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.