From: David Laight <David.Laight@ACULAB.COM>
To: "'paulmck@kernel.org'" <paulmck@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Denis Arefev <arefev@swemel.ru>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Josh Triplett <josh@joshtriplett.org>,
Steven Rostedt <rostedt@goodmis.org>,
"rcu@vger.kernel.org" <rcu@vger.kernel.org>,
"lvc-project@linuxtesting.org" <lvc-project@linuxtesting.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"trufanov@swemel.ru" <trufanov@swemel.ru>,
"vfh@swemel.ru" <vfh@swemel.ru>
Subject: RE: [PATCH v2] The value may overflow
Date: Tue, 5 Sep 2023 14:15:25 +0000 [thread overview]
Message-ID: <c312066b2cc44919bd11b6cd938cb05f@AcuMS.aculab.com> (raw)
In-Reply-To: <b79eb142-67b2-48f0-9ad9-f9b634491e09@paulmck-laptop>
...
> 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)
next prev parent reply other threads:[~2023-09-05 16:51 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-04 9:42 Denis Arefev
2023-09-04 10:24 ` Mathieu Desnoyers
2023-09-05 9:31 ` David Laight
2023-09-05 12:26 ` Mathieu Desnoyers
2023-09-05 13:26 ` Paul E. McKenney
2023-09-05 13:34 ` Mathieu Desnoyers
2023-09-05 13:56 ` Paul E. McKenney
2023-09-05 14:15 ` David Laight [this message]
2023-09-05 14:34 ` Mathieu Desnoyers
2023-09-05 16:40 ` Paul E. McKenney
2023-09-05 19:27 ` Paul E. McKenney
2023-09-05 19:36 ` Mathieu Desnoyers
2023-09-05 19:45 ` Paul E. McKenney
2023-09-05 20:40 ` Joel Fernandes
2023-09-05 20:52 ` Paul E. McKenney
2023-09-05 20:56 ` Joel Fernandes
2023-09-05 22:22 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c312066b2cc44919bd11b6cd938cb05f@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=arefev@swemel.ru \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=trufanov@swemel.ru \
--cc=vfh@swemel.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®