Re: [PATCH 3/3] lib/vsprintf: Use pr_crit() instead of long fancy messages

2021-05-20 Thread Petr Mladek via iommu
On Mon 2021-05-17 08:21:12, Geert Uytterhoeven wrote: > On Wed, Mar 31, 2021 at 11:59 AM Geert Uytterhoeven > wrote: > > While long fancy messages have a higher probability of being seen than > > small messages, they may scroll of the screen fast, if visible at all, > > and may still be missed.

Re: [PATCH] iommu/amd: Fix extended features logging

2021-04-12 Thread Petr Mladek via iommu
On Sun 2021-04-11 14:08:14, Joe Perches wrote: > On Sun, 2021-04-11 at 21:52 +0200, John Ogness wrote: > > I'd rather fix dev_info callers to allow pr_cont and then fix any code > > that is using this workaround. > > Assuming you mean all dev_() uses, me too. > > > And if the print maintainers

Re: [PATCH] iommu/amd: Fix extended features logging

2021-04-12 Thread Petr Mladek via iommu
On Sun 2021-04-11 21:52:59, John Ogness wrote: > On 2021-04-11, Alexander Monakov wrote: > >>> The second line is emitted via 'pr_cont', which causes it to have a > >>> different ('warn') loglevel compared to the previous line ('info'). > >>> > >>> Commit 9a295ff0ffc9 attempted to rectify this

Re: [PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages

2021-04-01 Thread Petr Mladek via iommu
On Wed 2021-03-31 09:40:07, Steven Rostedt wrote: > On Wed, 31 Mar 2021 11:31:03 +0200 > Geert Uytterhoeven wrote: > > > This reduces kernel size by ca. 0.5 KiB. > > If you are worried about size, disable tracing and it will go away > entirely. 0.5KiB is a drop in the bucket compared to what

Re: [PATCH v2 07/17] debugobjects: Move printk out of db lock critical sections

2018-11-29 Thread Petr Mladek
On Mon 2018-11-26 13:57:09, Sergey Senozhatsky wrote: > On (11/23/18 12:48), Petr Mladek wrote: > [..] > > > This should make serial consoles re-entrant. > > > So printk->console_driver_write() hopefully will not deadlock. > > > > Is the re-entrance safe

Re: [PATCH v2 07/17] debugobjects: Move printk out of db lock critical sections

2018-11-23 Thread Petr Mladek
On Fri 2018-11-23 11:40:48, Sergey Senozhatsky wrote: > On (11/22/18 11:16), Peter Zijlstra wrote: > > > So maybe we need to switch debug objects print-outs to _always_ > > > printk_deferred(). Debug objects can be used in code which cannot > > > do direct printk() - timekeeping is just one

Re: [PATCH v2 07/17] debugobjects: Move printk out of db lock critical sections

2018-11-23 Thread Petr Mladek
On Thu 2018-11-22 15:29:35, Waiman Long wrote: > On 11/22/2018 11:02 AM, Petr Mladek wrote: > > Anyway, I wonder what was the primary motivation for this patch. > > Was it the system hang? Or was it lockdep report about nesting > > two terminal locks: db->lock, po

Re: [PATCH v2 07/17] debugobjects: Move printk out of db lock critical sections

2018-11-23 Thread Petr Mladek
On Thu 2018-11-22 14:57:02, Waiman Long wrote: > On 11/21/2018 09:04 PM, Sergey Senozhatsky wrote: > > On (11/21/18 11:49), Waiman Long wrote: > > [..] > >>> case ODEBUG_STATE_ACTIVE: > >>> - debug_print_object(obj, "init"); > >>> state = obj->state; > >>>

Re: [PATCH v2 09/17] debugobjects: Make object hash locks nestable terminal locks

2018-11-23 Thread Petr Mladek
On Thu 2018-11-22 15:17:52, Waiman Long wrote: > On 11/22/2018 10:33 AM, Petr Mladek wrote: > > On Mon 2018-11-19 13:55:18, Waiman Long wrote: > >> By making the object hash locks nestable terminal locks, we can avoid > >> a bunch of unnecessary lockdep validati

Re: [PATCH v2 07/17] debugobjects: Move printk out of db lock critical sections

2018-11-22 Thread Petr Mladek
On Thu 2018-11-22 11:04:22, Sergey Senozhatsky wrote: > On (11/21/18 11:49), Waiman Long wrote: > [..] > > > case ODEBUG_STATE_ACTIVE: > > > - debug_print_object(obj, "init"); > > > state = obj->state; > > > raw_spin_unlock_irqrestore(>lock, flags); > > > +

Re: [PATCH v2 09/17] debugobjects: Make object hash locks nestable terminal locks

2018-11-22 Thread Petr Mladek
On Mon 2018-11-19 13:55:18, Waiman Long wrote: > By making the object hash locks nestable terminal locks, we can avoid > a bunch of unnecessary lockdep validations as well as saving space > in the lockdep tables. Please, explain which terminal lock might be nested. Hmm, it would hide eventual