From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: Christoph Hellwig <hch@infradead.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: arm64: kernel/sys.c - silence initialization warnings.
Date: Mon, 15 Mar 2021 20:30:39 -0400 [thread overview]
Message-ID: <96852.1615854639@turing-police> (raw)
In-Reply-To: <20210315192300.GA154861@infradead.org>
On Mon, 15 Mar 2021 19:23:00 -0000, Christoph Hellwig said:
> On Mon, Mar 15, 2021 at 11:14:34AM +0000, Catalin Marinas wrote:
> > We do similar initialisation in arch/arm64/kernel/sys32.c and
> > arch/arm64/kernel/traps.c for example. It's a pretty common pattern
> > throughout the kernel.
> >
> > So we either treat W=1 output as diff against the vanilla kernel when
> > checking new patches or we remove override-init altogether from W=1.
> > Mark Rutland pointed me to an older thread:
>
> Please just remove the override-init warning, it is not helpful at all.
The tl;dr: Christoph is *probably* correct that it's not flagging any actual
bugs. And since *my* interest is "get the kernel tree to a point where W=1
or sparse throwing a warning is something worth looking at", I'm not opposed
to a patch to remove it from W=1 tree-wide if it has essentially zero chance of
flagging an actual bug.
The longer version:
So I did a quick analysis...
For an x86_64 allmodconfig, there's not that many left:
16 drivers/ata/ahci.h
1 drivers/ata/pata_atiixp.c
1 drivers/ata/pata_cs5520.c
1 drivers/ata/pata_cs5530.c
1 drivers/ata/pata_sc1200.c
1 drivers/ata/pata_serverworks.c
1 drivers/ata/sata_mv.c
4 drivers/ata/sata_nv.c
1 drivers/ata/sata_sil24.c
1 drivers/block/drbd/drbd_main.c
6 drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h
2 drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_sh_mask.h
1 drivers/input/serio/i8042-x86ia64io.h
1 include/linux/blkdev.h
1 kernel/bpf/btf.c
4 kernel/time/hrtimer.c
1 lib/errname.c
The drivers/ata *.c warnings all appear to be the same type of thing:
static struct scsi_host_template serverworks_osb4_sht = {
ATA_BMDMA_SHT(DRV_NAME),
.sg_tablesize = LIBATA_DUMB_MAX_PRD,
};
The preprocessor macro defining the struct contents, and then
overriding one predefined value. So that's half of x64_64 done right there.
There's a few corners still need looking at, like why drivers/ata/ahci.h
throws 16 warnings on x64, but 30 on arm and 28 on arm64, and why
there's 4 warnings on include/linux/stddef.h on arm64 but not arm or x86.
But the number is certainly small enough that it's only a day or two's work
at most to check every single one. If I go through the rest of x86 and arm
and they're all legit, I'll send a patch to nuke it kernel-wide rather than piecemeal.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: Christoph Hellwig <hch@infradead.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: arm64: kernel/sys.c - silence initialization warnings.
Date: Mon, 15 Mar 2021 20:30:39 -0400 [thread overview]
Message-ID: <96852.1615854639@turing-police> (raw)
In-Reply-To: <20210315192300.GA154861@infradead.org>
On Mon, 15 Mar 2021 19:23:00 -0000, Christoph Hellwig said:
> On Mon, Mar 15, 2021 at 11:14:34AM +0000, Catalin Marinas wrote:
> > We do similar initialisation in arch/arm64/kernel/sys32.c and
> > arch/arm64/kernel/traps.c for example. It's a pretty common pattern
> > throughout the kernel.
> >
> > So we either treat W=1 output as diff against the vanilla kernel when
> > checking new patches or we remove override-init altogether from W=1.
> > Mark Rutland pointed me to an older thread:
>
> Please just remove the override-init warning, it is not helpful at all.
The tl;dr: Christoph is *probably* correct that it's not flagging any actual
bugs. And since *my* interest is "get the kernel tree to a point where W=1
or sparse throwing a warning is something worth looking at", I'm not opposed
to a patch to remove it from W=1 tree-wide if it has essentially zero chance of
flagging an actual bug.
The longer version:
So I did a quick analysis...
For an x86_64 allmodconfig, there's not that many left:
16 drivers/ata/ahci.h
1 drivers/ata/pata_atiixp.c
1 drivers/ata/pata_cs5520.c
1 drivers/ata/pata_cs5530.c
1 drivers/ata/pata_sc1200.c
1 drivers/ata/pata_serverworks.c
1 drivers/ata/sata_mv.c
4 drivers/ata/sata_nv.c
1 drivers/ata/sata_sil24.c
1 drivers/block/drbd/drbd_main.c
6 drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h
2 drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_sh_mask.h
1 drivers/input/serio/i8042-x86ia64io.h
1 include/linux/blkdev.h
1 kernel/bpf/btf.c
4 kernel/time/hrtimer.c
1 lib/errname.c
The drivers/ata *.c warnings all appear to be the same type of thing:
static struct scsi_host_template serverworks_osb4_sht = {
ATA_BMDMA_SHT(DRV_NAME),
.sg_tablesize = LIBATA_DUMB_MAX_PRD,
};
The preprocessor macro defining the struct contents, and then
overriding one predefined value. So that's half of x64_64 done right there.
There's a few corners still need looking at, like why drivers/ata/ahci.h
throws 16 warnings on x64, but 30 on arm and 28 on arm64, and why
there's 4 warnings on include/linux/stddef.h on arm64 but not arm or x86.
But the number is certainly small enough that it's only a day or two's work
at most to check every single one. If I go through the rest of x86 and arm
and they're all legit, I'll send a patch to nuke it kernel-wide rather than piecemeal.
next prev parent reply other threads:[~2021-03-16 0:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 9:55 arm64: kernel/sys.c - silence initialization warnings Valdis Klētnieks
2021-03-12 9:55 ` Valdis Klētnieks
2021-03-15 11:14 ` Catalin Marinas
2021-03-15 11:14 ` Catalin Marinas
2021-03-15 19:23 ` Christoph Hellwig
2021-03-15 19:23 ` Christoph Hellwig
2021-03-16 0:30 ` Valdis Klētnieks [this message]
2021-03-16 0:30 ` Valdis Klētnieks
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=96852.1615854639@turing-police \
--to=valdis.kletnieks@vt.edu \
--cc=catalin.marinas@arm.com \
--cc=hch@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=will@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.