[Top] [All Lists]

Re: [PATCH] xfs: clean up xfs_set_maxicount & use in growfs

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfs: clean up xfs_set_maxicount & use in growfs
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 27 Feb 2014 08:08:45 -0600
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140227071154.GK29907@dastard>
References: <530C29C7.90001@xxxxxxxxxx> <20140226021114.GA26022@xxxxxxxxxxxxx> <530E3282.7000703@xxxxxxxxxxx> <20140227071154.GK29907@dastard>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
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.


> Cheers,
> Dave.

<Prev in Thread] Current Thread [Next in Thread>