Re: [PATCH] conf: use proper maximum for parsing memory values

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/30/2014 10:09 AM, Eric Blake wrote:
> On 10/30/2014 09:55 AM, Eric Blake wrote:
>> On 10/30/2014 09:49 AM, Martin Kletzander wrote:
>>> The value is stored in unsigned long long, so ULLONG_MAX is the proper
>>> upper limit to use.
>>
>> No, it's not.
>>
>>>
>>> Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx>
>>> ---
>>> Even though this is a build-breaker (for 32bit systems
>>> memtune-unlimited fails to parse), I'm not pushing it as one because
>>> it feels odd that such change wouldn't break anything else.
>>
>> What's the compile failure?  This patch is intentionally trying to fit
>> the largest value that will fit in an unsigned long when scaled by
>> kilobytes, while still parsing by bytes.  Thus, on 64-bit machines, you
>> can parse 0xffffffffffffffff bytes, then scale down by 1024 and store in
>> unsigned long; on 32-bit machines, your maximum has to be limited to
>> 0xffffffff*1024 bytes before scaling back down.
> 
> Sounds like the real bug is in the memtune-unlimited test.  2^53-1 is
> the maximum memory for a 64-bit host, but invalid on a 32-bit host.  Any
> interface that uses 'unsigned long' as its capping point has to have
> different maximum limits on 32-bit hosts.

Or maybe the problem is that at some point we used unsigned long, and
later moved to unsigned long long, but never updated the comment?  I'm
trying to investigate the history of this code...

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]