public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: potential argument order bug in fs/xfs/xfs_dir2_node.c:xfs_dir2_leafn_unbalance
Date: Wed, 4 Sep 2013 23:24:54 -0400	[thread overview]
Message-ID: <20130905032454.GA13451@redhat.com> (raw)
In-Reply-To: <20130905031128.GZ23571@dastard>

On Thu, Sep 05, 2013 at 01:11:28PM +1000, Dave Chinner wrote:
 > On Wed, Sep 04, 2013 at 10:38:18PM -0400, Dave Jones wrote:
 > > I'm picking through some of the bugs in coverity's database,
 > > and I came across this one, which I'm unsure of..
 > > 
 > > In xfs_dir2_leafn_unbalance we have this code..
 > > 
 > > 1583         if (xfs_dir2_leafn_order(save_blk->bp, drop_blk->bp))
 > > 1584                 xfs_dir3_leafn_moveents(args, drop_blk->bp, &drophdr, dents, 0,
 > > 1585                                         save_blk->bp, &savehdr, sents, 0,
 > > 1586                                         drophdr.count);
 > > 1587         else
 > > 1588                 xfs_dir3_leafn_moveents(args, drop_blk->bp, &drophdr, dents, 0,
 > > 1589                                         save_blk->bp, &savehdr, sents,
 > > 1590                                         savehdr.count, drophdr.count);
 > > 
 > > The issue that coverity picked up in both cases, is that 'sents' and 'dents' are in
 > > a different order to how the xfs_dir3_leafn_moveents function expects them.
 > 
 > What does "order" mean to coverity? Is it really complaining about
 > function parameters being ordered (src, dst) rather than (dst, src)?
 > Or is it detecting that we are passing parameters names (dxxx, sxxx)
 > into a function that declares those parameters (syyy, dyyy) and it
 > throws based on that?

Yeah, the latter. It's done it to quite a few parts of the kernel.
In most cases I've looked through so far, it's not a problem, but there have
been 1-2 real bugs.

 > In more detail, the function prototype is effectively
 > xfs_dir3_leafn_moveents(source, destination, count), and so in both
 > cases here objects are being moved from the block being dropped
 > (freed) to the block being saved (merged block).

Ok, thanks for looking it over anyway.
I've marked it as being intentional in their db, so it shouldn't show up in future.

	Dave

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

      reply	other threads:[~2013-09-05  3:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-05  2:38 potential argument order bug in fs/xfs/xfs_dir2_node.c:xfs_dir2_leafn_unbalance Dave Jones
2013-09-05  3:11 ` Dave Chinner
2013-09-05  3:24   ` Dave Jones [this message]

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=20130905032454.GA13451@redhat.com \
    --to=davej@redhat.com \
    --cc=david@fromorbit.com \
    --cc=xfs@oss.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