On 5/11/22 16:45, Paul E. McKenney wrote:
Well no, because the "&" operation is a single operation on the CPU, and
isn't going to get split up like that.
Chiming in a bit late...
Much appreciated!
The usual way that this sort of thing causes trouble is if there is a
single store instruction that changes the value from MIGRATE_ISOLATE
to MIGRATE_CMA, and if the compiler decides to fetch twice, AND twice,
Doing an AND twice for "x & constant" this definitely blows my mind. Is
nothing sacred? :)
and then combine the results. This could give a zero outcome where the
underlying variable never had the value zero.
Is this sort of thing low probability?
Definitely.
Isn't this sort of thing prohibited?
Definitely not.
So what you have will likely work for at least a while longer, but it
is not guaranteed and it forces you to think a lot harder about what
the current implementations of the compiler can and cannot do to you.
The following LWN article goes through some of the possible optimizations
(vandalisms?) in this area: https://lwn.net/Articles/793253/
hmm, I don't think we hit any of those cases, do we? Because here, the
"write" side is via a non-inline function that I just don't believe the
compiler is allowed to call twice. Or is it?
Minchan's earlier summary:
CPU 0 CPU1
set_pageblock_migratetype(MIGRATE_ISOLATE)
if (get_pageblock_migrate(page) & MIGRATE_CMA)
set_pageblock_migratetype(MIGRATE_CMA)
if (get_pageblock_migrate(page) & MIGRATE_ISOLATE)
...where set_pageblock_migratetype() is not inline.
thanks,
--
John Hubbard
NVIDIA
In the end, it is your code, so you get to decide how much you would
like to keep track of what compilers get up to over time. ;-)
Thanx, Paul
