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

Jörn Engel joern at logfs.org
Thu Nov 26 04:36:58 EST 2009


Just stumbled across this patch.

On Tue, 13 October 2009 15:22:35 +0200, Simon Kagstrom wrote:
> +void dump_kmsg(int panic)
> +{
> +	unsigned long len = ACCESS_ONCE(log_end);
> +	struct dump_device *dump;
> +	const char *s1, *s2;
> +	unsigned long l1, l2;
> +
> +	s1 = "";
> +	l1 = 0;
> +	s2 = log_buf;
> +	l2 = len;
> +
> +	/* Have we rotated around the circular buffer? */
> +	if (len > log_buf_len) {

I believe this bit is wrong.  log_end is an unsigned int, so it can
wrap relatively quickly.  If log_end just wrapped to 0 and dump_kmsg is
called, the amount of printk buffer stored appears to be 0 as well.

To avoid this case one could either declare log_end and len as u64,
causing extra computational costs.  Or one could just use the
conditional code below unconditionally.  That could write random or
zeroed printk buffer directly after bootup, but would never miss
information.

> +		unsigned long pos = (len & LOG_BUF_MASK);
> +
> +		s1 = log_buf + pos;
> +		l1 = log_buf_len - pos;
> +
> +		s2 = log_buf;
> +		l2 = pos;
> +	}
> +
> +	list_for_each_entry(dump, &dump_list, list) {
> +		if (panic && dump->panic)
> +			dump->panic(dump, s1, l1, s2, l2);
> +		else if (!panic && dump->oops)
> +			dump->oops(dump, s1, l1, s2, l2);
> +	}
> +}
> -- 
> 1.6.0.4

Jörn

-- 
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein



More information about the linux-mtd mailing list