[PATCH v7 5/5]: mtdoops: refactor as a kmsg_dumper

[David Woodhouse]

Hmmm.

On Thu, 2009-10-15 at 09:48 +0200, Simon Kagstrom wrote:
> +	/* Panics must be written immediately */
> +	if (reason == kmsg_dump_panic) {
> +		if (!cxt->mtd->panic_write)
> +			printk(KERN_ERR "mtdoops: Cannot write from panic without panic_write\n");
> +		else
> +			mtdoops_write(cxt, 1);
> +		return;
> +	}
> +

...replaces...

> -	if (mtd->panic_write && (in_interrupt() || panic_on_oops))
> -		/* Interrupt context, we're going to panic so try and log */
> -		mtdoops_write(cxt, 1);
> -	else
> -		schedule_work(&cxt->work_write);
> -}

So in the case where the device driver doesn't provide a ->panic_oops()
function, we now don't even bother with a best-effort attempt to dump;
we just give up.

Would there be any harm in scheduling the work_write function _anyway_,
just in case it manages to run?

The bug report at http://bugzilla.kernel.org/show_bug.cgi?id=14102 seems
to be suggesting that sometimes it _did_ manage to work, with a bit of
luck and a following wind.

Also, it looks like in the (in_interrupt() || panic_on_oops) case we end
up calling kmsg_dump(KMSG_DUMP_OOPS) from oops_exit(), almost
immediately followed by kmsg_dump(KMSG_DUMP_PANIC). Is that going to do
the right thing?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation