On Wed, 20 Jan 2016, Sasha Levin wrote: > > As I've mentioned - this reproduces frequently. I'd be happy to add in debug > information into the kernel that might help you reproduce it, but as it seems > like a timing issue, I can't provide a simple reproducer. This isnt really important I think. Lets remove it. Subject: vmstat: Remove BUG_ON from vmstat_update If we detect that there is nothing to do just set the flag and do not check if it was already set before. Races really do not matter. If the flag is set by any code then the shepherd will start dealing with the situation and reenable the vmstat workers when necessary again. Concurrent actions could be onlining and offlining of processors or be a result of concurrency issues when updating the cpumask from multiple processors. Signed-off-by: Christoph Lameter <cl@xxxxxxxxx> Index: linux/mm/vmstat.c =================================================================== --- linux.orig/mm/vmstat.c +++ linux/mm/vmstat.c @@ -1408,17 +1408,7 @@ static void vmstat_update(struct work_st * Defer the checking for differentials to the * shepherd thread on a different processor. */ - int r; - /* - * Shepherd work thread does not race since it never - * changes the bit if its zero but the cpu - * online / off line code may race if - * worker threads are still allowed during - * shutdown / startup. - */ - r = cpumask_test_and_set_cpu(smp_processor_id(), - cpu_stat_off); - VM_BUG_ON(r); + cpumask_set_cpu(smp_processor_id(), cpu_stat_off); } } -- 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>