On 2/27/14, 1:11 AM, Dave Chinner wrote:
> On Wed, Feb 26, 2014 at 12:29:22PM -0600, Eric Sandeen wrote:
>> On 2/25/14, 8:11 PM, Christoph Hellwig wrote:
>>> On Mon, Feb 24, 2014 at 11:27:35PM -0600, Eric Sandeen wrote:
>>>> xfs_set_maxicount() overflowed fairly easily for large filesystems
>>>> and large maxicount; we started out by multiplying dblocks by
>>>> the percentage, *then* dividing by 100, and never checked for
>>>> an overflow. The calculations were also, IMHO, a little hard
>>>> to follow.
>>> Would be useful to get this test case into xfstests..
>> Ok so I was going on Dave's assertion about that. ;)
>> To overflow, we'd need dblocks * 100 to be > 2^64-1:
>> so dblocks would need to be > (2^64-1)/100
>> for 4k blocks that's 655 exabytes. Maybe not so possible after all ;)
> Until the block count is corrupted by fsfuzzer? ;)
>> Dave, maybe just removing the open-code is enough here.
> Sure, but I still like the conversion to use mult_frac....
Ok, I do too. Just a bit resistant to fixing what ain't
broke. I'll see if I can write up a test to be sure we're
doing sane things statfs/growfs with the change.