From: Greg KH <gregkh@linuxfoundation.org>
To: Alexander Lobakin <alexandr.lobakin@intel.com>
Cc: linux-kernel@vger.kernel.org,
Masahiro Yamada <masahiroy@kernel.org>,
Michal Marek <michal.lkml@markovi.net>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Masami Hiramatsu <mhiramat@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
Petr Mladek <pmladek@suse.com>,
Joe Lawrence <joe.lawrence@redhat.com>,
linux-kbuild@vger.kernel.org, live-patching@vger.kernel.org,
lkp@intel.com, stable@vger.kernel.org
Subject: Re: [RFC PATCH 1/3] modpost: fix TO_NATIVE() with expressions and consts
Date: Thu, 18 Aug 2022 16:10:21 +0200 [thread overview]
Message-ID: <Yv5ITarFK9Z3bkhZ@kroah.com> (raw)
In-Reply-To: <20220818140153.1113308-1-alexandr.lobakin@intel.com>
On Thu, Aug 18, 2022 at 04:01:53PM +0200, Alexander Lobakin wrote:
> From: Greg KH <gregkh@linuxfoundation.org>
> Date: Thu, 18 Aug 2022 14:26:14 +0200
>
> > On Thu, Aug 18, 2022 at 01:53:04PM +0200, Alexander Lobakin wrote:
> > > Macro TO_NATIVE() directly takes a reference to its argument @x
> > > without making an intermediate variable. This makes compilers
> > > emit build warnings and errors if @x is an expression or a deref
> > > of a const pointer (when target Endianness != host Endianness):
> > >
> > > >> scripts/mod/modpost.h:87:18: error: lvalue required as unary '&' operand
> > > 87 | __endian(&(x), &(__x), sizeof(__x)); \
> > > | ^
> > > scripts/mod/sympath.c:19:25: note: in expansion of macro 'TO_NATIVE'
> > > 19 | #define t(x) TO_NATIVE(x)
> > > | ^~~~~~~~~
> > > scripts/mod/sympath.c:100:31: note: in expansion of macro 't'
> > > 100 | eh->e_shoff = t(h(eh->e_shoff) + off);
> > >
> > > >> scripts/mod/modpost.h:87:24: warning: passing argument 2 of '__endian'
> > > discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
> > > 87 | __endian(&(x), &(__x), sizeof(__x)); \
> > > | ^~~~~~
> > > scripts/mod/sympath.c:18:25: note: in expansion of macro 'TO_NATIVE'
> > > 18 | #define h(x) TO_NATIVE(x)
> > > | ^~~~~~~~~
> > > scripts/mod/sympath.c:178:48: note: in expansion of macro 'h'
> > > 178 | iter < end; iter = (void *)iter + h(eh->e_shentsize)) {
> >
> > How come this hasn't shown up in cross-builds today?
>
> It doesn't happen with the current code.
Great, so there is no bug that you are trying to fix :)
> > > Create a temporary variable, assign @x to it and don't use @x after
> > > that. This makes it possible to pass expressions as an argument.
> > > Also, do a cast-away for the second argument when calling __endian()
> > > to avoid 'discarded qualifiers' warning, as typeof() preserves
> > > qualifiers and makes compilers think that we're passing pointer
> > > to a const.
> > >
> > > Reported-by: kernel test robot <lkp@intel.com>
> > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > Cc: stable@vger.kernel.org # 4.9+
> >
> > Where are these build warnings showing up at that we don't see them
> > today, yet this is needed to go back to all stable trees?
>
> I thought all fixes should go to the applicable stable trees, am I
> wrong? If so, I'll drop the tag in the next spin.
But this isn't fixing a bug in the code today that anyone can hit, so
why would you mark it as such?
> I remember we had such discussion already regarding fixing stuff in
> modpost, which can happen only with never mainlained GCC LTO or with
> the in-dev code. At the end that fix made it into the stables IIRC.
I don't remember taking fixes for out-of-tree LTO stuff, but I shouldn't
have :)
thanks,
greg k-h
next prev parent reply other threads:[~2022-08-18 14:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-18 11:53 [RFC PATCH 0/3] kallsyms: add option to include relative filepaths into kallsyms Alexander Lobakin
2022-08-18 11:53 ` [RFC PATCH 1/3] modpost: fix TO_NATIVE() with expressions and consts Alexander Lobakin
2022-08-18 12:26 ` Greg KH
2022-08-18 14:01 ` Alexander Lobakin
2022-08-18 14:10 ` Greg KH [this message]
2022-08-18 15:07 ` Alexander Lobakin
2022-08-18 11:53 ` [RFC PATCH 2/3] [STUB] increase kallsyms length limit Alexander Lobakin
2022-08-18 12:23 ` Greg KH
2022-08-18 11:53 ` [RFC PATCH 3/3] kallsyms: add option to include relative filepaths into kallsyms Alexander Lobakin
2022-08-18 12:23 ` Greg KH
2022-08-18 13:56 ` Alexander Lobakin
2022-08-18 14:11 ` Greg KH
2022-08-19 10:50 ` Alexander Lobakin
2022-08-19 11:02 ` Greg KH
2022-08-19 15:00 ` Alexander Lobakin
2022-08-19 15:19 ` Greg KH
2022-08-18 12:20 ` [RFC PATCH 0/3] " Greg KH
2022-08-18 13:39 ` Alexander Lobakin
2022-08-22 14:40 ` Alexander Lobakin
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=Yv5ITarFK9Z3bkhZ@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alexandr.lobakin@intel.com \
--cc=anil.s.keshavamurthy@intel.com \
--cc=davem@davemloft.net \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=lkp@intel.com \
--cc=masahiroy@kernel.org \
--cc=mbenes@suse.cz \
--cc=mhiramat@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=naveen.n.rao@linux.ibm.com \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=stable@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).