Messages in this thread | | | Date | Fri, 25 Sep 2020 09:54:00 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [RFC 2/2] printk: Add more information about the printk caller |
| |
On (20/09/24 15:38), Petr Mladek wrote: [..] > > Grrrr, I wonder why I thought that in_irq() covered also the situation > when IRQ was disabled. It was likely my wish because disabled > interrupts are problem for printk() because the console might > cause a softlockup.
preempt_disable() can also trigger softlockup.
> in_irq() actually behaves like in_serving_softirq(). > > I am confused and puzzled now. I wonder what contexts are actually > interesting for developers. It goes back to the ideas from Sergey > about preemption disabled, ...
Are we talking about context tracking for LOG_CONT or context on the serial console and /dev/kmsg?
If the latter, then my 5 cents, is that something like preemptible(), which checks
(preempt_count() == 0 && !irqs_disabled())
does not look completely unreasonable.
We had a rather OK context tracking in printk() before, but for a completely different purpose:
console_may_schedule = !oops_in_progress && preemptible() && !rcu_preempt_depth();
We know that printk() can cause RCU stalls [0]. Tracking this part of the context state is sort of meaningful.
Let's look at this from this POV - why do we add in_irq()/etc tracking info? Perhaps because we want to connect the dots between printk() caller state and watchdog reports. Do we cover all watchdogs? No, I don't think so. RCU stalls, local_irq_disable(), preempt_disable() are not covered.
Do we have any technical reasons not to add those missing bits?
[0] https://lkml.org/lkml/2018/1/9/485
-ss
| |