From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: linux-sparse@vger.kernel.org, Al Viro <viro@ftp.linux.org.uk>
Subject: Re: [PATCH] Handle SForced in storage_modifiers
Date: Mon, 14 Nov 2016 21:04:48 +0100 [thread overview]
Message-ID: <20161114200447.GA15866@macbook.local> (raw)
In-Reply-To: <1479150736-28392-1-git-send-email-jlayton@redhat.com>
On Mon, Nov 14, 2016 at 02:12:16PM -0500, Jeff Layton wrote:
> We have been seeing errors like this for a while now in the sparse
> Fedora package, when doing kernel builds:
>
> ./include/linux/err.h:53:25: warning: dereference of noderef expression
> ./include/linux/err.h:35:16: warning: dereference of noderef expression
>
> This spews all over the build because this comes from IS_ERR(), which
> is called everywhere. Even odder, it turns out that if we build the
> package with -fpic turned off, then it works fine.
>
> With some brute-force debugging, I think I've finally found the cause.
> This array is missing the SForced element. When this is added then the
> problem goes away.
>
> As to why this goes away when -fpic is removed, I can only assume that
> we get lucky with the memory layout and have a zeroed out region just
> beyond the end of the array.
>
> Fixes: 3829c4d8b097776e6b3472290a9fae08a705ab7a
> Cc: Al Viro <viro@ftp.linux.org.uk>
> Signed-off-by: Jeff Layton <jlayton@redhat.com>
> ---
> parse.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/parse.c b/parse.c
> index 205e12644a6c..b290ff2636f2 100644
> --- a/parse.c
> +++ b/parse.c
> @@ -1286,7 +1286,8 @@ static unsigned long storage_modifiers(struct decl_state *ctx)
> [SAuto] = MOD_AUTO,
> [SExtern] = MOD_EXTERN,
> [SStatic] = MOD_STATIC,
> - [SRegister] = MOD_REGISTER
> + [SRegister] = MOD_REGISTER,
> + [SForced] = 0
> };
> return mod[ctx->storage_class] | (ctx->is_inline ? MOD_INLINE : 0)
> | (ctx->is_tls ? MOD_TLS : 0);
> --
Humm,
The array is statically initialized and never modified,
your patch shouldn't change anything, and this regardless of
the memory layout or compiler options.
Luc Van Oostenryck
next prev parent reply other threads:[~2016-11-14 20:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-14 19:12 [PATCH] Handle SForced in storage_modifiers Jeff Layton
2016-11-14 20:04 ` Luc Van Oostenryck [this message]
2016-11-14 20:17 ` Linus Torvalds
2016-11-14 20:21 ` Luc Van Oostenryck
2016-11-15 1:00 ` Christopher Li
2016-11-15 2:07 ` Jeff Layton
2016-11-16 22:28 ` Christopher Li
2016-11-17 12:43 ` Jeff Layton
2017-01-05 6:39 ` Luc Van Oostenryck
2016-11-15 4:30 ` Josh Triplett
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=20161114200447.GA15866@macbook.local \
--to=luc.vanoostenryck@gmail.com \
--cc=jlayton@redhat.com \
--cc=linux-sparse@vger.kernel.org \
--cc=viro@ftp.linux.org.uk \
/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).