linux-kernel - Re: early_printk accessing __log

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Jul 2007 09:14:34 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Mike Frysinger <vapier.adi@...il.com>
Cc:	Robin Getz <rgetz@...ckfin.uclinux.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Greg Ungerer <gerg@...pgear.com>,
	Russell King <rmk@....linux.org.uk>,
	Tim Bird <tim.bird@...sony.com>, bryan.wu@...log.com
Subject: Re: early_printk accessing __log_buf

On Sun, Jul 22, 2007 at 07:50:47PM -0400, Mike Frysinger wrote:
> On 7/18/07, Robin Getz <rgetz@...ckfin.uclinux.org> wrote:
> >On Wed 18 Jul 2007 20:26, Andrew Morton pondered:
> >> Robin Getz wrote:
> >> > [need to access _log_buf from external for early debugging code]
> >> >
> >> > Something simple like - early_copy_log_buff(void *dest, size_t n)
> >> >
> >> > copies n bytes from log_buf to memory area dest. Returns number of
> >> > bytes that could not be copied. Can find out how many bytes are in
> >> > the log_buff by calling with zero size.
> >>
> >> When I was at $EARLIER_EMPLOYER, we had code in there to copy the last
> >> kilobyte-odd of the log buffer into flash when the box oopsed.
> >>
> >
> >Hmm - I think that if you call with NULL dest, and have it advance the
> >pointer, you could do the same thing with something like:
> >
> > /* see how many bytes are in the buff */
> > length = early_copy_log_buff(NULL, NULL);
> > /* advance the pointer, so we only copy the last 1k */
> > if (length >= 1024 )
> >    left = early_copy_log_buff(NULL, length - 1024);
> > /* copy to temp buffer, to save to flash */
> > early_copy_log_buff(buff, 1024);
> > save_buff_to_flash(buff);
> >
> >That way - you can put this in the standard places for failure, and still 
> >have
> >only one function polluting printk.c (Although if you want to use it for
> >failure trapping - it's up for "normal" run time use, and doesn't go into
> >__init.
> >
> >> Probably there are others, but they'll mainly be in the consumer/embedded
> >>  area, and those sorts of engineers don't read this mailing list much.
> >
> >Adding a few more 'embedded' folks - who might have some thoughts/opinions.
> 
> i think the attached two functions account for what Robin and Andrew
> were thinking ...

I don't have any strong opinions on this one way or the other. We've been
playing more with kexec for a recovery mode, that coupled with the crash
dumps gives us most of the state we need. We would probably make use of
this printk log access functionality if it were added, though, depending
on customer environments.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/