On Mon, Nov 19, 2018 at 01:55:16PM -0500, Waiman Long wrote:
> The db->lock is a raw spinlock and so the lock hold time is supposed
> to be short. This will not be the case when printk() is being involved
> in some of the critical sections. In order to avoid the long hold time,
> in case some
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? Some risk might be acceptable in
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? Some risk might be acceptable in Oops/panic
> situations. It is much less acceptable for random warnings.
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
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, pool_lock with logbuf_lock?
>
> The
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;
> >>>
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 example.
>
> No, printk_deferred() is a disease, it needs to be
On (11/22/18 14:57), Waiman Long wrote:
> > [..]
> >> As a side note, one of the test systems that I used generated a
> >> debugobjects splat in the bootup process and the system hanged
> >> afterward. Applying this patch alone fix the hanging problem and the
> >> system booted up successfully. So
On 11/22/2018 11:02 AM, Petr Mladek wrote:
> 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;
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;
>>> raw_spin_unlock_irqrestore(>lock, flags);
>>> +
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);
> > > +
On Thu, Nov 22, 2018 at 11:04:22AM +0900, Sergey Senozhatsky wrote:
> Some serial consoles call mod_timer(). So what we could have with the
> debug objects enabled was
>
> mod_timer()
>lock_timer_base()
> debug_activate()
> printk()
>
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);
> > + debug_print_object(obj, "init");
> >
On 11/19/2018 01:55 PM, Waiman Long wrote:
> The db->lock is a raw spinlock and so the lock hold time is supposed
> to be short. This will not be the case when printk() is being involved
> in some of the critical sections. In order to avoid the long hold time,
> in case some messages need to be
14 matches
Mail list logo
