| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
 RE: [Xen-devel] Question about printk implementation.
 
 OK.  We crossed emails.  You answered what I asked in the other.
 Thanks a bunch.
 Roger
 
 
 -----Original Message-----
 From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
 Sent: Wed 9/15/2010 5:07 PM
 To: Roger Cruz; xen-devel@xxxxxxxxxxxxxxxxxxx
 Subject: Re: [Xen-devel] Question about printk implementation.
 
 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
 
 
 
 No virus found in this incoming message.
 Checked by AVG - www.avg.com
 Version: 9.0.851 / Virus Database: 271.1.1/3134 - Release Date: 09/15/10 02:34:00
 
 
 _______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
 
 |