One question about API cpumask_setall()

One question about API cpumask_setall()

[Bibo Mao]

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?

Regards
Bibo Mao

Re: One question about API cpumask_setall()

[Yury Norov]

On Tue, Jul 28, 2026 at 04:16:27PM +0800, Bibo Mao wrote:
> 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.

Thanks,
Yury

Re: One question about API cpumask_setall()

[Bibo Mao]

On 2026/7/29 上午9:55, Yury Norov wrote:
> On Tue, Jul 28, 2026 at 04:16:27PM +0800, Bibo Mao wrote:
>> 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.
It should be workable with atomic operation on unsigned long, rather 
than the array of unsigned longs, the API cpumask_test_and_clear_cpu is 
atomic operation on unsigned long also.

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.

Regards
Bibo Mao
> 
> Thanks,
> Yury
> 

Re: One question about API cpumask_setall()

[Yury Norov]

On Wed, Jul 29, 2026 at 10:13:56AM +0800, Bibo Mao wrote:
> 
> 
> On 2026/7/29 上午9:55, Yury Norov wrote:
> > On Tue, Jul 28, 2026 at 04:16:27PM +0800, Bibo Mao wrote:
> > > 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.
> It should be workable with atomic operation on unsigned long, rather than
> 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.

Re: One question about API cpumask_setall()

[Bibo Mao]

On 2026/7/30 上午1:57, Yury Norov wrote:
> On Wed, Jul 29, 2026 at 10:13:56AM +0800, Bibo Mao wrote:
>>
>>
>> On 2026/7/29 上午9:55, Yury Norov wrote:
>>> On Tue, Jul 28, 2026 at 04:16:27PM +0800, Bibo Mao wrote:
>>>> 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.
>> It should be workable with atomic operation on unsigned long, rather than
>> 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.
I understand what you say, the whole series of atomic operations is not 
atomic.

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

Re: One question about API cpumask_setall()

[Yury Norov]

On Thu, Jul 30, 2026 at 02:41:42PM +0800, Bibo Mao wrote:
> 
> 
> On 2026/7/30 上午1:57, Yury Norov wrote:
> > On Wed, Jul 29, 2026 at 10:13:56AM +0800, Bibo Mao wrote:
> > > 
> > > 
> > > On 2026/7/29 上午9:55, Yury Norov wrote:
> > > > On Tue, Jul 28, 2026 at 04:16:27PM +0800, Bibo Mao wrote:
> > > > > 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.
> > > It should be workable with atomic operation on unsigned long, rather than
> > > 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.
> I understand what you say, the whole series of atomic operations is not
> atomic.
> 
> 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.

You're changing the topic now. You asked about the atomic version of
cpumask_setall(), and I've pointed that it's impossible.

Now you're asking about invalidation of caches. I can't say for each
and every architecture out there, and all their caching modes.

If you need to run cpumask_setall() concurrently with
cpumask_test_and_clear_cpu(), please use external locking mechanism.

Thanks,
Yury

Re: One question about API cpumask_setall()

[Bibo Mao]

On 2026/8/4 上午5:51, Yury Norov wrote:
> On Thu, Jul 30, 2026 at 02:41:42PM +0800, Bibo Mao wrote:
>>
>>
>> On 2026/7/30 上午1:57, Yury Norov wrote:
>>> On Wed, Jul 29, 2026 at 10:13:56AM +0800, Bibo Mao wrote:
>>>>
>>>>
>>>> On 2026/7/29 上午9:55, Yury Norov wrote:
>>>>> On Tue, Jul 28, 2026 at 04:16:27PM +0800, Bibo Mao wrote:
>>>>>> 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.
>>>> It should be workable with atomic operation on unsigned long, rather than
>>>> 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.
>> I understand what you say, the whole series of atomic operations is not
>> atomic.
>>
>> 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.
> 
> You're changing the topic now. You asked about the atomic version of
> cpumask_setall(), and I've pointed that it's impossible.
It is my fault, I do not explain the context clearly. I need to run 
cpumask_setall() concurrently with cpumask_test_and_clear_cpu(), the 
first idea coming from me is atomic method. :(

> 
> Now you're asking about invalidation of caches. I can't say for each
> and every architecture out there, and all their caching modes.
> 
> If you need to run cpumask_setall() concurrently with
> cpumask_test_and_clear_cpu(), please use external locking mechanism.
yes, locking mechanism is one method for the concurrent contention 
issue. And thanks for your help.

Regards
Bibo Mao

> 
> Thanks,
> Yury
>