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