On Thu, Jun 07, 2018 at 08:54:37AM -0700, Darrick J. Wong wrote:
> On Thu, Jun 07, 2018 at 03:27:50PM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> >
> > do_mod() is a hold-over from when we have different sizes for file
> > offsets and and other internal values for 40 bit XFS filesystems.
> > Hence depending on build flags variables passed to do_mod() could
> > change size. We no longer support those small format filesystems and
> > hence everything is of fixed size theses days, even on 32 bit
> > platforms.
> >
> > As such, we can convert all the do_mod() callers to platform
> > optimised modulus operations as defined by linux/math64.h.
> > Individual conversions depend on the types of variables being used.
> >
> > Signed-Off-By: Dave Chinner <dchinner@xxxxxxxxxx>
> > ---
.....
> > @@ -1090,7 +1094,7 @@ xfs_adjust_extent_unmap_boundaries(
> > struct xfs_mount *mp = ip->i_mount;
> > struct xfs_bmbt_irec imap;
> > int nimap, error;
> > - xfs_extlen_t mod = 0;
> > + xfs_rtblock_t mod = 0;
> >
> > nimap = 1;
> > error = xfs_bmapi_read(ip, *startoffset_fsb, 1, &imap, &nimap, 0);
> > @@ -1099,7 +1103,7 @@ xfs_adjust_extent_unmap_boundaries(
> >
> > if (nimap && imap.br_startblock != HOLESTARTBLOCK) {
> > ASSERT(imap.br_startblock != DELAYSTARTBLOCK);
> > - mod = do_mod(imap.br_startblock, mp->m_sb.sb_rextsize);
> > + div64_u64_rem(imap.br_startblock, mp->m_sb.sb_rextsize, &mod);
>
> Why does this need to be a div64_u64_rem? sb_rextsize is 32-bit, so the
> remainder won't exceed 2^32-1, right?
>
> > if (mod)
> > *startoffset_fsb += mp->m_sb.sb_rextsize - mod;
>
> Indeed if it ever did that would screw up this logic, wouldn't it?
Yeah, i think I screwed that one up, probably confused rextsize with
rextents. IOWs mod can remain as a xfs_extlen_t and this can become
div_u64_rem().
I'll fix and repost.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
