On Tue 2024-06-25 17:53:14, John Ogness wrote: > On 2024-06-26, Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > > On 2024/06/25 23:17, John Ogness wrote: > >> On 2024-06-25, Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > >>> syzbot is reporting circular locking dependency inside __bpf_prog_run(), > >>> for fault injection calls printk() despite rq lock is already held. > >>> > >>> Guard __bpf_prog_run() using printk_deferred_{enter,exit}() (and > >>> preempt_{disable,enable}() if CONFIG_PREEMPT_RT=n) in order to defer any > >>> printk() messages. > >> > >> Why is the reason for disabling preemption? > > > > Because since kernel/printk/printk_safe.c uses a percpu counter for deferring > > printk(), printk_safe_enter() and printk_safe_exit() have to be called from > > the same CPU. preempt_disable() before printk_safe_enter() and preempt_enable() > > after printk_safe_exit() guarantees that printk_safe_enter() and > > printk_safe_exit() are called from the same CPU. > > Yes, but we already have cant_migrate(). Are you suggesting there are > configurations where cant_migrate() is true but the context can be > migrated anyway? IMHO, we want to enter printk_safe only with preemption disabled. Otherwise, printk() would stay deferred on the given CPU for any task scheduled in this section. Best Regards, Petr