From: "Jesper Juhl" <jesper.juhl@gmail.com>
To: "Nathan Scott" <nathans@sgi.com>
Cc: "Meelis Roos" <mroos@linux.ee>,
"Linux Kernel list" <linux-kernel@vger.kernel.org>
Subject: Re: XFS warning in 2.6.18-rc4
Date: Fri, 11 Aug 2006 01:47:43 +0200 [thread overview]
Message-ID: <9a8748490608101647l4f51e761o6dc1f703c9d012b2@mail.gmail.com> (raw)
In-Reply-To: <20060810085616.C2581413@wobbly.melbourne.sgi.com>
On 10/08/06, Nathan Scott <nathans@sgi.com> wrote:
> On Wed, Aug 09, 2006 at 11:04:53PM +0300, Meelis Roos wrote:
> > fs/xfs/xfs_bmap.c: In function 'xfs_bmapi':
> > fs/xfs/xfs_bmap.c:2662: warning: 'rtx' is used uninitialized in this function
>
> You have a particularly dense compiler, unfortunately. This code
> has always been this way, its just a false cc warning that can be
> safely ignored until you upgrade to a fixed compiler (unless I'm
> missing something - please enlighten me if so). It does seem to
> be the case that there is no way 'rtx' will be used uninitialised
> when xfs_rtpick_extent() doesn't fail... no?
>
Ok, I may be reading something wrong here, but I think the warning is
actually not correct.
In fs/xfs/xfs_rtalloc.c::xfs_rtpick_extent() there is this code :
...
if ((error = xfs_trans_iget(mp, tp, mp->m_sb.sb_rbmino, 0,
XFS_ILOCK_EXCL, &ip)))
return error;
...
before anything even touches 'pick' (which is the last argument of
type "xfs_rtblock_t *" which is what "&rtx" is being passed to that
function as, from fs/xfs/xfs_bmap.c::xfs_bmap_rtalloc() at line 2659
before 'rtx' then used at line 2662.
Look at this block of code from fs/xfs/xfs_bmap.c::xfs_bmap_rtalloc() :
...
2658: if (ap->eof && ap->off == 0) {
2659: error = xfs_rtpick_extent(mp, ap->tp, ralen, &rtx);
2660: if (error)
2661: return error;
2662: ap->rval = rtx * mp->m_sb.sb_rextsize;
2663: } else {
2664: ap->rval = 0;
2665: }
..
'rtx' has not been initialized in this function before this block of code.
If the call to xfs_rtpick_extent() should happen to fail from the
check quoted above, then 'rtx' will in fact be used uninitialized in
line 2662 - except that will never happen, because if the check in In
fs/xfs/xfs_rtalloc.c::xfs_rtpick_extent() fails then error will be !=
0 and then well never get down to line 2662.
Or am I missing something ?
PS. Above line numbers etc are from 2.6.18-rc4.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
next prev parent reply other threads:[~2006-08-10 23:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-09 20:04 Meelis Roos
2006-08-09 22:56 ` Nathan Scott
2006-08-10 23:47 ` Jesper Juhl [this message]
2006-08-10 23:52 ` Nathan Scott
2006-08-11 0:02 ` Jesper Juhl
2006-08-15 3:46 ` David Chinner
2006-08-09 23:06 ` Alexey Dobriyan
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=9a8748490608101647l4f51e761o6dc1f703c9d012b2@mail.gmail.com \
--to=jesper.juhl@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mroos@linux.ee \
--cc=nathans@sgi.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®