On Thu 2016-09-01 16:55:07, Sergey Senozhatsky wrote:
> On (08/30/16 13:19), Petr Mladek wrote:
> >
> > I see. But then we will need to be more careful because printk_func
> > and printk_func_saved will be manipulated in different contexts:
> > normal, irq, nmi. A solution might be using an atomic
On (08/30/16 13:19), Petr Mladek wrote:
>
> I see. But then we will need to be more careful because printk_func
> and printk_func_saved will be manipulated in different contexts:
> normal, irq, nmi. A solution might be using an atomic counter
> and selecting the right vprintk_func according to the
On (08/30/16 13:19), Petr Mladek wrote:
[..]
> > yes, x86 has a per-cpu nmi_state to handle the case when NMI is
> > loosing its NMI context. But other arch-s, as far as I can see,
> > don't do that. Does it mean that we are safe only on x86?
>
> My understanding is that the kernel would crash on
On Tue 2016-08-30 18:39:18, Sergey Senozhatsky wrote:
> On (08/30/16 11:04), Petr Mladek wrote:
> > On Tue 2016-08-30 16:58:34, Sergey Senozhatsky wrote:
> > > Petr,
> > > one more question. Not related to the patch, but still related to NMI.
> > >
> > > can NMI nest?
> >
> > AFAIK, they cannot.
On (08/30/16 11:04), Petr Mladek wrote:
> On Tue 2016-08-30 16:58:34, Sergey Senozhatsky wrote:
> > Petr,
> > one more question. Not related to the patch, but still related to NMI.
> >
> > can NMI nest?
>
> AFAIK, they cannot. NMIs should be disabled until iret is called.
> Therefore we should be
On Tue 2016-08-30 16:58:34, Sergey Senozhatsky wrote:
> Petr,
> one more question. Not related to the patch, but still related to NMI.
>
> can NMI nest?
AFAIK, they cannot. NMIs should be disabled until iret is called.
Therefore we should be on the safe side if iret is not called
inside the NMI h
Petr,
one more question. Not related to the patch, but still related to NMI.
can NMI nest?
CPU0
-> NMI#0
printk_nmi_enter()
this_cpu_write(printk_func, vprintk_nmi)
...
=> NMI#1
: printk_nmi_
On (08/29/16 17:16), Petr Mladek wrote:
[..]
> The comment above is not longer valid.
oh, yes. it shouldn't even be there.
> > -static void print_nmi_seq_line(struct nmi_seq_buf *s, int start, int end)
> > +static void __print_nmi_seq_line(const char *text, int len)
>
> Also the name of the func
On Mon 2016-08-29 21:32:20, Sergey Senozhatsky wrote:
> From: Sergey Senozhatsky
>
> __printk_nmi_flush() can be called from nmi_panic(), therefore it has to
> test whether it's executed in NMI context and thus must route the messages
> through deferred printk() or via direct printk(). Except for
From: Sergey Senozhatsky
__printk_nmi_flush() can be called from nmi_panic(), therefore it has to
test whether it's executed in NMI context and thus must route the messages
through deferred printk() or via direct printk(). Except for two places
where __printk_nmi_flush() does unconditional direct
10 matches
Mail list logo
