Re: pstore dump inside an nmi handler

[Don Zickus <dzickus@redhat.com>]

On Fri, Jul 08, 2011 at 10:49:41PM +0100, Matthew Garrett wrote:
> On Fri, Jul 08, 2011 at 02:40:13PM -0700, Luck, Tony wrote:
> > > Inside pstore_dump(), the first thing it tries to grab is a mutex_lock()
> > > (inside an nmi hander).  This seems to be the root cause of my problems.
> > 
> > Someone else pointed out that mutex_lock() is a problem here too. They
> > wondered whether spin_lock_irqsave() would work - or whether pstore
> > backends were allowed to sleep - to which I said I hoped they didn't,
> > but wasn't really sure what the future will hold.
> 
> EFI can't sleep (at least, not as far as the kernel's concerned), so 
> we're safe there. I think it's fair to assume atomicity here - crash 
> dumping is a pretty specific situation. Although we may need to think 
> about whether pstore should be saving reboot and poweroff in that case.

Hmm, reading the ERST spec in ACPI4 (which is the backend behind pstore on
x86 boxes), it seems that reading/writing involves a state machine.  The
code doesn't seem to account for this if in the middle of reading an error
record, a system error occurs and you need to write an error record.  I
imagine the state machine would get screwed up and you would lose any info
you tried writing.

But perhaps, if we detect a spinlock is in use, we can bust it and reset
the state machine to solve that problem?

Cheers,
Don