All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: Paul Jackson <pj@sgi.com>
Cc: colpatch@us.ibm.com, linux-kernel@vger.kernel.org,
	mbligh@aracnet.com, akpm@osdl.org, haveblue@us.ibm.com
Subject: Re: [PATCH] nodemask_t x86_64 changes [5/7]
Date: Tue, 23 Mar 2004 20:37:55 -0800	[thread overview]
Message-ID: <20040324043755.GD791@holomorphy.com> (raw)
In-Reply-To: <20040323201101.3427494c.pj@sgi.com>

At some point in the past, I wrote:
>> Any idea where this bogon might be?

On Tue, Mar 23, 2004 at 08:11:01PM -0800, Paul Jackson wrote:
> Unless I'm missing something (quite possible), the following would
> expose the complement operators setting of high unused bits.
>     You have 32 bit unsigned longs and NR_CPUS == 24, you complement
>     some cpumask, and you then ask if it is empty, or ask if it is
>     equal to another cpumask that differs only in the unused
>     high byte, or ask its Hamming weight?
> The arithmetic cpumask ops don't mask off the unused bits above NR_CPUS.
> This might never be noticed, because cpumask_complement is the only op
> that sets these unused bits, the complement op is very rarely used, and
> none of its current uses can lead to the above bugs that I see offhand.

It's supposed to do this. bitmap_weight() masks off the trailing bits to
filter out "don't cares" from whole-word ops. Everything else operates
bitwise. Something like the following will keep the bits clear as you
wish, since apparently the more simplistic single-word ops aren't obeying
this. It's likely possible to better this by exploiting some invariants;
feel free improve on it.


-- wli


Index: pgcl-2.6.5-rc2/include/asm-generic/cpumask_arith.h
===================================================================
--- pgcl-2.6.5-rc2.orig/include/asm-generic/cpumask_arith.h	2004-03-19 16:11:33.000000000 -0800
+++ pgcl-2.6.5-rc2/include/asm-generic/cpumask_arith.h	2004-03-23 20:34:54.000000000 -0800
@@ -6,6 +6,12 @@
  * to contain the whole cpu bitmap.
  */
 
+#if NR_CPUS % BITS_PER_LONG
+#define __CPU_MASK_VALID_BITS__		((1UL << (NR_CPUS % BITS_PER_LONG)) - 1)
+#else
+#define __CPU_MASK_VALID_BITS__		(~0UL)
+#endif
+
 #define cpu_set(cpu, map)		set_bit(cpu, &(map))
 #define cpu_clear(cpu, map)		clear_bit(cpu, &(map))
 #define cpu_isset(cpu, map)		test_bit(cpu, &(map))
@@ -14,15 +20,15 @@
 #define cpus_and(dst,src1,src2)		do { dst = (src1) & (src2); } while (0)
 #define cpus_or(dst,src1,src2)		do { dst = (src1) | (src2); } while (0)
 #define cpus_clear(map)			do { map = 0; } while (0)
-#define cpus_complement(map)		do { map = ~(map); } while (0)
-#define cpus_equal(map1, map2)		((map1) == (map2))
-#define cpus_empty(map)			((map) == 0)
+#define cpus_complement(map)		do { map = ~(map) & __CPU_MASK_VALID_BITS__; } while (0)
+#define cpus_equal(map1, map2)		(!(((map1) ^ (map2)) & __CPU_MASK_VALID_BITS__))
+#define cpus_empty(map)			(!((map) & __CPU_MASK_VALID_BITS__))
 #define cpus_addr(map)			(&(map))
 
 #if BITS_PER_LONG == 32
-#define cpus_weight(map)		hweight32(map)
+#define cpus_weight(map)		hweight32((map) & __CPU_MASK_VALID_BITS__)
 #elif BITS_PER_LONG == 64
-#define cpus_weight(map)		hweight64(map)
+#define cpus_weight(map)		hweight64((map) & __CPU_MASK_VALID_BITS__)
 #endif
 
 #define cpus_shift_right(dst, src, n)	do { dst = (src) >> (n); } while (0)
@@ -39,11 +45,13 @@
 #define CPU_MASK_NONE	((cpumask_t)0)
 
 /* only ever use this for things that are _never_ used on large boxen */
-#define cpus_coerce(map)		((unsigned long)(map))
+#define cpus_coerce(map)		((unsigned long)(map) & __CPU_MASK_VALID_BITS__)
 #define cpus_promote(map)		({ map; })
 #define cpumask_of_cpu(cpu)		({ ((cpumask_t)1) << (cpu); })
 
 #define first_cpu(map)			__ffs(map)
 #define next_cpu(cpu, map)		find_next_bit(&(map), NR_CPUS, cpu + 1)
 
+#undef __CPU_MASK_VALID_BITS__
+
 #endif /* __ASM_GENERIC_CPUMASK_ARITH_H */

  reply	other threads:[~2004-03-24  4:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-18 23:04 [PATCH] nodemask_t x86_64 changes [5/7] Matthew Dobson
2004-03-23  7:08 ` Paul Jackson
2004-03-23 10:13   ` William Lee Irwin III
2004-03-23 21:36     ` Paul Jackson
2004-03-24  2:03       ` William Lee Irwin III
2004-03-24  4:11         ` Paul Jackson
2004-03-24  4:37           ` William Lee Irwin III [this message]
2004-03-26  5:06           ` Keith Owens
2004-03-26  7:14             ` Paul Jackson
2004-03-29  5:08               ` Keith Owens
2004-03-29  5:14                 ` Paul Jackson
2004-03-29  5:38                 ` William Lee Irwin III
2004-03-26 11:57             ` William Lee Irwin III

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=20040324043755.GD791@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=akpm@osdl.org \
    --cc=colpatch@us.ibm.com \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --cc=pj@sgi.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.