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. -- 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