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. > > 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. at https://lkml.kernel.org/r/ZnvVQ5cs9F0b7paI@xxxxxxxxxxxxxxx ?
