Messages in this thread | | | Date | Mon, 11 Jul 2011 11:39:31 -0400 | From | Don Zickus <> | Subject | Re: pstore dump inside an nmi handler |
| |
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
| |