On Thu, Aug 22, 2019 at 02:31:17PM -0500, Scott Wood wrote: > On Thu, 2019-08-22 at 09:59 -0400, Joel Fernandes wrote: > > On Wed, Aug 21, 2019 at 06:19:06PM -0500, Scott Wood wrote: > > > I think the prohibition on use_softirq can be dropped once RT gets the > > > latest RCU code, but the question of what use_softirq should default > > > to on PREEMPT_RT remains. > > > > Independent of the question of what use_softirq should default to, could > > we > > test RT with latest RCU code now to check if the deadlock goes away? That > > way, maybe we can find any issues in current RCU that cause scheduler > > deadlocks in the situation you pointed. The reason I am asking is because > > recently additional commits [1] try to prevent deadlock and it'd be nice > > to > > ensure that other conditions are not lingering (I don't think they are but > > it'd be nice to be sure). > > > > I am happy to do such testing myself if you want, however what does it > > take > > to apply the RT patchset to the latest mainline? Is it an achievable feat? > > I did run such a test (cherry picking all RCU patches that aren't already in > RT, plus your RFC patch to rcu_read_unlock_special, rather than applying RT > to current mainline) with rcutorture plus a looping kernel build overnight, > and didn't see any splats with or without use_softirq. Cool, that's good to know you didn't see splats! thanks, - Joel
