Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [patch V2 4/9] softirq: Make softirq control and processing RT aware | Date | Wed, 09 Dec 2020 14:30:13 +0100 |
| |
On Wed, Dec 09 2020 at 13:42, Peter Zijlstra wrote: > On Wed, Dec 09, 2020 at 01:36:54PM +0100, Thomas Gleixner wrote: >> On Wed, Dec 09 2020 at 11:11, Peter Zijlstra wrote: >> > On Fri, Dec 04, 2020 at 06:01:55PM +0100, Thomas Gleixner wrote: >> >> From: Thomas Gleixner <tglx@linutronix.de> >> >> + /* First entry of a task into a BH disabled section? */ >> >> + if (!current->softirq_disable_cnt) { >> >> + if (preemptible()) { >> >> + local_lock(&softirq_ctrl.lock); >> > >> > AFAICT this significantly changes the locking rules. >> > >> > Where previously we could do: >> > >> > spin_lock(&ponies) >> > spin_lock_bh(&foo); >> > >> > vs >> > >> > spin_lock_bh(&bar); >> > spin_lock(&ponies) >> > >> > provided the rest of the code observed: bar -> ponies -> foo >> > and never takes ponies from in-softirq. >> > >> > This is now a genuine deadlock on RT. >> >> I know, but making this work is trying to square the circle. > > :-) > >> Any approach we tried before going this way had worse problems than >> this particular limitation. > > OK, but that would've been very good Changelog material methinks.
Let me add that.
> Also, then we should probably make sure PREEMPT_RT=n builds start > suffering the same problem by adding the local_lock unconditionally, > otherwise this keeps being a PREEMPT_RT special and we'll keep having to > fix it up.
For lockdep builds I assume. I'd like to postpone that for a while like we postponed the rawlock nesting lockdep stuff until we have the vast majority sorted out.
Thanks,
tglx
| |