All of lore.kernel.org
 help / color / mirror / Atom feed
* sparc32 build failure in fault_32.c
@ 2011-03-06 22:55 Bob Breuer
  2011-03-09 21:01 ` David Miller
  2011-03-10 17:49 ` Bob Breuer
  0 siblings, 2 replies; 3+ messages in thread
From: Bob Breuer @ 2011-03-06 22:55 UTC (permalink / raw)
  To: sparclinux

Using gcc 3.3.4, I'm getting this build failure for sparc32:

arch/sparc/mm/fault_32.c: In function `do_sparc_fault':
arch/sparc/mm/fault_32.c:229: warning: `code' might be used
uninitialized in this function
make[3]: *** [arch/sparc/mm/fault_32.o] Error 1

I have no idea why gcc 3.3 is catching this while 4.x is not, but the
problem is caused by these lines:
  if (!ARCH_SUN4C && address >= TASK_SIZE)
<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/sparc/mm/fault_32.c;h[836f5aea90bcd94d4e4ba1b3114a8115291135;hb=HEAD#l244>         
goto vmalloc_fault;
  code = SEGV_MAPERR;

This first branch can jump to vmalloc_fault before "code" gets
initialized, and from there can jump back to bad_area_nosemaphore, which
may then use "code" without it being initialized.

Would it be safe enough to initialize code to SEGV_MAPERR earlier, or
should vmalloc_fault have a different fault code?

Bob


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: sparc32 build failure in fault_32.c
  2011-03-06 22:55 sparc32 build failure in fault_32.c Bob Breuer
@ 2011-03-09 21:01 ` David Miller
  2011-03-10 17:49 ` Bob Breuer
  1 sibling, 0 replies; 3+ messages in thread
From: David Miller @ 2011-03-09 21:01 UTC (permalink / raw)
  To: sparclinux

From: Bob Breuer <breuerr@mc.net>
Date: Sun, 06 Mar 2011 16:55:33 -0600

> Would it be safe enough to initialize code to SEGV_MAPERR earlier, or
> should vmalloc_fault have a different fault code?

Yep, and that's how I'll fix this, thanks!

---
sparc32: Fix might-be-used-uninitialized warning in do_sparc_fault().

When we try to handle vmalloc faults, we can take a code
path which uses "code" before we actually set it.

Amusingly gcc-3.3 notices this yet gcc-4.x does not.

Reported-by: Bob Breuer <breuerr@mc.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 arch/sparc/mm/fault_32.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/sparc/mm/fault_32.c b/arch/sparc/mm/fault_32.c
index 5b836f5..b10ac4d 100644
--- a/arch/sparc/mm/fault_32.c
+++ b/arch/sparc/mm/fault_32.c
@@ -240,11 +240,10 @@ asmlinkage void do_sparc_fault(struct pt_regs *regs, int text_fault, int write,
 	 * only copy the information from the master page table,
 	 * nothing more.
 	 */
+	code = SEGV_MAPERR;
 	if (!ARCH_SUN4C && address >= TASK_SIZE)
 		goto vmalloc_fault;
 
-	code = SEGV_MAPERR;
-
 	/*
 	 * If we're in an interrupt or have no user
 	 * context, we must not take the fault..
-- 
1.7.4.1


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: sparc32 build failure in fault_32.c
  2011-03-06 22:55 sparc32 build failure in fault_32.c Bob Breuer
  2011-03-09 21:01 ` David Miller
@ 2011-03-10 17:49 ` Bob Breuer
  1 sibling, 0 replies; 3+ messages in thread
From: Bob Breuer @ 2011-03-10 17:49 UTC (permalink / raw)
  To: sparclinux

David Miller wrote:
> From: Bob Breuer <breuerr@mc.net>
> Date: Sun, 06 Mar 2011 16:55:33 -0600
> 
>> Would it be safe enough to initialize code to SEGV_MAPERR earlier, or
>> should vmalloc_fault have a different fault code?
> 
> Yep, and that's how I'll fix this, thanks!
> 
> ---
> sparc32: Fix might-be-used-uninitialized warning in do_sparc_fault().
> 
> When we try to handle vmalloc faults, we can take a code
> path which uses "code" before we actually set it.
> 
> Amusingly gcc-3.3 notices this yet gcc-4.x does not.
> 
> Reported-by: Bob Breuer <breuerr@mc.net>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---

Thanks, no errors during compile.

Tested-by: Bob Breuer <breuerr@mc.net>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-03-10 17:49 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-06 22:55 sparc32 build failure in fault_32.c Bob Breuer
2011-03-09 21:01 ` David Miller
2011-03-10 17:49 ` Bob Breuer

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.