RE: [RFC][PATCH -next] pstore: replace spin_lock withspin_trylock_irqsave in panic path

[Luck, Tony]

> Personally, I am not sure we want to abort here at the pstore layer, it
> should probably be aborted lower.  There isn't any reason why we can't
> continue from a pstore perspective (we can just bust the spinlock).

But do we really have much chance at getting a real dump in this case?
The pstore buf_lock is protecting the memory that the backend uses to
save the data. If we can't get the lock, then we are going to conflict
using that buffer with whoever does have the lock. So we will probably
mess up whatever data they were trying to save, as well as not managing
to save our panic data. So this isn't just a back-end issue, it is
fundamental to the pstore layer (since it depends on this back end buffer).

This is a tough call - but I'm leaning a bit towards taking this patch.

I agree with your suggestion that we need a better comment by the "return"
(and also in the change log) saying why we are not saving the panic dmesg.

-Tony 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/