From: Guenter Roeck <linux@roeck-us.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Randy Dunlap <rdunlap@infradead.org>,
Helge Deller <deller@gmx.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-parisc@vger.kernel.org,
James Bottomley <James.Bottomley@hansenpartnership.com>,
John David Anglin <dave.anglin@bell.net>
Subject: Re: [GIT PULL] parisc architecture warning fix for kernel v5.15-rc2
Date: Thu, 16 Sep 2021 18:37:58 -0700 [thread overview]
Message-ID: <20210917013758.GA2520170@roeck-us.net> (raw)
In-Reply-To: <CAHk-=wh82AyhEQmNoWzqoFQjmwaQ8XiNL3u=knmr844LKkJQTg@mail.gmail.com>
On Thu, Sep 16, 2021 at 01:25:32PM -0700, Linus Torvalds wrote:
> On Thu, Sep 16, 2021 at 1:10 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On 9/16/21 1:03 PM, Randy Dunlap wrote:
> > >
> > > Already merged in the net tree.
> >
> > Ah, ok. Sorry for the noise (I already sent that patch).
>
> Well, I _just_ got the networking pull, so now that particular problem
> is solved in my tree too.
>
> There's a few more from your list, but I _think_ they are at least
> mostly pending in other trees and patch queues, so I'll ignore them
> unless told otherwise.
>
> But I've literally set aside this week to just get this mess sorted out.
>
> Not only do I think it's time to just *fix* these damn warning issues,
> but usually the week after rc1 is somewhat quiet since it takes a
> while for people to find regressions.
>
> So I have actually spent more time than I would normally consider
> healthy on code that I in any normal situation wouldn't care about at
> all.
>
> (I realize that Arnd and Guenther are now scoffing at my "normally
> consider healthy" since they have put even more time into this, but
> hey, I usually actively try to avoid reading grotty code in areas I
> don't actually care for).
>
> So if somebody is aware of some warning situation that still remains
> and doesn't seem to have any movement, please point me at all. Maybe
> we can't force-enable -Wall, but I want us to be really really close.
>
Let's say the list is getting small enough to be able to keep track.
Below is my current list of -Werror related build errors, as of
v5.15-rc1-164-gbdb575f87217.
Guenter
---
drivers/spi/spi-tegra20-slink.c:1200:12: error: 'tegra_slink_runtime_resume' defined but not used [-Werror=unused-function]
1200 | static int tegra_slink_runtime_resume(struct device *dev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/spi/spi-tegra20-slink.c:1188:12: error: 'tegra_slink_runtime_suspend' defined but not used [-Werror=unused-function]
1188 | static int tegra_slink_runtime_suspend(struct device *dev)
Affected builds:
alpha:allmodconfig
m68k:allmodconfig
parisc:allmodconfig
s390:allmodconfig
Patch:
https://lore.kernel.org/lkml/20210907045358.2138282-1-linux@roeck-us.net/
Status:
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
[ I hope that doesn't mean we'll have to wait for v5.16 for a fix ]
---
In file included from arch/mips/include/asm/sibyte/sb1250.h:28,
from drivers/watchdog/sb_wdog.c:58:
arch/mips/include/asm/sibyte/bcm1480_scd.h:261: error: "M_SPC_CFG_CLEAR" redefined
In file included from arch/mips/include/asm/sibyte/sb1250.h:28,
from drivers/watchdog/sb_wdog.c:58:
arch/mips/include/asm/sibyte/bcm1480_scd.h:262: error: "M_SPC_CFG_ENABLE" redefined
Affected builds:
mips:allmodconfig
Patch:
https://lore.kernel.org/r/20210913073220.1159520-1-liu.yun@linux.dev
Status:
Waiting for pull request from Wim
---
drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c: In function 'nvkm_control_mthd_pstate_info':
drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c:60:35: error: overflow in conversion from 'int' to '__s8' {aka 'signed char'} changes value from '-251' to '5' [-Werror=overflow]
60 | args->v0.pwrsrc = -ENOSYS;
Affected builds:
parisc:allmodconfig
Background:
args->v0.pwrsrc is s8, -ENOSYS is -251 on parisc
Patch:
https://lore.kernel.org/lkml/20210908190817.1213486-1-linux@roeck-us.net/
Status:
No response as of 9/15 (or I missed it)
---
drivers/scsi/ncr53c8xx.c:8000:26: error: 'retrieve_from_waiting_list' defined but not used
Affected builds:
parisc:allmodconfig
Patch:
https://lore.kernel.org/r/YTfS/LH5vCN6afDW@ls3530
Status:
Applied to 5.15/scsi-fixes
---
arch/s390/kernel/syscall.c: In function '__do_syscall':
arch/s390/kernel/syscall.c:168:1: error: '__do_syscall' uses dynamic stack allocation
lib/test_kasan.c: In function 'kasan_alloca_oob_right':
lib/test_kasan.c:782:1: error: 'kasan_alloca_oob_right' uses dynamic stack allocation
lib/test_kasan.c: In function 'kasan_alloca_oob_left':
lib/test_kasan.c:767:1: error: 'kasan_alloca_oob_left' uses dynamic stack allocation
Affected builds:
s390:allmodconfig
Background:
s390 defines a configuration flag to mark dynamic stack allocations as
warnings. This causes a build failure with -Werror.
Patch:
https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=fixes&id=f5711f9df9242446feccf2bdb6fdc06a72ca1010
Status:
Queued in https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git#fixes
---
drivers/video/fbdev/omap2/omapfb/dss/dsi.c: In function 'dsi_dump_dsidev_irqs':
drivers/video/fbdev/omap2/omapfb/dss/dsi.c:1623:1: error: the frame size of 1104 bytes is larger than 1024 bytes
and many similar errors. Seen in xtensa:allmodconfig.
Background:
xtensa:allmodconfig enables KASAN which in turn increases stack size
requirements significantly.
Patch:
https://lore.kernel.org/lkml/20210912025235.3514761-1-linux@roeck-us.net/
Status:
Queued in https://www.ozlabs.org/~akpm/mmotm/
prev parent reply other threads:[~2021-09-17 1:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-16 15:29 [GIT PULL] parisc architecture warning fix for kernel v5.15-rc2 Helge Deller
2021-09-16 18:25 ` pr-tracker-bot
2021-09-16 19:45 ` Guenter Roeck
2021-09-16 20:03 ` Randy Dunlap
2021-09-16 20:10 ` Guenter Roeck
2021-09-16 20:25 ` Linus Torvalds
2021-09-17 1:37 ` Guenter Roeck [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=20210917013758.GA2520170@roeck-us.net \
--to=linux@roeck-us.net \
--cc=James.Bottomley@hansenpartnership.com \
--cc=dave.anglin@bell.net \
--cc=deller@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=rdunlap@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox