On 15/09/2015 15:36, Christian Borntraeger wrote: > I am wondering why the old code behaved in such fatal ways. Is there > some interaction between waiting for a reschedule in the > synchronize_sched writer and some fork code actually waiting for the > read side to get the lock together with some rescheduling going on > waiting for a lock that fork holds? lockdep does not give me an hints > so I have no clue :-(
It may just be consuming too much CPU usage. kernel/rcu/tree.c warns about it: * if you are using synchronize_sched_expedited() in a loop, please * restructure your code to batch your updates, and then use a single * synchronize_sched() instead. and you may remember that in KVM we switched from RCU to SRCU exactly to avoid userspace-controlled synchronize_rcu_expedited(). In fact, I would say that any userspace-controlled call to *_expedited() is a bug waiting to happen and a bad idea---because userspace can, with little effort, end up calling it in a loop. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
