[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