From: Linus Torvalds <torvalds@linux-foundation.org>
To: Guenter Roeck <linux@roeck-us.net>,
"David S. Miller" <davem@davemloft.net>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Christian Koenig <christian.koenig@amd.com>,
Huang Rui <ray.huang@amd.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-sparc <sparclinux@vger.kernel.org>
Subject: Re: [PATCH] Enable '-Werror' by default for all kernel builds
Date: Mon, 6 Sep 2021 16:06:04 -0700 [thread overview]
Message-ID: <CAHk-=wi4NW3NC0xWykkw=6LnjQD6D_rtRtxY9g8gQAJXtQMi8A@mail.gmail.com> (raw)
In-Reply-To: <c3790fb9-b83f-9596-18a1-21ace987c850@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 2548 bytes --]
[ Adding some subsystem maintainers ]
On Mon, Sep 6, 2021 at 10:06 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> > But hopefully most cases are just "people haven't cared enough" and
> > easily fixed.
>
> We'll see. For my testbed I disabled the new configuration flag
> for the time being because its primary focus is boot tests, and
> there won't be any boot tests if images fail to build.
Sure, reasonable.
I've checked a few of the build errors by doing the appropriate cross
compiles, and it doesn't seem bad - but it does seem like we have a
number of really pointless long-standing warnings that should have
been fixed long ago.
For example, looking at sparc64, there are several build errors due to
those warnings now being fatal:
- drivers/gpu/drm/ttm/ttm_pool.c:386
This is a type mismatch error. It looks like __fls() on sparc64
returns 'int'. And the ttm_pool.c code assumes it returns 'unsigned
long'.
Oddly enough, the very line after that line does "min_t(unsigned
int" to get the types in line.
So the immediate reason is "sparc64 is different". But the deeper
reason seems to be that ttm_pool.c has odd type assumptions. But that
warning should have been fixed long ago, either way.
Christian/Huang? I get the feeling that both lines in that file
should use the min_t(). Hmm?
- drivers/input/joystick/analog.c:160
#warning Precise timer not defined for this architecture.
Unfortunate. I suspect that warning just has to be removed. It has
never caused anything to be fixed, it's old to the point of predating
the git history. Dmitry?
- at least a couple of stringop-overread errors. Attached is a
possible for for one of them.
The stringop overread is odd, because another one of them is
fs/qnx4/dir.c: In function ‘qnx4_readdir’:
fs/qnx4/dir.c:51:32: error: ‘strnlen’ specified bound 48 exceeds
source size 16 [-Werror=stringop-overread]
51 | size = strnlen(de->di_fname, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
but I'm not seeing why that one happens on sparc64, but not on arm64
or x86-64. There doesn't seem to be anything architecture-specific
anywhere in that area.
Funky.
Davem - attached patch compiles cleanly for me, but I'm not sure it's
necessarily the right thing to do, and I didn't check the code
generation. Maybe it screws up. Can somebody test on sparc64 and
perhaps think about it more than I did?
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 741 bytes --]
arch/sparc/kernel/mdesc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/sparc/kernel/mdesc.c b/arch/sparc/kernel/mdesc.c
index 8e645ddac58e..30f171b7b00c 100644
--- a/arch/sparc/kernel/mdesc.c
+++ b/arch/sparc/kernel/mdesc.c
@@ -39,6 +39,7 @@ struct mdesc_hdr {
u32 node_sz; /* node block size */
u32 name_sz; /* name block size */
u32 data_sz; /* data block size */
+ char data[];
} __attribute__((aligned(16)));
struct mdesc_elem {
@@ -612,7 +613,7 @@ EXPORT_SYMBOL(mdesc_get_node_info);
static struct mdesc_elem *node_block(struct mdesc_hdr *mdesc)
{
- return (struct mdesc_elem *) (mdesc + 1);
+ return (struct mdesc_elem *) mdesc->data;
}
static void *name_block(struct mdesc_hdr *mdesc)
next prev parent reply other threads:[~2021-09-06 23:06 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-06 14:26 [PATCH] Enable '-Werror' by default for all kernel builds Guenter Roeck
2021-09-06 16:12 ` Linus Torvalds
2021-09-06 16:18 ` Linus Torvalds
2021-09-06 17:05 ` Guenter Roeck
2021-09-06 23:06 ` Linus Torvalds [this message]
2021-09-06 23:49 ` Guenter Roeck
2021-09-07 1:12 ` Linus Torvalds
2021-09-07 2:29 ` Guenter Roeck
2021-09-07 15:50 ` Guenter Roeck
2021-09-07 8:56 ` Arnd Bergmann
2021-09-08 4:28 ` Guenter Roeck
2021-09-08 4:48 ` Al Viro
2021-09-08 5:14 ` Guenter Roeck
2021-09-08 7:11 ` Geert Uytterhoeven
2021-09-08 9:50 ` Arnd Bergmann
2021-09-08 10:10 ` Geert Uytterhoeven
2021-09-08 10:21 ` Geert Uytterhoeven
2021-09-08 12:42 ` Guenter Roeck
2021-09-08 13:19 ` Al Viro
2021-09-08 13:54 ` Guenter Roeck
2021-09-08 14:47 ` David Laight
2021-09-08 4:55 ` Linus Torvalds
2021-09-08 5:46 ` Guenter Roeck
2021-09-07 5:32 ` Huang Rui
2021-09-07 6:15 ` Christian König
2021-09-07 6:58 ` Geert Uytterhoeven
2021-09-07 2:30 ` Nathan Chancellor
2021-09-07 9:11 ` Arnd Bergmann
2021-09-07 9:11 ` Arnd Bergmann
2021-09-07 17:10 ` Linus Torvalds
2021-09-07 17:10 ` Linus Torvalds
2021-09-07 17:33 ` Linus Torvalds
2021-09-07 17:33 ` Linus Torvalds
2021-09-07 21:07 ` Harry Wentland
2021-09-08 3:52 ` Harry Wentland
2021-09-08 4:41 ` Linus Torvalds
2021-09-09 0:48 ` Harry Wentland
2021-09-07 17:48 ` Guenter Roeck
2021-09-07 19:12 ` Nathan Chancellor
2021-09-08 20:55 ` Nathan Chancellor
2021-09-08 20:55 ` Nathan Chancellor
2021-09-08 21:16 ` Guenter Roeck
2021-09-08 21:16 ` Guenter Roeck
2021-09-08 21:58 ` Marco Elver
2021-09-08 21:58 ` Marco Elver
2021-09-09 5:58 ` Christoph Hellwig
2021-09-09 5:58 ` Christoph Hellwig
2021-09-09 6:07 ` Guenter Roeck
2021-09-09 6:07 ` Guenter Roeck
2021-09-09 7:30 ` Christian König
2021-09-09 7:30 ` Christian König
2021-09-09 14:59 ` Guenter Roeck
2021-09-09 14:59 ` Guenter Roeck
2021-09-09 10:53 ` Marco Elver
2021-09-09 10:53 ` Marco Elver
2021-09-09 11:00 ` Arnd Bergmann
2021-09-09 11:00 ` Arnd Bergmann
2021-09-09 11:43 ` Marco Elver
2021-09-09 11:43 ` Marco Elver
2021-09-09 12:55 ` Arnd Bergmann
2021-09-09 12:55 ` Arnd Bergmann
2021-09-09 16:53 ` Linus Torvalds
2021-09-09 16:53 ` Linus Torvalds
2021-09-09 16:46 ` Linus Torvalds
2021-09-09 16:46 ` Linus Torvalds
2021-09-21 15:41 ` Arnd Bergmann
2021-09-21 15:41 ` Arnd Bergmann
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='CAHk-=wi4NW3NC0xWykkw=6LnjQD6D_rtRtxY9g8gQAJXtQMi8A@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=christian.koenig@amd.com \
--cc=davem@davemloft.net \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=ray.huang@amd.com \
--cc=sparclinux@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 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.