linux-kernel - Re: [patch 07/19] cpumask: Introduce cpumask_or

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: <87plagxd5a.ffs@tglx>
Date: Tue, 21 Oct 2025 21:34:09 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Yury Norov <yury.norov@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Peter Zijlstra
 <peterz@...radead.org>, Gabriele Monaco <gmonaco@...hat.com>, Mathieu
 Desnoyers <mathieu.desnoyers@...icios.com>, Michael Jeanson
 <mjeanson@...icios.com>, Jens Axboe <axboe@...nel.dk>, "Paul E. McKenney"
 <paulmck@...nel.org>, "Gautham R. Shenoy" <gautham.shenoy@....com>,
 Florian Weimer <fweimer@...hat.com>, Tim Chen <tim.c.chen@...el.com>,
 TCMalloc Team <tcmalloc-eng@...gle.com>
Subject: Re: [patch 07/19] cpumask: Introduce cpumask_or_weight()

Yury!

On Wed, Oct 15 2025 at 13:41, Yury Norov wrote:
> On Wed, Oct 15, 2025 at 07:29:36PM +0200, Thomas Gleixner wrote:
>> +unsigned int __bitmap_or_weight(unsigned long *dst, const unsigned long *bitmap1,
>> +				const unsigned long *bitmap2, unsigned int bits)
>> +{
>> +	unsigned int k, w = 0;
>> +
>> +	for (k = 0; k < bits / BITS_PER_LONG; k++) {
>> +		dst[k] = bitmap1[k] | bitmap2[k];
>> +		w += hweight_long(dst[k]);
>> +	}
>> +
>> +	if (bits % BITS_PER_LONG) {
>> +		dst[k] = bitmap1[k] | bitmap2[k];
>> +		w += hweight_long(dst[k] & BITMAP_LAST_WORD_MASK(bits));
>> +	}
>> +	return w;
>> +}
>
> We've got bitmap_weight_and() and bitmap_weight_andnot() already. Can
> you align naming with the existing scheme: bitmap_weight_or().

That's not the same thing. bitmap_weight_and/not() calculate the weight
of the AND resp. ANDNOT of the two bitmaps w/o modifying them:

   for (...)
       w += hweight(map1[k] & map2[k]);

While the above does:

   for (...) {
       dst[k] = map1[k] | map2[k];
       w += hweight(dst[k]);
   }

The whole point of this as explained in the change log is to avoid
walking the resulting bitmap after doing the OR operation. The compiler
is clever enough to do the or operation in a register, write it to dst
and then do the hweight calculation with it.

> Also, for outline implementation, can you employ the BITMAP_WEIGHT()
> macro?

If you insist on this ugly:

  return BITMAP_WEIGHT(({dst[idx] = bitmap1[idx] | bitmap2[idx]; dst[idx]; }), bits);

Sure.

Thanks,

        tglx