Hello,Yes, I think so.
On Wed, Nov 29, 2023 at 11:01:04AM -0500, Waiman Long wrote:
...
Setting and clearing a bit is as atomic as it gets, right?I may be a bit paranoid about incorrect result due to racing as I had beenDepending on how the cpumask operators are implemented, we may not have aCan you please elaborate this part a bit? I'm having a difficult time
guarantee that testing CPU 2, for instance, will always return true. That is
imagining the sequence of operations where this would matter but that could
easily be me not being familiar with the details.
burned before. Just testing a bit in the bitmask may probably be OK. I don't
think it will be a problem for x86, but I am less certain about other moreI just can't think of a case where this would be broken. The data being read
exotic architectures like arm64 or PPC which I am less familiar about. I add
a seqcount for synchronization just for the peace of mind. I can take the
seqcount out if you don't it is necessary.
and written is atomic. There's no way to break a bit operation into multiple
pieces. It is possible to write a really bone-headed bitmask operations
(like, if you shift the bits into place or sth) to make the bits go through
unintended changes but that'd just be a flat-out broken implementation. Even
for a bitmask where write accesses are synchronized through a spinlock, we
should still be able to use test_bit() without holding the lock. This seems
like a pretty basic assumption.
Adding unnecessary synchronization confuses the readers. If we don't need
it, we shouldn't have it.