All of lore.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 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.