xfs_dir2_free_hdr_t entries are unsigned, so they can't be negative.
remove these unnessary checks in process_leaf_node_dir_v2_free.
Reported by coverity.
Signed-off-by: Vivek Trivedi <redacted>
---
db/check.c | 2 --
1 file changed, 2 deletions(-)
and place the free just before the return here so that we have a single
uwinding exit.
Otherwise this looks good to me.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
From: Christoph Hellwig <hch@infradead.org> Date: 2015-12-20 15:35:18
On Fri, Dec 11, 2015 at 04:39:01PM +0530, Vivek Trivedi wrote:
Fix unintentional integer overflow in xlog_find_verify_cycle.
Reported by coverity.
xfs_daddr_t is a 64-bit integer. How does replacing it with an int fix
overlows?
xlog_find_verify_cycle originates in the kernel code, so any fix
should probably be done there first.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
From: Christoph Hellwig <hch@infradead.org> Date: 2015-12-20 15:36:51
quoted hunk
+++ b/mkfs/xfs_mkfs.c
@@ -2022,7 +2022,7 @@ _("warning: sparse inodes not supported without CRC support, disabled.\n"));*andtheunderlyingvolumeisstriped,thensetrtextblocks*tothestripewidth.*/-intrswidth;+__uint64_trswidth;__uint64_trtextbytes;
This looks odd. We initiallize assigned ft.rtswidth (which is an int)
or 0 to it. I think you want a separate variable for the result of
the DTOBT(rswidth) statement to make this clear.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
From: Dave Chinner <david@fromorbit.com> Date: 2015-12-20 23:45:48
On Sun, Dec 20, 2015 at 07:35:13AM -0800, Christoph Hellwig wrote:
On Fri, Dec 11, 2015 at 04:39:01PM +0530, Vivek Trivedi wrote:
quoted
Fix unintentional integer overflow in xlog_find_verify_cycle.
Reported by coverity.
xfs_daddr_t is a 64-bit integer. How does replacing it with an int fix
overlows?
xfs_daddr_t is being abused here as a count rather than a disk
address, whereas all the other counts in the function are ints and
so the value can't be more than 32 bits anyway....
xlog_find_verify_cycle originates in the kernel code, so any fix
should probably be done there first.
I'll pull all the libxfs changes made first in userspace back into
the kernel - no point making people jump throw hoops just to get a
fix into the libxfs code...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
and place the free just before the return here so that we have a single
uwinding exit.
<sigh>
I'll just make the change locally, given I *was* only 15 minutes
away from pushing this into the public repository.
-Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
From: Dave Chinner <david@fromorbit.com> Date: 2015-12-20 23:51:06
On Sun, Dec 20, 2015 at 07:36:49AM -0800, Christoph Hellwig wrote:
quoted
+++ b/mkfs/xfs_mkfs.c
@@ -2022,7 +2022,7 @@ _("warning: sparse inodes not supported without CRC support, disabled.\n"));*andtheunderlyingvolumeisstriped,thensetrtextblocks*tothestripewidth.*/-intrswidth;+__uint64_trswidth;__uint64_trtextbytes;
This looks odd. We initiallize assigned ft.rtswidth (which is an int)
or 0 to it. I think you want a separate variable for the result of
the DTOBT(rswidth) statement to make this clear.
I don't see any point in doing that. It really doesn't matter that
the variable it is initialised from is only a 32 bit int, and having
yet another variable in mkfs is not going to make the code easier to
understand...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs