On Fri, 2010-09-03 at 10:01 +1000, Dave Chinner wrote: > On Thu, Sep 02, 2010 at 10:51:19AM -0500, Alex Elder wrote: > > On Thu, 2010-09-02 at 15:17 +1000, Dave Chinner wrote: > > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > > > If we attempt to preallocate more than 2^32 blocks of space in a . . . > > > + resblks = min_t(xfs_fileoff_t, (e - s), (MAXEXTLEN * nimaps)); > > > > I guess it's clear that MAXEXTLEN fits in 32 bits because of > > sizeof (xfs_extlen_t). > > True, but if sizeof(xfs_extlen_t) was the limiting factor, > then the mulitply could still cause 32bit overflows. > > The real reason is that MAXEXTLEN defines the maximum extent length > supported by the on disk bmap btree record format. The record format > defines the extent length in FSBs to be: > > #define MAXEXTLEN ((xfs_extlen_t)0x001fffff) /* 21 bits */ > > and as such fits easily into the 32 bit limit. Yes, I recognized that but didn't mention it. However... > > And inspection shows that nimaps is > > just 1, so this does the 32-bit limiting. But that just > > seems indirect. > > nimaps can be up to: > > #define XFS_BMAP_MAX_NMAP 4 ...I had not noticed that nimap could have been changed from its value 1 by the xfs_bmapi() call, so the point you make is important. > So if we change the loop to do more allocations per loop, then > the code will already handle it correctly. :) Yes. And like I said, just adjusting the comment explains why it is safe. -Alex _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
