On 2024-11-21 17:50:06 [+0100], Alessandro Carminati wrote: > Hello Sebastian, Hi Alessandro, > On Wed, Nov 20, 2024 at 5:40 PM Sebastian Andrzej Siewior > <bigeasy@xxxxxxxxxxxxx> wrote: > > > > On 2024-11-20 10:26:02 [-0500], Steven Rostedt wrote: > > > The "%pK" dereferences a pointer and there's some SELinux hooks attached to > > > that code. The problem is that the SELinux hooks take spinlocks. This would > > > not have been an issue if it wasn't for that "%pK" in the format. > > > > That is missing check and I think Thomas Weissschuh wanted to add it. So > > we don't call into selinux. > > Your comment confuses me a bit, as I'm unsure what Thomas is actually > working on. > Am I correct in assuming he's addressing a fix in lib/vsprintf.c to ensure > that sleeping functions aren't called, allowing these functions to work in > any context? restricted_pointer() has a check for in_hardirq() among others. This needs an additional PREEMPT_RT check. I would be actual in favour to get rid of case 1 for kptr_restrict and have either 0 or 2. > However, his mention of "This fix for kmemleak is still needed as the > pointers in the kmemleak report are useful" adds to my confusion. > Meanwhile, Steven suggests reworking SELinux to resolve the issue. > Could you clarify what you mean by "So we don't call into selinux"? This getting out of hand. By adding the PREEMPT_RT check to restricted_pointer() we don't call in selinux so the problem is gone. kmemleak is not the only problem. printk(), as another of vspritf pointer code user, can be called from any place and would also trigger a warning here. As far as "kmemleak need to be usefull" goes: With kptr_restrict == 0 then with or without pointer hashing they will be useful. If we need to go via selinux then it ends as a hint. Sebastian
