[PATCH/RFC v5 4/5]: core: Add dump device to call on oopses and panics

Simon Kagstrom simon.kagstrom at netinsight.net
Mon Nov 30 07:03:59 EST 2009


On Mon, 30 Nov 2009 11:56:42 +0000
David Woodhouse <dwmw2 at infradead.org> wrote:

> On Mon, 2009-11-30 at 12:37 +0100, Simon Kagstrom wrote:
> > I'm a bit worried about taking the lock here - can't we end up with a
> > deadlock if we happen to crash in the wrong place? 
> 
> Um, yes -- just as the existing version can end up with a deadlock if we
> happen to crash while adding or removing a dumper and holding _that_
> lock. Try calling kmsg_dump_unregister(NULL), or putting a dumper in a
> module and then unloading that module without deregistering it, etc.

Well, actually we've thought of that:

	if (!spin_trylock_irqsave(&dump_list_lock, flags)) {
		printk(KERN_ERR "dump_kmsg: dump list lock is held during %s, skipping dump\n",
				kmsg_to_str(reason));
		return;
	}
	list_for_each_entry(dumper, &dump_list, list)
		dumper->dump(dumper, reason, s1, l1, s2, l2);
	spin_unlock_irqrestore(&dump_list_lock, flags);

Anyway, I'm happy with the explanation, so keep the lock in.

// Simon



More information about the linux-mtd mailing list