Re: [Xen-devel] Question about printk implementation.

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 15/09/2010 22:03, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

> On 15/09/2010 21:24, "Roger Cruz" <roger.cruz@xxxxxxxxxxxxxxxxxxx> wrote:
> 
>> I was looking over the implementation of printk (xenunstable) and I have a
>> question about the spin_lock_recursive use and the static "buf" variable in
>> this routine.  Suppose that that in a single processor system the hypervisor
>> is printing using this printk routine and has acquired the console_lock.  Is
>> it possible for a high level interrupt, like an NMI (just as an example, any
>> other interrupts that preempt the current work in the hypervisor will do), to
>> come in and then use printk.  Because we are in single CPU mode, the
>> spin_lock_recursive will succeed (if I interpreted the code correctly).  When
>> the higher level interrupt exits and returns to the hypervisor code that was
>> previously printing, the contents of the static "buf" would have changed.  Is
>> this a possibility??
> 
> Well yeah, you know what? Don't do that then! Our printk (like very many Xen
> functions) is not NMI safe.

Oh, I see you are thinking of any arbitrary hardirq. Note that we
local_irq_save() before acquiring the console_lock. This has the effect of
disabling irqs while we hold the console_lock. So we cannot be interrupted
on the local CPU (and as I already said, although NMIs can still interrupt
the local CPU, we shouldn't use printk() in NMI context except in fatal
error circumstances where we are prepared to bust the console_lock first).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel