On Thu 21-01-16 09:45:12, Christoph Lameter wrote: > On Thu, 21 Jan 2016, Michal Hocko wrote: [...] > > The vmstat update might be still waiting for its timer, idle mode started > > and kick vmstat_update which might cpumask_test_and_set_cpu. Once the > > idle terminates and the originally schedule vmstate_update executes it > > sees the bit set and BUG_ON. > > Ok so we are going into idle mode and the vmstat_update timer is pending. > Then the timer will not fire since going idle switches preemption off. > quiet_vmstat will run without the chance of running vmstat_update > > We could be going idle and not have disabled preemption yet. Then > vmstat_update will run. On return to the idling operation preemption will > be disabled and quiet_vmstat() will be run. > > I do not see how these two things could race. It goes like this: CPU0: CPU1 vmstat_update cpumask_test_and_set_cpu (0->1) [...] vmstat_shepherd <enter idle> cpumask_test_and_clear_cpu(CPU0) (1->0) quiet_vmstat cpumask_test_and_set_cpu (0->1) queue_delayed_work_on(CPU0) refresh_cpu_vm_stats() [...] vmstat_update nothing_to_do cpumask_test_and_set_cpu (1->1) VM_BUG_ON Or am I missing something? -- Michal Hocko SUSE Labs -- 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>