Re: One question about API cpumask_setall()
From: Bibo Mao
Date: Thu Jul 30 2026 - 02:50:36 EST
On 2026/7/30 上午1:57, Yury Norov wrote:
On Wed, Jul 29, 2026 at 10:13:56AM +0800, Bibo Mao wrote:I understand what you say, the whole series of atomic operations is not atomic.
On 2026/7/29 上午9:55, Yury Norov wrote:
On Tue, Jul 28, 2026 at 04:16:27PM +0800, Bibo Mao wrote:It should be workable with atomic operation on unsigned long, rather than
Hi,
I am preparing to use API cpumask_setall() for TLB flush on LoongArch KVM
side. There are cpumask_test_and_clear_cpu/cpumask_setall() APIs, it seems
that API cpumask_setall() does not support atomic operation.
Do you think it is reasonable to add new API similar with cpumask_setall()
which supports atomic operation?
Maybe reasonable, but it's impossible. cpumask is a bitmap, which in
turn is an array of unsigned longs. There's no atomic operations on
arrays.
the array of unsigned longs, the API cpumask_test_and_clear_cpu is atomic
operation on unsigned long also.
No, cpumask_test_and_clear_cpu is atomic() operates on cpumask_t*,
which is a pointer to unsigned long.
Is it ok to use smp_store_mb() to fill the bitmap with the similar API
cpumask_setall()? where xchg() is used in smp_store_mb() wrapper instead.
If your bitmap is longer than 1 word, you'll have to issue 2 or more
smp_store_mb()'s. Then, a series of atomic operations is not atomic
itself.
My concern is whether cpumask_test_and_clear_cpu() operation on cpumask_t* will invalidate non-atomic write operation on another CPU. From MESI/MOSI protocol, this will not happen, only that order of write and atomic test_and_clear operation may be different.
Regards
Bibo Mao