: core: Add dump device to call on oopses and panics
in [Kernel]
|
From: Artem Bityutskiy on 30 Nov 2009 02:30 On Thu, 2009-11-26 at 10:36 +0100, Jörn Engel wrote: > 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 me it looks like 'log_end' is not supposed to wrap. What makes you think it can? In which cases it can? -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Artem Bityutskiy on 30 Nov 2009 04:00 On Mon, 2009-11-30 at 08:46 +0100, Jörn Engel wrote: > On Mon, 30 November 2009 09:27:51 +0200, Artem Bityutskiy wrote: > > > > To me it looks like 'log_end' is not supposed to wrap. What makes you > > think it can? In which cases it can? > > It is a 32bit variable. Would do you expect happens once you reach > 0xffffffff and add 1? Yes, now I see log_end is an ever increasing variable. How about this patch on top of the existing one (untested): diff --git a/kernel/printk.c b/kernel/printk.c index f711b99..66995ca 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -1486,28 +1486,27 @@ static const char *kmsg_to_str(enum kmsg_dump_reason reason) */ void kmsg_dump(enum kmsg_dump_reason reason) { - unsigned long len = ACCESS_ONCE(log_end); + unsigned long end = ACCESS_ONCE(log_end) & LOG_BUF_MASK; struct kmsg_dumper *dumper; const char *s1, *s2; unsigned long l1, l2; unsigned long flags; - s1 = ""; - l1 = 0; - s2 = log_buf; - l2 = len; - - /* Have we rotated around the circular buffer? */ - if (len > log_buf_len) { - unsigned long pos = len & LOG_BUF_MASK; - - s1 = log_buf + pos; - l1 = log_buf_len - pos; - - s2 = log_buf; - l2 = pos; + /* + * Have we ever rotated around the circular buffer? If we never did, + * we have to have zeroes at the end. + */ + if (log_buf[end]) { + s1 = log_buf + end; + l1 = log_buf_len - end; + } else { + s1 = ""; + l1 = 0; } + s2 = log_buf; + l2 = end; + 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)); Then the whole function will look like this: /** * kmsg_dump - dump kernel log to kernel message dumpers. * @reason: the reason (oops, panic etc) for dumping * * Iterate through each of the dump devices and call the oops/panic * callbacks with the log buffer. */ void kmsg_dump(enum kmsg_dump_reason reason) { unsigned long end = ACCESS_ONCE(log_end) & LOG_BUF_MASK; struct kmsg_dumper *dumper; const char *s1, *s2; unsigned long l1, l2; unsigned long flags; /* * Have we ever rotated around the circular buffer? If we never did, * we have to have zeroes at the end. */ if (log_buf[end]) { s1 = log_buf + end; l1 = log_buf_len - end; } else { s1 = ""; l1 = 0; } s2 = log_buf; l2 = end; 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); } -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Artem Bityutskiy on 30 Nov 2009 04:20 On Thu, 2009-11-26 at 10:36 +0100, Jörn Engel wrote: > 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. Simon, if you want your patches to be merged to 2.6.33, we should address this issue ASAP, otherwise it'll be too late. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Artem Bityutskiy on 30 Nov 2009 04:50 On Mon, 2009-11-30 at 10:35 +0100, Jörn Engel wrote: > On Mon, 30 November 2009 10:51:58 +0200, Artem Bityutskiy wrote: > > > > How about this patch on top of the existing one (untested): > > > > + /* > > + * Have we ever rotated around the circular buffer? If we never did, > > + * we have to have zeroes at the end. > > + */ > > + if (log_buf[end]) { > > + s1 = log_buf + end; > > + l1 = log_buf_len - end; > > + } else { > > + s1 = ""; > > + l1 = 0; > > So now you are assuming that a) the buffer is initially zeroed and b) > noone ever writes NUL to it. Is that correct? a) seems to be true because the buffer is either a static array or a bootmem alloc, which seems to memzero the buffers it returns, at least AFAICS. But I did not test this. vs b). well, the printk ring buffer should contain ASCII, so I assumed binary zeroes should not be possible there. > I'm not sure whether those assumptions are valid. If they are, then > this will obviously work. Otherwise we can just always assume the > wrapped case. Of course someone who has more knowlege about the printk buffer should comment on this. The other alternative I was thinking about was to introduce a boolean flag, and set it to one as soon as 'lon_end' becomes larger than 'log_buf_len'. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Woodhouse on 30 Nov 2009 05:30 On Mon, 2009-11-30 at 10:51 +0200, Artem Bityutskiy wrote: > On Mon, 2009-11-30 at 08:46 +0100, Jörn Engel wrote: > > On Mon, 30 November 2009 09:27:51 +0200, Artem Bityutskiy wrote: > > > > > > To me it looks like 'log_end' is not supposed to wrap. What makes you > > > think it can? In which cases it can? > > > > It is a 32bit variable. Would do you expect happens once you reach > > 0xffffffff and add 1? > > Yes, now I see log_end is an ever increasing variable. > > How about this patch on top of the existing one (untested): I suspect you should be modelling this more closely on the code in do_syslog() for case 3. The end is at (log_end & LOG_BUF_MASK), and you have (logged_chars) to write. This mean that you won't write messages to the log which were 'cleared' by 'dmesg -c', but that's acceptable, I think. Why are you setting s1 to "" in the case where l1 is zero, btw? Can't it be NULL? diff --git a/kernel/printk.c b/kernel/printk.c index f711b99..d150c57 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -1486,26 +1486,33 @@ static const char *kmsg_to_str(enum kmsg_dump_reason reason) */ void kmsg_dump(enum kmsg_dump_reason reason) { - unsigned long len = ACCESS_ONCE(log_end); + unsigned long end; + unsigned chars; struct kmsg_dumper *dumper; const char *s1, *s2; unsigned long l1, l2; unsigned long flags; - s1 = ""; - l1 = 0; - s2 = log_buf; - l2 = len; - - /* Have we rotated around the circular buffer? */ - if (len > log_buf_len) { - unsigned long pos = len & LOG_BUF_MASK; + /* Theoretically, the log could move on after we do this, but + there's not a log we can do about that. The new messages + will overwrite the start of what we dump. */ + spin_lock_irqsave(&logbuf_lock, flags); + end = log_end & LOG_BUF_MASK; + chars = logged_chars; + spin_unlock_irqrestore(&logbuf_lock, flags); - s1 = log_buf + pos; - l1 = log_buf_len - pos; + if (logged_chars > end) { + s1 = log_buf + log_buf_len - logged_chars + end; + l1 = logged_chars - end; s2 = log_buf; - l2 = pos; + l2 = end; + } else { + s1 = ""; + l1 = 0; + + s2 = log_buf + end - logged_chars; + l2 = logged_chars; } if (!spin_trylock_irqsave(&dump_list_lock, flags)) { -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: (none) Next: Coding style correction in HDLC/Frame Relay support routines |