[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c312066b2cc44919bd11b6cd938cb05f@AcuMS.aculab.com>
Date: Tue, 5 Sep 2023 14:15:25 +0000
From: David Laight <David.Laight@...LAB.COM>
To: "'paulmck@...nel.org'" <paulmck@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
CC: Denis Arefev <arefev@...mel.ru>,
Lai Jiangshan <jiangshanlai@...il.com>,
Josh Triplett <josh@...htriplett.org>,
Steven Rostedt <rostedt@...dmis.org>,
"rcu@...r.kernel.org" <rcu@...r.kernel.org>,
"lvc-project@...uxtesting.org" <lvc-project@...uxtesting.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"trufanov@...mel.ru" <trufanov@...mel.ru>,
"vfh@...mel.ru" <vfh@...mel.ru>
Subject: RE: [PATCH v2] The value may overflow
...
> That would instead be more than 512-16=496 CPUs, correct? 496 CPUs would
> only require a 31-bit shift, which should be OK, but 497 would require
> a 32-bit shift, which would result in sign extension. If it turns out
> that sign extension is OK, then we should get in trouble at 513 CPUs,
> which would result in a 33-bit shift (and is that even defined in C?).
Not quite right :-)
(1 << 31) is int and negative, that gets sign extended before
being converted to 'unsigned long' - so has the top 33 bits set.
(1 << 32) is undefined, the current x86 cpu ignore the high
shift bits so it is (1 << 0).
If the mask is being used to optimise a search the code might
just happen to work!
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists