[PATCH 00/50] Add log level to show_stack()
Dmitry Safonov
dima at arista.com
Wed Nov 13 13:25:15 AEDT 2019
On 11/13/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/12 19:12), Sergey Senozhatsky wrote:
>> On (19/11/12 09:35), Petr Mladek wrote:
>> [..]
>>> This is getting too complicated. It would introduce too many
>>> hidden rules. While the explicitly passed loglevel parameter
>>> is straightforward and clear.
>>
>> If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
>> (either downgrade or upgrade). That's one rule, basically. Not too
>> complicated, I guess.
>
> Can be taken even a bit further than
>
> show_stack(NULL, NULL, LOGLEVEL_DEBUG);
> or
> show_stack(NULL, NULL, LOGLEVEL_ERR);
>
> For instance,
>
> spin_lock_irqsave(&rq->lock, flags);
> printk_emergency_enter(LOGLEVEL_SCHED);
> ...
> show_stack(...);
> printk();
> printk();
> ...
> spin_unlock_irqrestore(&rq->lock, flags);
>
> or
>
> spin_lock_irqsave(&uart_port->lock, flags);
> printk_emergency_enter(LOGLEVEL_SCHED);
> ...
> printk();
> printk();
> ...
Yeah, that makes sense.
I believe it's up to you, Petr and Steven to decide what's better for
printk(). I mean, after all you care for all this code.
I guess I've pointed that in my point of view price for one-time testing
code is cheaper than adding a new printk feature to swap log levels on
the fly. But again, it's just how I see it - if we fix those printing
problems, than in half year we will forget they ever existed, but in
your proposal, there will still be some clever printk code.
On the other side, also worth to note that current patches set fix
problems for kdb (and for my hung task printing patch), but it's
incomplete for sysrq driver. I've gone through functions used by sysrq
driver and the same changes introducing log level parameter would be
needed for: sched_show_task(), debug_show_all_locks(), show_regs(),
show_state(), show_mem(). Some of them don't need any platform changes,
but at least show_regs() needs.
So, you also need to have that in mind making the decision.
Thanks,
Dmitry
More information about the Linuxppc-dev
mailing list