Alexander Bluhm <> wrote:

> During configuration there is usually some kind of lock, it happens
> rarely, and bugs are hard to trigger, especially on amd64 which
> guarantees some consistency.  That's why it works.
> > Some times ago, I privately pointed this and proposed to modify if_flags
> > atomically. May be it's time to rethink this.
> Atomic operations are not the answer to everything.  They are still
> slow and don't guarantee consistency with the logic around them.
> If writes to if_flags happen rarely and are protected by exclusive
> netlock anyway, we can leave them as they are.
> More problematic is reading.  Many people believe that reading an
> integer, that another CPU can modify, is fine.  To make the integer
> value consistent for the compiler, you need READ_ONCE() or
> atomic_load_int().  And then consider whether reordering it with
> all the instructions around it, is a problem.  Getting that right
> with memory barriers is very hard.  It should not be done in regular
> code, better use primitives that have better semantics.

Right the problem is other fields in the structure which are married
to each other.  A flag indicates that some other field should be looked
at.  But the reading point, in some code, does not indicate this semantic,
and the compiler feels free to pre-read the wrong part from the structure
out of order.  There are many ways this can play out.  It is better to
lock the entire sub-block in some way, than just the single field.

Reply via email to