Alexander Bluhm <alexander.bl...@gmx.net> 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.
