On 2022-04-01 10:10:38 [+0000], Zhang, Qiang1 wrote: > >Could we fix in a way that we don't involve freeing memory from in-IRQ? > >This could trigger a lockdep splat if the local-lock in SLUB is acquired from in-IRQ context on !PREEMPT_RT. > > Hi, I will move qlist_free_all() from IPI context to task context, > This operation and the next release members > in the quarantine pool operate similarly > > I don't know the phenomenon you described. Can you explain it in detail? If you mean by phenomenon my second sentence then the kernel option CONFIG_PROVE_RAW_LOCK_NESTING will trigger on !PREEMPT_RT in a code sequence like raw_spin_lock() spin_lock(); which is wrong on PREEMPT_RT. So we have a warning on both configurations. The call chain in your case will probably not lead to a warning since there is no raw_spinlock_t involved within the IPI call. We worked on avoiding memory allocation and freeing from in-IRQ context therefore I would prefer to have something that works for both and not just ifdef around the RT-case. > Thanks > Zqiang Sebastian
