lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1DD7BFEDD3147247B1355BEFEFE46652379C3DF118@HQMAIL04.nvidia.com>
Date:	Wed, 9 May 2012 12:04:07 -0700
From:	Diwakar Tundlam <dtundlam@...dia.com>
To:	'Peter Zijlstra' <peterz@...radead.org>
CC:	'Ingo Molnar' <mingo@...nel.org>,
	'David Rientjes' <rientjes@...gle.com>,
	"'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
	Peter De Schrijver <pdeschrijver@...dia.com>
Subject: RE: [PATCH] sched: Make nr_uninterruptible count a signed value

The issue is because when promoting from 32-bit unsigned to 64-bit signed, the compiler first does SIZE increase and then the sign change. If it did SIGN change first and then size increase (with sign-extension) and it will work correctly.

But then, the compiler is probably doing the right thing here because the starting point is an unsigned value and when it is assigned a negative value, the compiler is perfectly justified in converting it to a large positive value which is what happened here.

The theoretical correct fix is to change the declaration to signed long nr_uninterruptible simply because it can sometimes become -ve.

The other fix is to fix the print statement - but it feels wrong.

It would be good to fix the declaration...

Thanks,
--Diwakar.

-----Original Message-----
From: Peter Zijlstra [mailto:peterz@...radead.org] 
Sent: Wednesday, May 09, 2012 1:12 AM
To: Diwakar Tundlam
Cc: 'Ingo Molnar'; 'David Rientjes'; 'linux-kernel@...r.kernel.org'; Peter De Schrijver
Subject: RE: [PATCH] sched: Make nr_uninterruptible count a signed value

On Tue, 2012-05-08 at 15:46 -0700, Diwakar Tundlam wrote:
> Maybe it is an artifact of 32-bit machine displaying 64-bit print format.
> An (unsigned long)(-24) promoted to (signed long long) ends up as 4294967272.
> As seen in my output of sched_debug.

Ah, quite possible. %Ld is indeed %lld and the value is long, not long long. So the proper fix is to fudge that printk statement somehow.

> Your machine is probably natively 64-bit. 

Yeah, I gave up on 32bit computing a while ago..

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ