On Tue, Jul 19, 2011 at 08:27:54PM +0100, Matthew Garrett wrote: > On Tue, Jul 19, 2011 at 03:14:22PM -0400, Seiji Aguchi wrote: > > > > >And how does that handle the case where we're halfway through a pstore > > >access when the NMI arrives? ERST, at least, has a complex state > > >machine. You can't guarantee what starting one transaction without > > >completing one that was in process will do. > > > > As for ERST, write access is protected by raw_spin_trylock_irqsave(&erst_lock). > > Are there anything I'm missing? > > If there's already locking involved, what benefit does removing the lock > in the pstore code give? You'll just hang when you hit the erst code > instead of the pstore code. I'm sorry, you're right, this is a trylock so we won't hang in this case. We should probably document that in the pstore documentation to ensure that any future backends have the same behaviour. -- Matthew Garrett | mjg59 at srcf.ucam.org
