On Tue 2016-10-11 16:35:28, Sergey Senozhatsky wrote:
> On (10/10/16 13:17), Petr Mladek wrote:
> [..]
> > > it may look that lockdep *probably* can report the issues via 'safe'
> > > printk,
> > > but that's a notably huge behavior breakage -- if lockdep report comes
> > > from
> > > an about-to
On (10/10/16 13:17), Petr Mladek wrote:
[..]
> > it may look that lockdep *probably* can report the issues via 'safe' printk,
> > but that's a notably huge behavior breakage -- if lockdep report comes from
> > an about-to-deadlock irq handler, then we won't see anything from that CPU
> > unless the
On Mon 2016-10-10 13:09:57, Sergey Senozhatsky wrote:
> On (10/06/16 13:32), Petr Mladek wrote:
> > On Thu 2016-10-06 13:22:48, Sergey Senozhatsky wrote:
> > > On (10/05/16 11:50), Petr Mladek wrote:
> > > [..]
> > > > > well, it solves a number of problems that the existing implementation
> > > >
On (10/06/16 13:32), Petr Mladek wrote:
> On Thu 2016-10-06 13:22:48, Sergey Senozhatsky wrote:
> > On (10/05/16 11:50), Petr Mladek wrote:
> > [..]
> > > > well, it solves a number of problems that the existing implementation
> > > > cannot handle.
> > >
> > > Please, provide a summary. I wonder
On Thu 2016-10-06 13:22:48, Sergey Senozhatsky wrote:
> On (10/05/16 11:50), Petr Mladek wrote:
> [..]
> > > well, it solves a number of problems that the existing implementation
> > > cannot handle.
> >
> > Please, provide a summary. I wonder if these are real life problems.
>
> 1) some pathces/
On (10/05/16 11:50), Petr Mladek wrote:
[..]
> > well, it solves a number of problems that the existing implementation
> > cannot handle.
>
> Please, provide a summary. I wonder if these are real life problems.
anything that starts from printk().
I'm trying to address printk() recursion only, by
On Wed 2016-10-05 10:36:57, Sergey Senozhatsky wrote:
> On (10/04/16 14:22), Petr Mladek wrote:
> [..]
> > if (retry && console_trylock())
> > goto again;
> >
> > with a safe variant, something like
> >
> > if (retry) {
> > local_irq_save(flags);
> > al
On Wed 2016-10-05 10:27:14, Sergey Senozhatsky wrote:
> On (10/04/16 16:52), Petr Mladek wrote:
> > >
> > > Or is there any other catch that I do not see at the moment?
> >
> > And there is :-( The above logic looked at the problem only from
> > one side. It was about errors starting from the pri
On (10/04/16 14:22), Petr Mladek wrote:
[..]
> if (retry && console_trylock())
> goto again;
>
> with a safe variant, something like
>
> if (retry) {
> local_irq_save(flags);
> alt_printk_enter();
> lock_failed = console_trylock(
On (10/04/16 16:52), Petr Mladek wrote:
> >
> > Or is there any other catch that I do not see at the moment?
>
> And there is :-( The above logic looked at the problem only from
> one side. It was about errors starting from the printk()
> code itself, for example:
yes, like I said - printk recur
On Fri 2016-09-30 13:15:46, Petr Mladek wrote:
> On Fri 2016-09-30 10:15:44, Sergey Senozhatsky wrote:
> > On (09/29/16 15:00), Petr Mladek wrote:
> > [..]
> > > > @@ -1791,7 +1791,7 @@ asmlinkage int vprintk_emit(int facility, int
> > > > level,
> > > > zap_locks();
> > > >
On Sat 2016-10-01 11:48:29, Sergey Senozhatsky wrote:
> On (09/30/16 13:15), Petr Mladek wrote:
> > > do you mean that, once alt_printk is done properly, we can drop
> > > printk_deferred()? I was thinking of it, but decided not to
> > > mention/touch it in this patch set.
> >
> > My understanding
On (09/30/16 13:15), Petr Mladek wrote:
[..]
> > and the decision was to keep `unsigned long flags' on stack in the
> > alt_enter/exit caller. besides in most of the cases we already have
> > it (in vprintk_emit() and console_unlock()).
>
> I would pass the pointer to flags as alt_enter() paramete
On (09/30/16 13:15), Petr Mladek wrote:
[..]
> > and the decision was to keep `unsigned long flags' on stack in the
> > alt_enter/exit caller. besides in most of the cases we already have
> > it (in vprintk_emit() and console_unlock()).
>
> I would pass the pointer to flags as alt_enter() paramete
On Fri 2016-09-30 10:15:44, Sergey Senozhatsky wrote:
> On (09/29/16 15:00), Petr Mladek wrote:
> [..]
> > > @@ -1791,7 +1791,7 @@ asmlinkage int vprintk_emit(int facility, int level,
> > > zap_locks();
> > > }
> > >
> > > - lockdep_off();
> > > + alt_printk_enter();
> >
> > IMHO, we
On (09/29/16 15:00), Petr Mladek wrote:
[..]
> > @@ -1791,7 +1791,7 @@ asmlinkage int vprintk_emit(int facility, int level,
> > zap_locks();
> > }
> >
> > - lockdep_off();
> > + alt_printk_enter();
>
> IMHO, we could not longer enter vprintk_emit() recursively. The same
> sec
On Tue 2016-09-27 23:22:36, Sergey Senozhatsky wrote:
> Use alt_printk buffer in in printk recursion-prone blocks:
> -- around logbuf_lock protected sections in vprintk_emit() and
>console_unlock()
> -- around down_trylock_console_sem() and up_console_sem()
>
> Note that it addresses deadlocks
Use alt_printk buffer in in printk recursion-prone blocks:
-- around logbuf_lock protected sections in vprintk_emit() and
console_unlock()
-- around down_trylock_console_sem() and up_console_sem()
Note that it addresses deadlocks caused by recursiove printk()
calls only.
Examples:
1) printk()
18 matches
Mail list logo
