* potential argument order bug in fs/xfs/xfs_dir2_node.c:xfs_dir2_leafn_unbalance
@ 2013-09-05 2:38 Dave Jones
2013-09-05 3:11 ` Dave Chinner
0 siblings, 1 reply; 3+ messages in thread
From: Dave Jones @ 2013-09-05 2:38 UTC (permalink / raw)
To: xfs
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.
Is this intentional ? If so I'll mark it as such in their db.
thanks,
Dave
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: potential argument order bug in fs/xfs/xfs_dir2_node.c:xfs_dir2_leafn_unbalance
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
0 siblings, 1 reply; 3+ messages in thread
From: Dave Chinner @ 2013-09-05 3:11 UTC (permalink / raw)
To: Dave Jones; +Cc: xfs
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?
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).
What the xfs_dir2_leafn_order() call tells us is whether the objects
in the drop block get inserted into the save block before or after
the objects in the save block. i.e. if we are merging from the left
or right sibling....
So I don't see that there's a problem here.
> Is this intentional ? If so I'll mark it as such in their db.
The code looks fine to me...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: potential argument order bug in fs/xfs/xfs_dir2_node.c:xfs_dir2_leafn_unbalance
2013-09-05 3:11 ` Dave Chinner
@ 2013-09-05 3:24 ` Dave Jones
0 siblings, 0 replies; 3+ messages in thread
From: Dave Jones @ 2013-09-05 3:24 UTC (permalink / raw)
To: Dave Chinner; +Cc: xfs
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-09-05 3:25 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox