In my attempt to weed out all warnings in ARM defconfigs, this
is the latest installment of patches. Ideally these could all
go through the respective subsystem maintainer trees, but
for any patches I don't hear anything back on, I will just
merge them through the arm-soc tree.
Arnd
Arnd Bergmann (16):
ARM: warnings in arch/arm/include/asm/uaccess.h
ARM: binfmt_flat: unused variable 'persistent'
SCSI: ARM: ncr5380/oak uses no interrupts
SCSI: ARM: make fas216_dumpinfo function conditional
vfs: bogus warnings in fs/namei.c
mm/slob: use min_t() to compare ARCH_SLAB_MINALIGN
cgroup: fix warning when building without any subsys
ipvs: fix ip_vs_set_timeout debug messages
USB: EHCI: mark ehci_orion_conf_mbus_windows __devinit
clk: don't mark clkdev_add_table as init
pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops
video: mark nuc900fb_map_video_memory as __devinit
ARM: be really quiet when building with 'make -s'
ARM: pxa: armcore: fix PCI PIO warnings
spi/s3c64xx: use correct dma_transfer_direction type
ARM: pass -marm to gcc by default for both C and assembler
arch/arm/Makefile | 13 +++++++------
arch/arm/boot/Makefile | 10 +++++-----
arch/arm/common/it8152.c | 12 +++++++++---
arch/arm/include/asm/flat.h | 2 +-
arch/arm/include/asm/uaccess.h | 4 ++--
arch/arm/tools/Makefile | 2 +-
drivers/clk/clkdev.c | 2 +-
drivers/pcmcia/pxa2xx_sharpsl.c | 2 +-
drivers/scsi/arm/fas216.c | 2 +-
drivers/scsi/arm/oak.c | 1 +
drivers/spi/spi-s3c64xx.c | 2 +-
drivers/usb/host/ehci-orion.c | 2 +-
drivers/video/nuc900fb.c | 2 +-
fs/namei.c | 6 +++---
include/linux/cgroup.h | 2 +-
mm/slob.c | 6 +++---
net/netfilter/ipvs/ip_vs_ctl.c | 10 ++++++----
17 files changed, 45 insertions(+), 35 deletions(-)
Cc: "James E.J. Bottomley" <redacted>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Ben Blum <redacted>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Bryan Wu <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christoph Lameter <redacted>
Cc: Dave Martin <redacted>
Cc: David S. Miller <davem@davemloft.net>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Eric Miao <redacted>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Grant Likely <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Greg Ungerer <redacted>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Igor Grinberg <redacted>
Cc: Jan Kara <jack@suse.cz>
Cc: Jochen Friedrich <jochen@scram.de>
Cc: Julian Anastasov <ja@ssi.bg>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Kukjin Kim <redacted>
Cc: Li Zefan <redacted>
Cc: Michal Marek <redacted>
Cc: Mike Rapoport <redacted>
Cc: Mike Turquette <redacted>
Cc: Nicolas Pitre <redacted>
Cc: Pavel Machek <redacted>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Russell King <redacted>
Cc: Simon Horman <horms@verge.net.au>
Cc: Tejun Heo <tj@kernel.org>
Cc: Wan ZongShun <redacted>
Cc: coreteam at netfilter.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-fbdev at vger.kernel.org
Cc: linux-fsdevel at vger.kernel.org
Cc: linux-pcmcia at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-scsi at vger.kernel.org
Cc: linux-usb at vger.kernel.org
Cc: netdev at vger.kernel.org
Cc: netfilter-devel at vger.kernel.org
Cc: netfilter at vger.kernel.org
Cc: spi-devel-general at lists.sourceforge.net
--
1.7.10
The follow_link() function always initializes its *p argument,
or returns an error, but not all versions of gcc figure this
out, so we have to work around this using the uninitialized_var()
macro.
Without this patch, building with arm-linux-gnueabi-gcc-4.6 results in:
fs/namei.c: In function 'link_path_walk':
fs/namei.c:649:24: warning: 'cookie' may be used uninitialized in this function [-Wuninitialized]
fs/namei.c:1544:9: note: 'cookie' was declared here
fs/namei.c: In function 'path_lookupat':
fs/namei.c:649:24: warning: 'cookie' may be used uninitialized in this function [-Wuninitialized]
fs/namei.c:1934:10: note: 'cookie' was declared here
fs/namei.c: In function 'path_openat':
fs/namei.c:649:24: warning: 'cookie' may be used uninitialized in this function [-Wuninitialized]
fs/namei.c:2899:9: note: 'cookie' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel at vger.kernel.org
Cc: Jan Kara <jack@suse.cz>
---
fs/namei.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: Jan Kara <jack@suse.cz> Date: 2012-10-08 11:51:16
On Fri 05-10-12 16:55:19, Arnd Bergmann wrote:
The follow_link() function always initializes its *p argument,
or returns an error, but not all versions of gcc figure this
out, so we have to work around this using the uninitialized_var()
macro.
Well, I'm somewhat sceptical to this approach. I agree that bogus
warnings are not nice but later when the code is changed and possibly real
use without initialization is added, we won't notice it. Without changing
anything, we'd at least have a chance of catching it with gcc versions
which were clever enough to not warn with the original code. Or
alternatively if we unconditionally initialized the variable that would get
rid of the warning and made the code more future-proof (that's what I
usually end up doing)... I don't really care that much about the chosen
solution, Al is the one to decide. But I wanted to point out there are
downsides to your solution.
Honza
quoted hunk
Without this patch, building with arm-linux-gnueabi-gcc-4.6 results in:
fs/namei.c: In function 'link_path_walk':
fs/namei.c:649:24: warning: 'cookie' may be used uninitialized in this function [-Wuninitialized]
fs/namei.c:1544:9: note: 'cookie' was declared here
fs/namei.c: In function 'path_lookupat':
fs/namei.c:649:24: warning: 'cookie' may be used uninitialized in this function [-Wuninitialized]
fs/namei.c:1934:10: note: 'cookie' was declared here
fs/namei.c: In function 'path_openat':
fs/namei.c:649:24: warning: 'cookie' may be used uninitialized in this function [-Wuninitialized]
fs/namei.c:2899:9: note: 'cookie' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel at vger.kernel.org
Cc: Jan Kara <jack@suse.cz>
---
fs/namei.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
The follow_link() function always initializes its *p argument,
or returns an error, but not all versions of gcc figure this
out, so we have to work around this using the uninitialized_var()
macro.
Well, I'm somewhat sceptical to this approach. I agree that bogus
warnings are not nice but later when the code is changed and possibly real
use without initialization is added, we won't notice it. Without changing
anything, we'd at least have a chance of catching it with gcc versions
which were clever enough to not warn with the original code. Or
alternatively if we unconditionally initialized the variable that would get
rid of the warning and made the code more future-proof (that's what I
usually end up doing)... I don't really care that much about the chosen
solution, Al is the one to decide. But I wanted to point out there are
downsides to your solution.
I'll drop the patch for now and won't send it from my tree then. I agree
that uninitialized_var() is not ideal, but none of the alternatives seemed
better.
With my latest compiler, I don't actually see the warnings any more, so
maybe someone fixed gcc instead, or this went away after another change.
I'll let you know if it comes back so we can discuss about a better fix then.
Arnd
The follow_link() function always initializes its *p argument,
or returns an error, but not all versions of gcc figure this
out, so we have to work around this using the uninitialized_var()
macro.
Well, I'm somewhat sceptical to this approach. I agree that bogus
warnings are not nice but later when the code is changed and possibly real
use without initialization is added, we won't notice it. Without changing
anything, we'd at least have a chance of catching it with gcc versions
which were clever enough to not warn with the original code. Or
alternatively if we unconditionally initialized the variable that would get
rid of the warning and made the code more future-proof (that's what I
usually end up doing)... I don't really care that much about the chosen
solution, Al is the one to decide. But I wanted to point out there are
downsides to your solution.
I'll drop the patch for now and won't send it from my tree then. I agree
that uninitialized_var() is not ideal, but none of the alternatives seemed
better.
With my latest compiler, I don't actually see the warnings any more, so
maybe someone fixed gcc instead, or this went away after another change.
I'll let you know if it comes back so we can discuss about a better fix then.
Update: I could actually reproduce the problem now, but it only happens when
building with 'gcc -s' (i.e. CONFIG_CC_OPTIMIZE_FOR_SIZE). It does happen
with both gcc-4.6 and with gcc-4.8, and on both x86-64 and ARM. An alternative
patch that would also make it go away is the variant below, but I think that's
even worse than the first version I suggested because it makes the binary
output slightly worse by adding an unnecessary initialization when building with
'make -s'.
Arnd
From: Jan Kara <jack@suse.cz> Date: 2012-10-09 13:43:20
On Tue 09-10-12 13:07:19, Arnd Bergmann wrote:
On Tuesday 09 October 2012, Arnd Bergmann wrote:
quoted
On Monday 08 October 2012, Jan Kara wrote:
quoted
On Fri 05-10-12 16:55:19, Arnd Bergmann wrote:
quoted
The follow_link() function always initializes its *p argument,
or returns an error, but not all versions of gcc figure this
out, so we have to work around this using the uninitialized_var()
macro.
Well, I'm somewhat sceptical to this approach. I agree that bogus
warnings are not nice but later when the code is changed and possibly real
use without initialization is added, we won't notice it. Without changing
anything, we'd at least have a chance of catching it with gcc versions
which were clever enough to not warn with the original code. Or
alternatively if we unconditionally initialized the variable that would get
rid of the warning and made the code more future-proof (that's what I
usually end up doing)... I don't really care that much about the chosen
solution, Al is the one to decide. But I wanted to point out there are
downsides to your solution.
I'll drop the patch for now and won't send it from my tree then. I agree
that uninitialized_var() is not ideal, but none of the alternatives seemed
better.
With my latest compiler, I don't actually see the warnings any more, so
maybe someone fixed gcc instead, or this went away after another change.
I'll let you know if it comes back so we can discuss about a better fix then.
Update: I could actually reproduce the problem now, but it only happens when
building with 'gcc -s' (i.e. CONFIG_CC_OPTIMIZE_FOR_SIZE). It does happen
with both gcc-4.6 and with gcc-4.8, and on both x86-64 and ARM. An alternative
patch that would also make it go away is the variant below, but I think that's
even worse than the first version I suggested because it makes the binary
output slightly worse by adding an unnecessary initialization when building with
'make -s'.
Hum, dumb compiler... I like this patch better and since the extra
initialization is on error path only, I don't think it matters. But
whatever Al likes better.
Honza
From: Al Viro <viro@ZenIV.linux.org.uk> Date: 2012-10-11 04:37:34
On Tue, Oct 09, 2012 at 01:07:19PM +0000, Arnd Bergmann wrote:
Update: I could actually reproduce the problem now, but it only happens when
building with 'gcc -s' (i.e. CONFIG_CC_OPTIMIZE_FOR_SIZE). It does happen
with both gcc-4.6 and with gcc-4.8, and on both x86-64 and ARM. An alternative
patch that would also make it go away is the variant below, but I think that's
even worse than the first version I suggested because it makes the binary
output slightly worse by adding an unnecessary initialization when building with
'make -s'.
I can live with that, provided that you give it sane commit message and
your s-o-b.
The follow_link() function always initializes its *p argument,
or returns an error, but when building with 'gcc -s', the compiler
gets confused by the __always_inline attribute to the function
and can no longer detect where the cookie was initialized.
The solution is to always initialize the pointer from follow_link,
even in the error path. When building with -O2, this has zero impact
on generated code and adds a single instruction in the error path
for a -Os build on ARM.
Without this patch, building with gcc-4.6 through gcc-4.8 and
CONFIG_CC_OPTIMIZE_FOR_SIZE results in:
fs/namei.c: In function 'link_path_walk':
fs/namei.c:649:24: warning: 'cookie' may be used uninitialized in this function [-Wuninitialized]
fs/namei.c:1544:9: note: 'cookie' was declared here
fs/namei.c: In function 'path_lookupat':
fs/namei.c:649:24: warning: 'cookie' may be used uninitialized in this function [-Wuninitialized]
fs/namei.c:1934:10: note: 'cookie' was declared here
fs/namei.c: In function 'path_openat':
fs/namei.c:649:24: warning: 'cookie' may be used uninitialized in this function [-Wuninitialized]
fs/namei.c:2899:9: note: 'cookie' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Sometimes we want the kernel build process to only print messages
on errors, e.g. in automated build testing. This uses the "kecho"
macro that the build system provides to hide a few informational
messages. Nothing changes for a regular "make" or "make V=1".
Without this patch, building any ARM kernel results in:
Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/zImage is ready
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <redacted>
Cc: Nicolas Pitre <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Michal Marek <redacted>
---
arch/arm/boot/Makefile | 10 +++++-----
arch/arm/tools/Makefile | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
From: Nicolas Pitre <hidden> Date: 2012-10-05 16:36:40
On Fri, 5 Oct 2012, Arnd Bergmann wrote:
Sometimes we want the kernel build process to only print messages
on errors, e.g. in automated build testing. This uses the "kecho"
macro that the build system provides to hide a few informational
messages. Nothing changes for a regular "make" or "make V=1".
Without this patch, building any ARM kernel results in:
Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/zImage is ready
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <redacted>
Cc: Nicolas Pitre <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Michal Marek <redacted>
The __devinit section is going away soon, but while it's
still there, we get a correct warning about
ehci_orion_conf_mbus_windows being discarded before
its caller, so it should be marked __devinit rather than
__init.
Without this patch, building dove_defconfig results in:
WARNING: drivers/usb/host/built-in.o(.devinit.text+0x8a4): Section mismatch in reference from the function ehci_orion_drv_probe() to the function .init.text:ehci_orion_conf_mbus_windows()
The function __devinit ehci_orion_drv_probe() references
a function __init ehci_orion_conf_mbus_windows().
If ehci_orion_conf_mbus_windows is only used by ehci_orion_drv_probe then
annotate ehci_orion_conf_mbus_windows with a matching annotation.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb at vger.kernel.org
---
drivers/usb/host/ehci-orion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Alan Stern <stern@rowland.harvard.edu> Date: 2012-10-05 18:05:35
On Fri, 5 Oct 2012, Arnd Bergmann wrote:
The __devinit section is going away soon, but while it's
still there, we get a correct warning about
ehci_orion_conf_mbus_windows being discarded before
its caller, so it should be marked __devinit rather than
__init.
Without this patch, building dove_defconfig results in:
WARNING: drivers/usb/host/built-in.o(.devinit.text+0x8a4): Section mismatch in reference from the function ehci_orion_drv_probe() to the function .init.text:ehci_orion_conf_mbus_windows()
The function __devinit ehci_orion_drv_probe() references
a function __init ehci_orion_conf_mbus_windows().
If ehci_orion_conf_mbus_windows is only used by ehci_orion_drv_probe then
annotate ehci_orion_conf_mbus_windows with a matching annotation.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb at vger.kernel.org
The it8152 PCI host used on the pxa/cm_x2xx machines
uses the old-style I/O window registration. This should
eventually get converted to pci_ioremap_io() but for
now, let's cast the IT8152_IO_BASE constant to an integer
type to get rid of the warnings.
Without this patch, building cm_x2xx_defconfig results in:
arch/arm/common/it8152.c: In function 'it8152_pci_setup':
arch/arm/common/it8152.c:287:18: warning: assignment makes integer from pointer without a cast [enabled by default]
arch/arm/common/it8152.c:288:16: warning: assignment makes integer from pointer without a cast [enabled by default]
arch/arm/common/it8152.c:291:17: warning: assignment makes integer from pointer without a cast [enabled by default]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Mike Rapoport <redacted>
Cc: Igor Grinberg <redacted>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Eric Miao <redacted>
---
arch/arm/common/it8152.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
From: Igor Grinberg <hidden> Date: 2012-10-05 15:32:56
On 10/05/12 16:55, Arnd Bergmann wrote:
The it8152 PCI host used on the pxa/cm_x2xx machines
uses the old-style I/O window registration. This should
eventually get converted to pci_ioremap_io() but for
now, let's cast the IT8152_IO_BASE constant to an integer
type to get rid of the warnings.
Without this patch, building cm_x2xx_defconfig results in:
arch/arm/common/it8152.c: In function 'it8152_pci_setup':
arch/arm/common/it8152.c:287:18: warning: assignment makes integer from pointer without a cast [enabled by default]
arch/arm/common/it8152.c:288:16: warning: assignment makes integer from pointer without a cast [enabled by default]
arch/arm/common/it8152.c:291:17: warning: assignment makes integer from pointer without a cast [enabled by default]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Mike Rapoport <redacted>
Cc: Igor Grinberg <redacted>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Eric Miao <redacted>
The ip_vs_set_timeout function sets timeouts for TCP and UDP, which
can be enabled independently at compile time. The debug message
always prints both timeouts that are passed into the function,
but if one is disabled, the message will show uninitialized data.
This splits the debug message into two separte IP_VS_DBG statements
that are in the same #ifdef section to ensure we only print the
text about what is actually going on.
Without this patch, building ARM ixp4xx_defconfig results in:
net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev at vger.kernel.org
Cc: Simon Horman <horms@verge.net.au>
Cc: Julian Anastasov <ja@ssi.bg>
Cc: netfilter-devel at vger.kernel.org
Cc: netfilter at vger.kernel.org
Cc: coreteam at netfilter.org
---
net/netfilter/ipvs/ip_vs_ctl.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
The ip_vs_set_timeout function sets timeouts for TCP and UDP, which
can be enabled independently at compile time. The debug message
always prints both timeouts that are passed into the function,
but if one is disabled, the message will show uninitialized data.
This splits the debug message into two separte IP_VS_DBG statements
that are in the same #ifdef section to ensure we only print the
text about what is actually going on.
Without this patch, building ARM ixp4xx_defconfig results in:
Are there any CONFIG_IP_VS_PROTO_xxx options in this
default config? It is a waste of memory if IPVS is compiled
without any protocols.
net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
There are many __ip_vs_get_timeouts callers but
just one calls memset(&t, 0, sizeof(t)) before that,
problem only for ip_vs_genl_set_config and ip_vs_set_timeout.
To be safe, can we move this memset into
__ip_vs_get_timeouts instead of playing games with defines?:
memset(t, 0, sizeof(*t));
This debug message will be more precise in showing the
changed values if we replace the __ip_vs_get_timeouts
call in ip_vs_genl_set_config with memset(&t, 0, sizeof(t)).
Then we will see 0 for values that are not changed/supported.
quoted hunk
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev at vger.kernel.org
Cc: Simon Horman <horms@verge.net.au>
Cc: Julian Anastasov <ja@ssi.bg>
Cc: netfilter-devel at vger.kernel.org
Cc: netfilter at vger.kernel.org
Cc: coreteam at netfilter.org
---
net/netfilter/ipvs/ip_vs_ctl.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
On Friday 05 October 2012, Julian Anastasov wrote:
Hello,
On Fri, 5 Oct 2012, Arnd Bergmann wrote:
quoted
The ip_vs_set_timeout function sets timeouts for TCP and UDP, which
can be enabled independently at compile time. The debug message
always prints both timeouts that are passed into the function,
but if one is disabled, the message will show uninitialized data.
This splits the debug message into two separte IP_VS_DBG statements
that are in the same #ifdef section to ensure we only print the
text about what is actually going on.
Without this patch, building ARM ixp4xx_defconfig results in:
Are there any CONFIG_IP_VS_PROTO_xxx options in this
default config? It is a waste of memory if IPVS is compiled
without any protocols.
They all appear to be turned off:
$ grep CONFIG_IP_VS obj-tmp/.config
CONFIG_IP_VS=m
CONFIG_IP_VS_DEBUG=y
CONFIG_IP_VS_TAB_BITS=12
# CONFIG_IP_VS_PROTO_TCP is not set
# CONFIG_IP_VS_PROTO_UDP is not set
# CONFIG_IP_VS_PROTO_AH_ESP is not set
# CONFIG_IP_VS_PROTO_ESP is not set
# CONFIG_IP_VS_PROTO_AH is not set
# CONFIG_IP_VS_PROTO_SCTP is not set
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
# CONFIG_IP_VS_SED is not set
# CONFIG_IP_VS_NQ is not set
CONFIG_IP_VS_SH_TAB_BITS=8
quoted
net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
There are many __ip_vs_get_timeouts callers but
just one calls memset(&t, 0, sizeof(t)) before that,
problem only for ip_vs_genl_set_config and ip_vs_set_timeout.
To be safe, can we move this memset into
__ip_vs_get_timeouts instead of playing games with defines?:
memset(t, 0, sizeof(*t));
This debug message will be more precise in showing the
changed values if we replace the __ip_vs_get_timeouts
call in ip_vs_genl_set_config with memset(&t, 0, sizeof(t)).
Then we will see 0 for values that are not changed/supported.
8<-----
ipvs: initialize returned data in do_ip_vs_get_ctl
As reported by a gcc warning, the do_ip_vs_get_ctl does not initalize
all the members of the ip_vs_timeout_user structure it returns if
at least one of the TCP or UDP protocols is disabled for ipvs.
This makes sure that the data is always initialized, before it is
returned as a response to IPVS_CMD_GET_CONFIG or printed as a
debug message in IPVS_CMD_SET_CONFIG.
Without this patch, building ARM ixp4xx_defconfig results in:
net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
On Friday 05 October 2012, Julian Anastasov wrote:
quoted
Hello,
On Fri, 5 Oct 2012, Arnd Bergmann wrote:
quoted
The ip_vs_set_timeout function sets timeouts for TCP and UDP, which
can be enabled independently at compile time. The debug message
always prints both timeouts that are passed into the function,
but if one is disabled, the message will show uninitialized data.
This splits the debug message into two separte IP_VS_DBG statements
that are in the same #ifdef section to ensure we only print the
text about what is actually going on.
Without this patch, building ARM ixp4xx_defconfig results in:
Are there any CONFIG_IP_VS_PROTO_xxx options in this
default config? It is a waste of memory if IPVS is compiled
without any protocols.
They all appear to be turned off:
$ grep CONFIG_IP_VS obj-tmp/.config
CONFIG_IP_VS=m
CONFIG_IP_VS_DEBUG=y
CONFIG_IP_VS_TAB_BITS=12
# CONFIG_IP_VS_PROTO_TCP is not set
# CONFIG_IP_VS_PROTO_UDP is not set
# CONFIG_IP_VS_PROTO_AH_ESP is not set
# CONFIG_IP_VS_PROTO_ESP is not set
# CONFIG_IP_VS_PROTO_AH is not set
# CONFIG_IP_VS_PROTO_SCTP is not set
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
# CONFIG_IP_VS_SED is not set
# CONFIG_IP_VS_NQ is not set
CONFIG_IP_VS_SH_TAB_BITS=8
Something should be changed here, may be at least
TCP/UDP, who knows.
quoted hunk
quoted
quoted
net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
There are many __ip_vs_get_timeouts callers but
just one calls memset(&t, 0, sizeof(t)) before that,
problem only for ip_vs_genl_set_config and ip_vs_set_timeout.
To be safe, can we move this memset into
__ip_vs_get_timeouts instead of playing games with defines?:
memset(t, 0, sizeof(*t));
This debug message will be more precise in showing the
changed values if we replace the __ip_vs_get_timeouts
call in ip_vs_genl_set_config with memset(&t, 0, sizeof(t)).
Then we will see 0 for values that are not changed/supported.
8<-----
ipvs: initialize returned data in do_ip_vs_get_ctl
As reported by a gcc warning, the do_ip_vs_get_ctl does not initalize
all the members of the ip_vs_timeout_user structure it returns if
at least one of the TCP or UDP protocols is disabled for ipvs.
This makes sure that the data is always initialized, before it is
returned as a response to IPVS_CMD_GET_CONFIG or printed as a
debug message in IPVS_CMD_SET_CONFIG.
Without this patch, building ARM ixp4xx_defconfig results in:
net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
That is what we want. If you plan another submission
you can add empty line before this memset and to replace
the __ip_vs_get_timeouts call in ip_vs_genl_set_config with
memset but they are cosmetic changes. Or may be Simon will
take care about the coding style when applying the change.
Acked-by: Julian Anastasov <ja@ssi.bg>
On Saturday 06 October 2012, Julian Anastasov wrote:
On Sat, 6 Oct 2012, Arnd Bergmann wrote:
quoted
quoted
Are there any CONFIG_IP_VS_PROTO_xxx options in this
default config? It is a waste of memory if IPVS is compiled
without any protocols.
They all appear to be turned off:
$ grep CONFIG_IP_VS obj-tmp/.config
CONFIG_IP_VS=m
CONFIG_IP_VS_DEBUG=y
CONFIG_IP_VS_TAB_BITS=12
# CONFIG_IP_VS_PROTO_TCP is not set
# CONFIG_IP_VS_PROTO_UDP is not set
# CONFIG_IP_VS_PROTO_AH_ESP is not set
# CONFIG_IP_VS_PROTO_ESP is not set
# CONFIG_IP_VS_PROTO_AH is not set
# CONFIG_IP_VS_PROTO_SCTP is not set
Something should be changed here, may be at least
TCP/UDP, who knows.
I don't try to read too much into our defconfigs. We have 140 of them
on ARM, and they are mainly useful to give a reasonable build coverage,
but I wouldn't expect them to be actually used on that hardware.
I'll leave it up to Krzysztof to send a patch for this if he wants.
That is what we want. If you plan another submission
you can add empty line before this memset and to replace
the __ip_vs_get_timeouts call in ip_vs_genl_set_config with
memset but they are cosmetic changes. Or may be Simon will
take care about the coding style when applying the change.
Acked-by: Julian Anastasov <ja@ssi.bg>
I'd prefer Simon to pick up the patch. He should also decide whether he wants
to add it to stable. In theory, this is a small leak of kernel stack data
to user space, but as you say in practice it should not happen because it
only exists for silly configurations that nobody should be using.
AFAICT, removing the call to __ip_vs_get_timeouts in do_ip_vs_get_ctl would
be a semantic change for the case where a user sends a IPVS_CMD_SET_CONFIG
message without without the complete set of attributes inside it. The current
behavior is to leave the timeouts alone, replacing the __ip_vs_get_timeouts
with a memset would zero them. I left this part alone then.
Arnd
8<-----
ipvs: initialize returned data in do_ip_vs_get_ctl
As reported by a gcc warning, the do_ip_vs_get_ctl does not initalize
all the members of the ip_vs_timeout_user structure it returns if
at least one of the TCP or UDP protocols is disabled for ipvs.
This makes sure that the data is always initialized, before it is
returned as a response to IPVS_CMD_GET_CONFIG or printed as a
debug message in IPVS_CMD_SET_CONFIG.
Without this patch, building ARM ixp4xx_defconfig results in:
net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Julian Anastasov <ja@ssi.bg>
---
From: Simon Horman <horms@verge.net.au> Date: 2012-10-09 01:48:36
On Sat, Oct 06, 2012 at 09:54:15AM +0000, Arnd Bergmann wrote:
On Saturday 06 October 2012, Julian Anastasov wrote:
quoted
On Sat, 6 Oct 2012, Arnd Bergmann wrote:
quoted
quoted
Are there any CONFIG_IP_VS_PROTO_xxx options in this
default config? It is a waste of memory if IPVS is compiled
without any protocols.
They all appear to be turned off:
$ grep CONFIG_IP_VS obj-tmp/.config
CONFIG_IP_VS=m
CONFIG_IP_VS_DEBUG=y
CONFIG_IP_VS_TAB_BITS=12
# CONFIG_IP_VS_PROTO_TCP is not set
# CONFIG_IP_VS_PROTO_UDP is not set
# CONFIG_IP_VS_PROTO_AH_ESP is not set
# CONFIG_IP_VS_PROTO_ESP is not set
# CONFIG_IP_VS_PROTO_AH is not set
# CONFIG_IP_VS_PROTO_SCTP is not set
Something should be changed here, may be at least
TCP/UDP, who knows.
I don't try to read too much into our defconfigs. We have 140 of them
on ARM, and they are mainly useful to give a reasonable build coverage,
but I wouldn't expect them to be actually used on that hardware.
I'll leave it up to Krzysztof to send a patch for this if he wants.
That is what we want. If you plan another submission
you can add empty line before this memset and to replace
the __ip_vs_get_timeouts call in ip_vs_genl_set_config with
memset but they are cosmetic changes. Or may be Simon will
take care about the coding style when applying the change.
Acked-by: Julian Anastasov <ja@ssi.bg>
I'd prefer Simon to pick up the patch. He should also decide whether he wants
to add it to stable. In theory, this is a small leak of kernel stack data
to user space, but as you say in practice it should not happen because it
only exists for silly configurations that nobody should be using.
AFAICT, removing the call to __ip_vs_get_timeouts in do_ip_vs_get_ctl would
be a semantic change for the case where a user sends a IPVS_CMD_SET_CONFIG
message without without the complete set of attributes inside it. The current
behavior is to leave the timeouts alone, replacing the __ip_vs_get_timeouts
with a memset would zero them. I left this part alone then.
Arnd
Hi,
sorry for being a bit slow, it was a long weekend here.
This patch looks reasonable and I think it is appropriate for stable.
I'll see about getting it merged accordingly.
quoted hunk
8<-----
ipvs: initialize returned data in do_ip_vs_get_ctl
As reported by a gcc warning, the do_ip_vs_get_ctl does not initalize
all the members of the ip_vs_timeout_user structure it returns if
at least one of the TCP or UDP protocols is disabled for ipvs.
This makes sure that the data is always initialized, before it is
returned as a response to IPVS_CMD_GET_CONFIG or printed as a
debug message in IPVS_CMD_SET_CONFIG.
Without this patch, building ARM ixp4xx_defconfig results in:
net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Julian Anastasov <ja@ssi.bg>
---
The Linaro cross toolchain and probably others nowadays default to
building in THUMB2 mode. When building a kernel for a CPU that does
not support THUMB2, the compiler complains about incorrect flags.
We can work around this by setting -marm for all non-T2 builds.
Without this patch, building assabet_defconfig results in:
usr/initramfs_data.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
arch/arm/nwfpe/entry.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
firmware/cis/PCMLM28.cis.gen.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
(and many more)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <redacted>
Cc: Dave Martin <redacted>
---
arch/arm/Makefile | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
@@ -21,8 +21,6 @@ endifOBJCOPYFLAGS:=-Obinary-R.comment-SGZFLAGS:=-9#KBUILD_CFLAGS +=-pipe-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:-KBUILD_CFLAGS+=$(callcc-option,-marm,)# Never generate .eh_frameKBUILD_CFLAGS+=$(callcc-option,-fno-dwarf2-cfi-asm)
@@ -105,17 +103,20 @@ endififeq ($(CONFIG_THUMB2_KERNEL),y)AFLAGS_AUTOIT:=$(callas-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it)AFLAGS_NOWARN:=$(callas-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)-CFLAGS_THUMB2:=-mthumb$(AFLAGS_AUTOIT)$(AFLAGS_NOWARN)-AFLAGS_THUMB2:=$(CFLAGS_THUMB2)-Wa$(comma)-mthumb+CFLAGS_ISA:=-mthumb$(AFLAGS_AUTOIT)$(AFLAGS_NOWARN)+AFLAGS_ISA:=$(CFLAGS_ISA)-Wa$(comma)-mthumb# Work around buggy relocation from gas if requested:ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y)CFLAGS_MODULE+=-fno-optimize-sibling-callsendif+else+CFLAGS_ISA:=$(callcc-option,-marm,)+AFLAGS_ISA:=$(CFLAGS_ISA)endif# Need -Uarm for gcc < 3.x-KBUILD_CFLAGS+=$(CFLAGS_ABI)$(CFLAGS_THUMB2)$(arch-y)$(tune-y)$(callcc-option,-mshort-load-bytes,$(callcc-option,-malignment-traps,))-msoft-float-Uarm-KBUILD_AFLAGS+=$(CFLAGS_ABI)$(AFLAGS_THUMB2)$(arch-y)$(tune-y)-includeasm/unified.h-msoft-float+KBUILD_CFLAGS+=$(CFLAGS_ABI)$(CFLAGS_ISA)$(arch-y)$(tune-y)$(callcc-option,-mshort-load-bytes,$(callcc-option,-malignment-traps,))-msoft-float-Uarm+KBUILD_AFLAGS+=$(CFLAGS_ABI)$(AFLAGS_ISA)$(arch-y)$(tune-y)-includeasm/unified.h-msoft-floatCHECKFLAGS+=-D__arm__
From: Nicolas Pitre <hidden> Date: 2012-10-05 18:42:28
On Fri, 5 Oct 2012, Arnd Bergmann wrote:
The Linaro cross toolchain and probably others nowadays default to
building in THUMB2 mode. When building a kernel for a CPU that does
not support THUMB2, the compiler complains about incorrect flags.
We can work around this by setting -marm for all non-T2 builds.
Without this patch, building assabet_defconfig results in:
usr/initramfs_data.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
arch/arm/nwfpe/entry.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
firmware/cis/PCMLM28.cis.gen.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
(and many more)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <redacted>
Cc: Dave Martin <redacted>
I don't think you need "call cc-option" with -marm. Those gcc versions
that might not accept -marm have not been able to compile the kernel for
a long long time now. Otherwise...
Acked-by: Nicolas Pitre <redacted>
@@ -21,8 +21,6 @@ endifOBJCOPYFLAGS:=-Obinary-R.comment-SGZFLAGS:=-9#KBUILD_CFLAGS +=-pipe-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:-KBUILD_CFLAGS+=$(callcc-option,-marm,)# Never generate .eh_frameKBUILD_CFLAGS+=$(callcc-option,-fno-dwarf2-cfi-asm)
@@ -105,17 +103,20 @@ endififeq ($(CONFIG_THUMB2_KERNEL),y)AFLAGS_AUTOIT:=$(callas-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it)AFLAGS_NOWARN:=$(callas-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)-CFLAGS_THUMB2:=-mthumb$(AFLAGS_AUTOIT)$(AFLAGS_NOWARN)-AFLAGS_THUMB2:=$(CFLAGS_THUMB2)-Wa$(comma)-mthumb+CFLAGS_ISA:=-mthumb$(AFLAGS_AUTOIT)$(AFLAGS_NOWARN)+AFLAGS_ISA:=$(CFLAGS_ISA)-Wa$(comma)-mthumb# Work around buggy relocation from gas if requested:ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y)CFLAGS_MODULE+=-fno-optimize-sibling-callsendif+else+CFLAGS_ISA:=$(callcc-option,-marm,)+AFLAGS_ISA:=$(CFLAGS_ISA)endif# Need -Uarm for gcc < 3.x-KBUILD_CFLAGS+=$(CFLAGS_ABI)$(CFLAGS_THUMB2)$(arch-y)$(tune-y)$(callcc-option,-mshort-load-bytes,$(callcc-option,-malignment-traps,))-msoft-float-Uarm-KBUILD_AFLAGS+=$(CFLAGS_ABI)$(AFLAGS_THUMB2)$(arch-y)$(tune-y)-includeasm/unified.h-msoft-float+KBUILD_CFLAGS+=$(CFLAGS_ABI)$(CFLAGS_ISA)$(arch-y)$(tune-y)$(callcc-option,-mshort-load-bytes,$(callcc-option,-malignment-traps,))-msoft-float-Uarm+KBUILD_AFLAGS+=$(CFLAGS_ABI)$(AFLAGS_ISA)$(arch-y)$(tune-y)-includeasm/unified.h-msoft-floatCHECKFLAGS+=-D__arm__
There is a subtle difference between dma_transfer_direction and
dma_data_direction: the former is used by the dmaengine framework,
while the latter is used by the dma-mapping API. Although the
purpose is comparable, the actual values are different and must
not be mixed. In this case, the driver just wants to use
dma_transfer_direction.
Without this patch, building s3c6400_defconfig results in:
drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_dmacb':
drivers/spi/spi-s3c64xx.c:239:21: warning: comparison between
'enum dma_data_direction' and 'enum dma_transfer_direction' [-Wenum-compare]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Kukjin Kim <redacted>
Cc: Grant Likely <redacted>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: spi-devel-general at lists.sourceforge.net
---
drivers/spi/spi-s3c64xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The definition of ARCH_SLAB_MINALIGN is architecture dependent
and can be either of type size_t or int. Comparing that value
with ARCH_KMALLOC_MINALIGN can cause harmless warnings on
platforms where they are different. Since both are always
small positive integer numbers, using the size_t type to compare
them is safe and gets rid of the warning.
Without this patch, building ARM collie_defconfig results in:
mm/slob.c: In function '__kmalloc_node':
mm/slob.c:431:152: warning: comparison of distinct pointer types lacks a cast [enabled by default]
mm/slob.c: In function 'kfree':
mm/slob.c:484:153: warning: comparison of distinct pointer types lacks a cast [enabled by default]
mm/slob.c: In function 'ksize':
mm/slob.c:503:153: warning: comparison of distinct pointer types lacks a cast [enabled by default]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Lameter <redacted>
Cc: Pekka Enberg <penberg@kernel.org>
---
mm/slob.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: Christoph Lameter <hidden> Date: 2012-10-05 16:46:23
On Fri, 5 Oct 2012, Arnd Bergmann wrote:
Without this patch, building ARM collie_defconfig results in:
mm/slob.c: In function '__kmalloc_node':
mm/slob.c:431:152: warning: comparison of distinct pointer types lacks a cast [enabled by default]
mm/slob.c: In function 'kfree':
mm/slob.c:484:153: warning: comparison of distinct pointer types lacks a cast [enabled by default]
mm/slob.c: In function 'ksize':
mm/slob.c:503:153: warning: comparison of distinct pointer types lacks a cast [enabled by default]
From: Pekka Enberg <penberg@kernel.org> Date: 2012-10-31 07:25:30
On Fri, 5 Oct 2012, Christoph Lameter wrote:
On Fri, 5 Oct 2012, Arnd Bergmann wrote:
quoted
Without this patch, building ARM collie_defconfig results in:
mm/slob.c: In function '__kmalloc_node':
mm/slob.c:431:152: warning: comparison of distinct pointer types lacks a cast [enabled by default]
mm/slob.c: In function 'kfree':
mm/slob.c:484:153: warning: comparison of distinct pointer types lacks a cast [enabled by default]
mm/slob.c: In function 'ksize':
mm/slob.c:503:153: warning: comparison of distinct pointer types lacks a cast [enabled by default]
The fas216_dumpinfo function is only used by __fas216_checkmagic,
which is conditionally compiled, so we should put both functions
inside of the same #ifdef.
Without this patch, building rpc_defconfig results in:
drivers/scsi/arm/fas216.c:182:13: warning: 'fas216_dumpinfo' defined but not used [-Wunused-function]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <redacted>
Cc: "James E.J. Bottomley" <redacted>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-scsi at vger.kernel.org
---
drivers/scsi/arm/fas216.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
In a configuration where the base cgroup support is enabled but
every single cgroup subsys is turned off, CGROUP_BUILTIN_SUBSYS_COUNT
is zero, which causes the sanity check code in cgroup_load_subsys
to trigger:
BUG_ON(ss->subsys_id >= CGROUP_BUILTIN_SUBSYS_COUNT);
BUG_ON(subsys[ss->subsys_id] != ss);
Gcc first confirms that subsys_id cannot be 0 or larger and consequently
warns in the second line.
kernel/cgroup.c: In function 'cgroup_load_subsys':
kernel/cgroup.c:4326:38: warning: array subscript is below array bounds [-Warray-bounds]
Since the subsys_id can never be less than zero, we can just change the
type to an unsigned int, which makes the warning go away.
Found by building ARM cns3420vb_defconfig.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tejun Heo <tj@kernel.org>
Cc: Li Zefan <redacted>
Cc: Ben Blum <redacted>
---
include/linux/cgroup.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Fri, Oct 05, 2012 at 04:55:21PM +0200, Arnd Bergmann wrote:
quoted hunk
In a configuration where the base cgroup support is enabled but
every single cgroup subsys is turned off, CGROUP_BUILTIN_SUBSYS_COUNT
is zero, which causes the sanity check code in cgroup_load_subsys
to trigger:
BUG_ON(ss->subsys_id >= CGROUP_BUILTIN_SUBSYS_COUNT);
BUG_ON(subsys[ss->subsys_id] != ss);
Gcc first confirms that subsys_id cannot be 0 or larger and consequently
warns in the second line.
kernel/cgroup.c: In function 'cgroup_load_subsys':
kernel/cgroup.c:4326:38: warning: array subscript is below array bounds [-Warray-bounds]
Since the subsys_id can never be less than zero, we can just change the
type to an unsigned int, which makes the warning go away.
Found by building ARM cns3420vb_defconfig.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tejun Heo <tj@kernel.org>
Cc: Li Zefan <redacted>
Cc: Ben Blum <redacted>
---
include/linux/cgroup.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Fri, Oct 05, 2012 at 04:55:21PM +0200, Arnd Bergmann wrote:
In a configuration where the base cgroup support is enabled but
every single cgroup subsys is turned off, CGROUP_BUILTIN_SUBSYS_COUNT
is zero, which causes the sanity check code in cgroup_load_subsys
to trigger:
BUG_ON(ss->subsys_id >= CGROUP_BUILTIN_SUBSYS_COUNT);
BUG_ON(subsys[ss->subsys_id] != ss);
CGROUP_BUILTIN_SUBSYS_COUNT is already gone in mainline. I suppose
this is no longer necessary?
Thanks.
--
tejun
On Fri, Oct 05, 2012 at 04:55:21PM +0200, Arnd Bergmann wrote:
quoted
In a configuration where the base cgroup support is enabled but
every single cgroup subsys is turned off, CGROUP_BUILTIN_SUBSYS_COUNT
is zero, which causes the sanity check code in cgroup_load_subsys
to trigger:
BUG_ON(ss->subsys_id >= CGROUP_BUILTIN_SUBSYS_COUNT);
BUG_ON(subsys[ss->subsys_id] != ss);
CGROUP_BUILTIN_SUBSYS_COUNT is already gone in mainline. I suppose
this is no longer necessary?
Ah, you are right. I can confirm the problem is gone, and I'll drop
the patch.
Arnd
On NOMMU ARM, the __addr_ok() and __range_ok() macros do not evaluate
their arguments, which may lead to harmless build warnings in some
code where the variables are not used otherwise. Adding a cast to void
gets rid of the warning and does not make any semantic changes.
Without this patch, building at91x40_defconfig results in:
fs/read_write.c: In function 'rw_copy_check_uvector':
fs/read_write.c:684:9: warning: unused variable 'buf' [-Wunused-variable]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Ungerer <redacted>
Cc: Russell King <redacted>
---
arch/arm/include/asm/uaccess.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
On NOMMU ARM, the __addr_ok() and __range_ok() macros do not evaluate
their arguments, which may lead to harmless build warnings in some
code where the variables are not used otherwise. Adding a cast to void
gets rid of the warning and does not make any semantic changes.
Without this patch, building at91x40_defconfig results in:
fs/read_write.c: In function 'rw_copy_check_uvector':
fs/read_write.c:684:9: warning: unused variable 'buf' [-Wunused-variable]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Ungerer <redacted>
Cc: Russell King <redacted>
Acked-by: Greg Ungerer <redacted>
I can pick it up and push to the arm-soc tree.
Regards
Greg
On NOMMU ARM, the __addr_ok() and __range_ok() macros do not evaluate
their arguments, which may lead to harmless build warnings in some
code where the variables are not used otherwise. Adding a cast to void
gets rid of the warning and does not make any semantic changes.
Without this patch, building at91x40_defconfig results in:
fs/read_write.c: In function 'rw_copy_check_uvector':
fs/read_write.c:684:9: warning: unused variable 'buf' [-Wunused-variable]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Ungerer <redacted>
Cc: Russell King <redacted>
Acked-by: Greg Ungerer <redacted>
Thanks!
I can pick it up and push to the arm-soc tree.
Well, my idea was that I would prefer the patches go through some other tree
besides arm-soc since they are not really the main purpose for this tree.
The core ARM patches in particular should go through Russell's ARM tree.
I have a few more that come in during the merge window and plan to send
him a pull request for those.
Arnd
The flat_get_addr_from_rp() macro does not use the 'persistent' argument
on ARM, causing a harmless compiler warning. A cast to void removes
that warning.
Without this patch, building at91x40_defconfig results in:
fs/binfmt_flat.c: In function 'load_flat_file':
fs/binfmt_flat.c:746:17: warning: unused variable 'persistent' [-Wunused-variable]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Ungerer <redacted>
Cc: Russell King <redacted>
Cc: Bryan Wu <redacted>
---
arch/arm/include/asm/flat.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The flat_get_addr_from_rp() macro does not use the 'persistent' argument
on ARM, causing a harmless compiler warning. A cast to void removes
that warning.
Without this patch, building at91x40_defconfig results in:
fs/binfmt_flat.c: In function 'load_flat_file':
fs/binfmt_flat.c:746:17: warning: unused variable 'persistent' [-Wunused-variable]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Ungerer <redacted>
Cc: Russell King <redacted>
Cc: Bryan Wu <redacted>
Acked-by: Greg Ungerer <redacted>
I can pick this one up to, and push to the arm-soc tree.
Regards
Greg
The sharpsl_pcmcia_ops structure gets passed into
sa11xx_drv_pcmcia_probe, where it gets accessed at run-time,
unlike all other pcmcia drivers that pass their structures
into platform_device_add_data, which makes a copy.
This means the gcc warning is valid and the structure
must not be marked as __initdata.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Russell King <redacted>
Cc: Pavel Machek <redacted>
Cc: linux-pcmcia at lists.infradead.org
Cc: Jochen Friedrich <jochen@scram.de>
Cc: stable at vger.kernel.org
---
drivers/pcmcia/pxa2xx_sharpsl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The ncr5380 driver is included by multiple board specific
drivers, which may or may not use the interrupt handler.
The oak variant doesn't, and should set the DONT_USE_INTR
macro.
Without this patch, building rpc_defconfig results in:
drivers/scsi/arm/../NCR5380.c:1160:20: warning: 'oakscsi_intr' defined but not used [-Wunused-function]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <redacted>
Cc: "James E.J. Bottomley" <redacted>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-scsi at vger.kernel.org
---
drivers/scsi/arm/oak.c | 1 +
1 file changed, 1 insertion(+)
s3c2440_clk_add is a subsys_interface method and calls clkdev_add_table,
which means we might be calling it after the __init section is
discarded.
Without this patch, building mini2440_defconfig results in:
WARNING: vmlinux.o(.text+0x9848): Section mismatch in reference from the function s3c2440_clk_add() to the function .init.text:clkdev_add_table()
The function s3c2440_clk_add() references
the function __init clkdev_add_table().
This is often because s3c2440_clk_add lacks a __init
annotation or the annotation of clkdev_add_table is wrong.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <redacted>
Cc: Mike Turquette <redacted>
Cc: Kukjin Kim <redacted>
Cc: Ben Dooks <ben-linux@fluff.org>
---
drivers/clk/clkdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
nuc900fb_map_video_memory is called by an devinit function
that may be called at run-time, but the function itself is
marked __init and will be discarded after boot.
To avoid calling into a function that may have been overwritten,
mark nuc900fb_map_video_memory itself as __devinit.
Without this patch, building nuc950_defconfig results in:
WARNING: drivers/video/built-in.o(.devinit.text+0x26c): Section mismatch in reference from the function nuc900fb_probe() to the function .init.text:nuc900fb_map_video_memory()
The function __devinit nuc900fb_probe() references
a function __init nuc900fb_map_video_memory().
If nuc900fb_map_video_memory is only used by nuc900fb_probe then
annotate nuc900fb_map_video_memory with a matching annotation.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Wan ZongShun <redacted>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev at vger.kernel.org
---
drivers/video/nuc900fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)