* Re: linux-next: arm allmodconfig
2008-10-29 0:56 linux-next: arm allmodconfig Andrew Morton
@ 2008-10-29 7:12 ` Takashi Iwai
2008-10-29 7:40 ` [xfs-masters] " Dave Chinner
` (3 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Takashi Iwai @ 2008-10-29 7:12 UTC (permalink / raw)
To: Andrew Morton
Cc: Ingo Molnar, Thomas Gleixner, Dave Airlie, netdev,
linux-arm-kernel, Herbert Xu, Paul Moore, Pekka Enberg,
xfs-masters
At Tue, 28 Oct 2008 17:56:04 -0700,
Andrew Morton wrote:
>
> > sound/soc/codecs/tlv320aic23.c: In function `tlv320aic23_set_dai_sysclk':
> > sound/soc/codecs/tlv320aic23.c:424: warning: unused variable `codec'
This will be either removed or used with other codes.
Waiting for a patch of the original author right now.
> > sound/pci/hda/patch_sigmatel.c: In function `stac92xx_smux_enum_put':
> > sound/pci/hda/patch_sigmatel.c:571: warning: 'val' might be used uninitialized in this function
>
> This looks like a bug.
Yep, indeed. Fixed now on sound git tree.
(Wondering why this warning doesn't hit on my machine with
gcc-4.3.3...)
Thanks!
Takashi
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [xfs-masters] linux-next: arm allmodconfig
2008-10-29 0:56 linux-next: arm allmodconfig Andrew Morton
2008-10-29 7:12 ` Takashi Iwai
@ 2008-10-29 7:40 ` Dave Chinner
2008-10-29 8:24 ` Ingo Molnar
2008-10-29 9:40 ` Russell King - ARM Linux
` (2 subsequent siblings)
4 siblings, 1 reply; 10+ messages in thread
From: Dave Chinner @ 2008-10-29 7:40 UTC (permalink / raw)
To: xfs-masters
Cc: Ingo Molnar, Thomas Gleixner, Dave Airlie, netdev,
linux-arm-kernel, Herbert Xu, Paul Moore, Takashi Iwai,
Pekka Enberg
On Tue, Oct 28, 2008 at 05:56:04PM -0700, Andrew Morton wrote:
> > fs/xfs/quota/xfs_qm_syscalls.c: In function `xfs_qm_dqrele_inodes_ag':
> > fs/xfs/quota/xfs_qm_syscalls.c:1039: warning: 'inode_refed' might be used uninitialized in this function
I haven't seen this one before. And it's a real bug, too.
gcc-4.3.1 on x86_64 is not picking this warning up:
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-9' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.1 (Debian 4.3.1-9)
$
$
$ touch fs/xfs/quota/xfs_qm_syscalls.c
$ make -j2 ARCH=um
SYMLINK arch/um/include/shared/kern_constants.h
make[1]: `arch/um/sys-x86_64/user-offsets.s' is up to date.
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL scripts/checksyscalls.sh
CHK include/linux/compile.h
CC fs/xfs/quota/xfs_qm_syscalls.o
LD fs/xfs/xfs.o
LD fs/xfs/built-in.o
LD fs/built-in.o
What compiler version are you using?
I'll send out a patch to fix this in a minute.
> > fs/xfs/xfs_rtalloc.c: In function `xfs_growfs_rt':
> > fs/xfs/xfs_rtalloc.c:1875: warning: 'tp' might be used uninitialized in this function
False positive, and I don't get this reported, either.
Hold on - the above gcc binary only emits a warning for the xfs_growfs_rt issue
when CONFIG_CC_OPTIMIZE_FOR_SIZE=y is set. It still doesn't catch the quota
bug, though. This is so fucked up....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [xfs-masters] linux-next: arm allmodconfig
2008-10-29 7:40 ` [xfs-masters] " Dave Chinner
@ 2008-10-29 8:24 ` Ingo Molnar
2008-10-29 22:07 ` [xfs-masters] " Dave Chinner
0 siblings, 1 reply; 10+ messages in thread
From: Ingo Molnar @ 2008-10-29 8:24 UTC (permalink / raw)
To: xfs-masters, Thomas Gleixner, Dave Airlie, netdev,
linux-arm-kernel, Herbert Xu
* Dave Chinner <david@fromorbit.com> wrote:
> > > fs/xfs/xfs_rtalloc.c: In function `xfs_growfs_rt':
> > > fs/xfs/xfs_rtalloc.c:1875: warning: 'tp' might be used uninitialized in this function
>
> False positive, and I don't get this reported, either.
>
> Hold on - the above gcc binary only emits a warning for the
> xfs_growfs_rt issue when CONFIG_CC_OPTIMIZE_FOR_SIZE=y is set. It
> still doesn't catch the quota bug, though. This is so fucked up....
FYI, i've got 3 XFS warnings mapped in tip/auto-warnings-next:
earth4:~/tip> gll linus..auto-warnings-next | grep xfs
ec2f37c: work around warning in fs/xfs/xfs_mount.c
8501db3: work around warning in fs/xfs/xfs_rtalloc.c
8077af8: warnings: fix xfs posix acl
you can find those commits in the auto-warnings-next branch of -tip:
http://people.redhat.com/mingo/tip.git/README
the rtalloc annotation is below. I went through the flow and the code
seems to be correct and GCC is wrong.
Ingo
------------->
From 8501db35588df4f35d67d8ba207422006a214ae7 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Mon, 18 Aug 2008 15:21:19 +0200
Subject: [PATCH] work around warning in fs/xfs/xfs_rtalloc.c
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
fix warning:
fs/xfs/xfs_rtalloc.c: In function ‘xfs_growfs_rt’:
fs/xfs/xfs_rtalloc.c:1875: warning: ‘tp’ may be used uninitialized in this function
This is a spurious gcc warning - it does not realize the correct/bug-free
flow of logic regarding the 'error' and 'tp' variables.
No code changed:
7c10fd959065115c8e252ff5a861a01e xfs_rtalloc.o.before.asm
7c10fd959065115c8e252ff5a861a01e xfs_rtalloc.o.after.asm
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
fs/xfs/xfs_rtalloc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/xfs/xfs_rtalloc.c b/fs/xfs/xfs_rtalloc.c
index e2f68de..fe5de08 100644
--- a/fs/xfs/xfs_rtalloc.c
+++ b/fs/xfs/xfs_rtalloc.c
@@ -1872,7 +1872,7 @@ xfs_growfs_rt(
xfs_extlen_t rsumblocks; /* current number of rt summary blks */
xfs_sb_t *sbp; /* old superblock */
xfs_fsblock_t sumbno; /* summary block number */
- xfs_trans_t *tp; /* transaction pointer */
+ xfs_trans_t *uninitialized_var(tp); /* transaction pointer */
sbp = &mp->m_sb;
cancelflags = 0;
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [xfs-masters] Re: linux-next: arm allmodconfig
2008-10-29 8:24 ` Ingo Molnar
@ 2008-10-29 22:07 ` Dave Chinner
0 siblings, 0 replies; 10+ messages in thread
From: Dave Chinner @ 2008-10-29 22:07 UTC (permalink / raw)
To: xfs-masters
Cc: Thomas Gleixner, Dave Airlie, netdev, linux-arm-kernel,
Herbert Xu, Paul Moore, Takashi Iwai, Pekka Enberg
On Wed, Oct 29, 2008 at 09:24:59AM +0100, Ingo Molnar wrote:
>
> * Dave Chinner <david@fromorbit.com> wrote:
>
> > > > fs/xfs/xfs_rtalloc.c: In function `xfs_growfs_rt':
> > > > fs/xfs/xfs_rtalloc.c:1875: warning: 'tp' might be used uninitialized in this function
> >
> > False positive, and I don't get this reported, either.
> >
> > Hold on - the above gcc binary only emits a warning for the
> > xfs_growfs_rt issue when CONFIG_CC_OPTIMIZE_FOR_SIZE=y is set. It
> > still doesn't catch the quota bug, though. This is so fucked up....
>
> FYI, i've got 3 XFS warnings mapped in tip/auto-warnings-next:
>
> earth4:~/tip> gll linus..auto-warnings-next | grep xfs
>
> ec2f37c: work around warning in fs/xfs/xfs_mount.c
Can't say I've ever seen that warning. What gcc version is
generating it?
> 8501db3: work around warning in fs/xfs/xfs_rtalloc.c
Yeah, that's bogus.
> 8077af8: warnings: fix xfs posix acl
Should be fixed in the -next tree.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: linux-next: arm allmodconfig
2008-10-29 0:56 linux-next: arm allmodconfig Andrew Morton
2008-10-29 7:12 ` Takashi Iwai
2008-10-29 7:40 ` [xfs-masters] " Dave Chinner
@ 2008-10-29 9:40 ` Russell King - ARM Linux
2008-10-29 16:05 ` Tony Lindgren
2008-10-29 10:16 ` Pekka J Enberg
2008-10-29 13:53 ` Paul Moore
4 siblings, 1 reply; 10+ messages in thread
From: Russell King - ARM Linux @ 2008-10-29 9:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Ingo Molnar, Thomas Gleixner, Dave Airlie, netdev,
linux-arm-kernel, Herbert Xu, Paul Moore, Takashi Iwai,
Pekka Enberg, xfs-masters
On Tue, Oct 28, 2008 at 05:56:04PM -0700, Andrew Morton wrote:
> > arch/arm/mm/dma-mapping.c: In function `dma_sync_sg_for_cpu':
> > arch/arm/mm/dma-mapping.c:588: warning: statement with no effect
>
> Something in here:
>
> dmabounce_sync_for_cpu(dev, sg_dma_address(s), 0,
> sg_dma_len(s), dir);
That's because dmabounce_sync_for_xxx() functions return whether they
did anything, so in the case where the buffer isn't bounced, we fall
through to the standard DMA cache maintainence methods.
When there's no dmabounce, we define these functions to (1), which
of course causes the warning. I'll eventually convert them to inline
functions instead.
> > kernel/sched.c: In function `add_preempt_count':
> > kernel/sched.c:4294: warning: unsupported arg to `__builtin_return_address'
> > kernel/sched.c:4296: warning: unsupported arg to `__builtin_return_address'
> > kernel/sched.c:4298: warning: unsupported arg to `__builtin_return_address'
> > kernel/sched.c: In function `sub_preempt_count':
> > kernel/sched.c:4294: warning: unsupported arg to `__builtin_return_address'
> > kernel/sched.c:4296: warning: unsupported arg to `__builtin_return_address'
> > kernel/sched.c:4298: warning: unsupported arg to `__builtin_return_address'
>
> Related to CALLER_ADDR2, etc.
Later ARM toolchains seem to have dropped support for non-zero arguments
to __builtin_return_address() - presumably to support this new fangled
EABI stuff. Not much can be done about that without screaming at the
toolchain people.
> > drivers/atm/zatm.c: In function `refill_pool':
> > drivers/atm/zatm.c:226: warning: `virt_to_bus' is deprecated (declared at /usr/src/devel/arch/arm/include/asm/memory.h:184)
> >
> <50ish similar warnings snipped>
We really really want to see the end of virt_to_bus() in the kernel -
since ARM is a non-cache coherent architecture, every usage of it is
a bug since there'll be no cache maintainence.
So, essentially, these warnings are saying that this driver is buggy
on ARM.
> > drivers/atm/ambassador.h:257:1: warning: "FLASH_BASE" redefined
> > In file included from arch/arm/mach-versatile/include/mach/irqs.h:22,
> > from /usr/src/devel/arch/arm/include/asm/irq.h:4,
> > from /usr/src/devel/arch/arm/include/asm/hardirq.h:6,
> > from include/linux/hardirq.h:7,
> > from include/asm-generic/local.h:5,
> > from /usr/src/devel/arch/arm/include/asm/local.h:1,
> > from include/linux/module.h:20,
> > from drivers/atm/ambassador.c:25:
> > arch/arm/mach-versatile/include/mach/platform.h:443:1: warning: this is the location of the previous definition
> > In file included from drivers/atm/ambassador.c:44:
> > drivers/atm/ambassador.h:258:1: warning: "FLASH_SIZE" redefined
Here we go again...
I do wish that people wouldn't include "platform.h" headers defining lots
of generically named constants into a header file used by most of the
kernel build. It's stupid for several reasons:
1. see the above warnings.
2. if you change anything in that header, you're going to get a needless
full kernel rebuild
3. and that causes additional strain on kautobuild's build caches
We've had this in the past with sa1100-regs.h and similar, and we solved
it there.
Unfortunately, people persist in including their platform includes into
lots of header files rather than having just the relevent C files include
them. Eg, arch/arm/plat-omap/include/mach/hardware.h:
/*
* ---------------------------------------------------------------------------
* Board specific defines
* ---------------------------------------------------------------------------
*/
#ifdef CONFIG_MACH_OMAP_INNOVATOR
#include "board-innovator.h"
#endif
#ifdef CONFIG_MACH_OMAP_H2
#include "board-h2.h"
#endif
...
#ifdef CONFIG_MACH_SX1
#include "board-sx1.h"
#endif
which is included via asm/io.h, asm/irq.h, asm/pci.h, asm/vga.h.
As long as this idiocracy, we're going to see these kinds of clashes.
This stuff needs to die. I've a good idea to do a sweep of all ARM
includes, and commit a patch to my devel tree for linux-next to remove
such includes as an encouragement to fixing this stuff properly.
People will then have a couple of months to sort out their mess.
> > crypto/testmgr.c: In function `alg_test_comp':
> > crypto/testmgr.c:829: warning: 'ret' might be used uninitialized in this function
>
> There's no way for the compiler to know that this code isn't buggy.
>
> Suggest that this be fixed via uninitialized_var() or, better, convert
> to a do{}while() loop.
>
> I notice that test_comp() also has two locals called `ret' - one
> shadowing the other.
Here's a question: Why do we have to have the test manager built in if
we build some crypto modules? What if you're building an embedded target
and don't want to test the crypto modules on every boot? (Think code
size, boot time, etc.)
> > include/asm-generic/cmpxchg-local.h:15: warning: 'prev' might be used uninitialized in this function
> > drivers/gpu/drm/drm_lock.c: In function `drm_lock_free':
> > include/asm-generic/cmpxchg-local.h:15: warning: 'prev' might be used uninitialized in this function
> > include/asm-generic/cmpxchg-local.h:15: warning: 'prev' might be used uninitialized in this function
> > drivers/gpu/drm/drm_lock.c: In function `drm_notifier':
> > include/asm-generic/cmpxchg-local.h:15: warning: 'prev' might be used uninitialized in this function
> > drivers/gpu/drm/drm_lock.c: In function `drm_idlelock_release':
> > include/asm-generic/cmpxchg-local.h:15: warning: 'prev' might be used uninitialized in this function
>
> didn't look.
No idea.
> > drivers/gpu/drm/drm_agpsupport.c:36:21: asm/agp.h: No such file or directory
> > make[3]: *** [drivers/gpu/drm/drm_agpsupport.o] Error 1
> > make[2]: *** [drivers/gpu/drm] Error 2
> > make[1]: *** [drivers/gpu] Error 2
> > make[1]: *** Waiting for unfinished jobs....
>
> DRM has been breaking arm allmodconfig for at least a year.
I've no idea what asm/agp.h is supposed to have in it, no idea what
DRM actually is other than "Digital Rights Management" ;)
I suspect the right answer is to make DRM depend on !ARM - I know of
no ARM platform with AGP.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: linux-next: arm allmodconfig
2008-10-29 9:40 ` Russell King - ARM Linux
@ 2008-10-29 16:05 ` Tony Lindgren
0 siblings, 0 replies; 10+ messages in thread
From: Tony Lindgren @ 2008-10-29 16:05 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Andrew Morton, Ingo Molnar, Thomas Gleixner, Dave Airlie, netdev,
linux-arm-kernel, Herbert Xu, Paul Moore, Takashi Iwai,
Pekka Enberg, xfs-masters
* Russell King - ARM Linux <linux@arm.linux.org.uk> [081029 02:59]:
> On Tue, Oct 28, 2008 at 05:56:04PM -0700, Andrew Morton wrote:
<snip>
>
> > > drivers/atm/ambassador.h:257:1: warning: "FLASH_BASE" redefined
> > > In file included from arch/arm/mach-versatile/include/mach/irqs.h:22,
> > > from /usr/src/devel/arch/arm/include/asm/irq.h:4,
> > > from /usr/src/devel/arch/arm/include/asm/hardirq.h:6,
> > > from include/linux/hardirq.h:7,
> > > from include/asm-generic/local.h:5,
> > > from /usr/src/devel/arch/arm/include/asm/local.h:1,
> > > from include/linux/module.h:20,
> > > from drivers/atm/ambassador.c:25:
> > > arch/arm/mach-versatile/include/mach/platform.h:443:1: warning: this is the location of the previous definition
> > > In file included from drivers/atm/ambassador.c:44:
> > > drivers/atm/ambassador.h:258:1: warning: "FLASH_SIZE" redefined
>
> Here we go again...
>
> I do wish that people wouldn't include "platform.h" headers defining lots
> of generically named constants into a header file used by most of the
> kernel build. It's stupid for several reasons:
>
> 1. see the above warnings.
> 2. if you change anything in that header, you're going to get a needless
> full kernel rebuild
> 3. and that causes additional strain on kautobuild's build caches
>
> We've had this in the past with sa1100-regs.h and similar, and we solved
> it there.
>
> Unfortunately, people persist in including their platform includes into
> lots of header files rather than having just the relevent C files include
> them. Eg, arch/arm/plat-omap/include/mach/hardware.h:
>
> /*
> * ---------------------------------------------------------------------------
> * Board specific defines
> * ---------------------------------------------------------------------------
> */
>
> #ifdef CONFIG_MACH_OMAP_INNOVATOR
> #include "board-innovator.h"
> #endif
>
> #ifdef CONFIG_MACH_OMAP_H2
> #include "board-h2.h"
> #endif
> ...
> #ifdef CONFIG_MACH_SX1
> #include "board-sx1.h"
> #endif
>
> which is included via asm/io.h, asm/irq.h, asm/pci.h, asm/vga.h.
>
> As long as this idiocracy, we're going to see these kinds of clashes.
> This stuff needs to die. I've a good idea to do a sweep of all ARM
> includes, and commit a patch to my devel tree for linux-next to remove
> such includes as an encouragement to fixing this stuff properly.
>
> People will then have a couple of months to sort out their mess.
I'll remove those omap includes, I have few other patches pending before
I get to that though.
Cheers,
Tony
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: linux-next: arm allmodconfig
2008-10-29 0:56 linux-next: arm allmodconfig Andrew Morton
` (2 preceding siblings ...)
2008-10-29 9:40 ` Russell King - ARM Linux
@ 2008-10-29 10:16 ` Pekka J Enberg
2008-10-29 13:53 ` Paul Moore
4 siblings, 0 replies; 10+ messages in thread
From: Pekka J Enberg @ 2008-10-29 10:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Ingo Molnar, Thomas Gleixner, Dave Airlie, netdev,
linux-arm-kernel, Herbert Xu, Paul Moore, Takashi Iwai,
xfs-masters
On Tue, 28 Oct 2008, Andrew Morton wrote:
> > include/linux/slub_def.h:231: warning: 'ret' might be used uninitialized in this function
> > include/linux/slub_def.h:231: warning: 'ret' might be used uninitialized in this function
>
> I lost interest here.
Looks like a bogus warning to me. But we might as well clean it up a bit
and maybe the compiler is less confused that way.
Pekka
>From 48724e2995a0fd292d326f79caebe61f4f115021 Mon Sep 17 00:00:00 2001
From: Pekka Enberg <penberg@cs.helsinki.fi>
Date: Wed, 29 Oct 2008 12:13:37 +0200
Subject: [PATCH] slub: avoid bogus warning on arm
Move the ret variable to where we actually need it in an attempt to avoid a
bugs warning when compiling for ARM.
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
include/linux/slub_def.h | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index dc28432..4d3de0c 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -228,14 +228,13 @@ static __always_inline void *kmalloc_large(size_t size, gfp_t flags)
static __always_inline void *kmalloc(size_t size, gfp_t flags)
{
- void *ret;
-
if (__builtin_constant_p(size)) {
if (size > PAGE_SIZE)
return kmalloc_large(size, flags);
if (!(flags & SLUB_DMA)) {
struct kmem_cache *s = kmalloc_slab(size);
+ void *ret;
if (!s)
return ZERO_SIZE_PTR;
--
1.5.4.3
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: linux-next: arm allmodconfig
2008-10-29 0:56 linux-next: arm allmodconfig Andrew Morton
` (3 preceding siblings ...)
2008-10-29 10:16 ` Pekka J Enberg
@ 2008-10-29 13:53 ` Paul Moore
2008-10-29 20:12 ` Paul Moore
4 siblings, 1 reply; 10+ messages in thread
From: Paul Moore @ 2008-10-29 13:53 UTC (permalink / raw)
To: Andrew Morton
Cc: Ingo Molnar, Thomas Gleixner, Dave Airlie, netdev,
linux-arm-kernel, Herbert Xu, Takashi Iwai, Pekka Enberg,
xfs-masters
On Tuesday 28 October 2008 8:56:04 pm Andrew Morton wrote:
> > net/netlabel/netlabel_mgmt.c: In function `netlbl_mgmt_listentry':
> > net/netlabel/netlabel_mgmt.c:268: warning: 'ret_val' might be used
> > uninitialized in this function
>
> Assumes that netlbl_af4list_foreach_rcu() will never iterate zero
> times.
>
> Assumes that entry->type can never have an unexpected value.
>
> gcc cannot get this right, and C-level changes will be needed to shut
> this up.
No idea why this didn't come up when I was compiling this ... oh well,
good thing I'm not a proud guy :) I'll get this fixed and post a patch
later today.
Thanks.
--
paul moore
linux @ hp
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: linux-next: arm allmodconfig
2008-10-29 13:53 ` Paul Moore
@ 2008-10-29 20:12 ` Paul Moore
0 siblings, 0 replies; 10+ messages in thread
From: Paul Moore @ 2008-10-29 20:12 UTC (permalink / raw)
To: Andrew Morton
Cc: Ingo Molnar, Thomas Gleixner, Dave Airlie, netdev,
linux-arm-kernel, Herbert Xu, Takashi Iwai, Pekka Enberg,
xfs-masters
On Wednesday 29 October 2008 9:53:02 am Paul Moore wrote:
> On Tuesday 28 October 2008 8:56:04 pm Andrew Morton wrote:
> > > net/netlabel/netlabel_mgmt.c: In function
> > > `netlbl_mgmt_listentry': net/netlabel/netlabel_mgmt.c:268:
> > > warning: 'ret_val' might be used uninitialized in this function
> >
> > Assumes that netlbl_af4list_foreach_rcu() will never iterate zero
> > times.
> >
> > Assumes that entry->type can never have an unexpected value.
> >
> > gcc cannot get this right, and C-level changes will be needed to
> > shut this up.
>
> No idea why this didn't come up when I was compiling this ... oh
> well, good thing I'm not a proud guy :) I'll get this fixed and post
> a patch later today.
I updated my lblnet-2.6_next tree with a fix as well as another patch
from Roel Kluin to fix a signed/unsigned mistake. I'll post the
patches to the relevant lists but I'm waiting one more patch from
someone first.
In the meantime, interested parties can find the git tree here:
* git://git.infradead.org/users/pcmoore/lblnet-2.6_next
--
paul moore
linux @ hp
^ permalink raw reply [flat|nested] 10+ messages in thread