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 from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
