Am 15.09.2015 um 18:42 schrieb Paolo Bonzini: > > > 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. Right. This also implies that we should fix this for 4.2 - I guess. Christian -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
