On Fri, 13 Dec 2024 10:44:26 -0800 Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > But this is not the case. I'm not sure what would happen here, but it is > > definitely out of scope of the requirements of the PI logic and thus, > > trylock must also not be used in hard interrupt context. > > If hard-irq acquired rt_mutex B (spin_lock or spin_trylock doesn't > change the above analysis), the task won't schedule > and it has to release this rt_mutex B before reenabling irq. > The irqrestore without releasing the lock is a bug regardless. > > What's the concern then? That PI may see an odd order of locks for this task ? > but it cannot do anything about it anyway, since the task won't schedule. > And before irq handler is over the B will be released and everything > will look normal again. The problem is the chain walk. It could also cause unwanted side effects in RT. If low priority task 1 has lock A and is running on another CPU and low priority task 2 blocks on lock A and then is interrupted right before going to sleep as being "blocked on", and takes lock B in the interrupt context. We then have high priority task 3 on another CPU block on B which will then see that the owner of B is blocked (even though it is not blocked for B), it will boost its priority as well as the owner of the lock (A). The A owner will get boosted where it is not the task that is blocking the high priority task. My point is that RT is all about deterministic behavior. It would require a pretty substantial audit to the PI logic to make sure that this doesn't cause any unexpected results. My point is, the PI logic was not designed for taking a lock after being blocked on another lock. It may work, but we had better prove and show all side effects that can happen in these cases. -- Steve
