On Wed, Jun 26, 2024 at 4:09 PM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > > On 2024/06/27 7:33, Steven Rostedt wrote: > > So you are saying that because a BPF hook can attach to a tracepoint > > that is called with rq locks held, it should always disable preemption > > and call printk_deferred_enter(), because it *might* hit an error path > > that will call printk?? In other words, how the BPF hook is used > > determines if the rq lock is held or not when it is called. > > Yes. > > > > > I can use that same argument for should_fail_ex(). Because how it is > > used determines if the rq lock is held or not when it is called. And it > > is the function that actually calls printk(). > > Strictly speaking, KASAN/KMSAN/KCSAN etc. *might* call printk() at any location. > In that aspect, just wrapping individual function that explicitly calls printk() > might not be sufficient. We will need to widen section for deferring printk(), > but we don't want to needlessly call migrate_disable()/preempt_disable()/ > printk_deferred_enter() due to performance reason. We need to find a balanced > location for calling migrate_disable()/preempt_disable()/printk_deferred_enter(). > I consider __bpf_prog_run() as a balanced location. Tetsuo, your repeated invalid arguments are not making this thread productive. Told you already that the same can happen without bpf in the picture. > > > > Sorry, but it makes no sense to put the burden of the > > printk_deferred_enter() on the BPF hook logic. It should sit solely > > with the code that actually calls printk(). > > How do you respond to Petr Mladek's comment > > Yeah, converting printk() into printk_deferred() or using > printk_deferred_enter() around particular code paths is a whac-a-mole > game. Exactly. wrapping bpf with printk_deferred_enter() is such a whac-a-mole. It doesn't fix an issue.
