Re: [RFC][PATCH v3 2/3] Skip spin_locks in panic case and addWARN_ON()

[Don Zickus]

On Mon, Dec 12, 2011 at 10:48:52AM -0800, Luck, Tony wrote:
> > if (reason == KMSG_DUMP_PANIC) {
> > 	if(is_spin_locked(&psinfo->buf_lock))
> > 		pr_err("lock is taken.\n");
> > else {
> > 	spin_lock_irqsave(&psinfo->buf_lock, flags);
> > }
> >
> > However, this won't work for this reason.
> >  - printk() must not be called in serialized path because deadlock of logbuf_lock may cause.
> 
> There is also the issue that kmsg has already computed the addresses
> of useful pieces in __log_buf at this point - so any printk() we
> add here is not going to be saved into pstore.  So a user relying
> on pstore to see what happened, won't see any messages we add here.

Ah.  Good point.

Now we have a scenario (though rare), where kmsg_dump can fail to save a
dump because some one already has the lock.  Hitachi's whole goal behind
kmsg_dump is to record every possible reason for rebooting the machine for
inspection on reboot, I think if I understood Seiji privately.

Seiji, has does this failure impact kmsg_dump's goal?

Cheers,
Don
--
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/