Dmitry Vyukov wrote: > If the race described in > http://www.spinics.net/lists/cgroups/msg14078.html does actually > happen, then there is nothing to check. > https://gcc.gnu.org/ml/gcc/2012-02/msg00005.html talks about different > memory locations, if there is store-widening involving different > memory locations, then this is a compiler bug. But the race happens on > a single memory location, in such case the code is buggy. > All ->in_execve ->in_iowait ->sched_reset_on_fork ->sched_contributes_to_load ->sched_migrated ->memcg_may_oom ->memcg_kmem_skip_account ->brk_randomized shares the same byte. sched_fork(p) modifies p->sched_reset_on_fork but p is not yet visible. __sched_setscheduler(p) modifies p->sched_reset_on_fork. try_to_wake_up(p) modifies p->sched_contributes_to_load. perf_event_task_migrate(p) modifies p->sched_migrated. Trying to reproduce this problem with static __always_inline bool perf_sw_migrate_enabled(void) { - if (static_key_false(&perf_swevent_enabled[PERF_COUNT_SW_CPU_MIGRATIONS])) - return true; return false; } would help testing ->sched_migrated case. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>