On Sun, Oct 09, 2011 at 07:45:29PM -0400, Christoph Hellwig wrote:

On Mon, Oct 10, 2011 at 10:11:47AM +1100, Dave Chinner wrote:

quoted

From: Dave Chinner <redacted>

Fix a potential prefetch read problem due to the first loop
execution of pf_batch_read potentially not initialising the fsbno
varaible:

variable.

quoted

==10177== Thread 6:
==10177== Conditional jump or move depends on uninitialised value(s)
==10177==    at 0x8079CAB: pf_batch_read (prefetch.c:408)
==10177==    by 0x6A2996D: clone (clone.S:130)
==10177==

Signed-off-by: Dave Chinner <redacted>
---
 repair/prefetch.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/repair/prefetch.c b/repair/prefetch.c
index d2fdf90..da074a8 100644
--- a/repair/prefetch.c
+++ b/repair/prefetch.c

@@ -397,7 +397,7 @@ pf_batch_read(
 	int			len, size;
 	int			i;
 	int			inode_bufs;
-	unsigned long		fsbno;
+	unsigned long		fsbno = 0;

Call me stupid, but I can't see how this could actually be a real
life issue.  The first thing we do in the loop is to to write
to fsbno in btree_find.  I'm fine adding this to shut up warnins,
but I can't see a real issue.

If btree_find() fails to find the key being looked up, it returns
without having initialised fsbno.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs