linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Keith Owens <kaos@sgi.com>
To: Linas Vepstas <linas@austin.ibm.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, torvalds@osdl.org
Subject: Re: [PATCH] kernel/printk.c lockless access
Date: Sat, 08 Jan 2005 13:37:44 +1100	[thread overview]
Message-ID: <7552.1105151864@ocs3.ocs.com.au> (raw)
In-Reply-To: Your message of "Thu, 06 Jan 2005 13:58:12 MDT." <20050106195812.GL22274@austin.ibm.com>

On Thu, 6 Jan 2005 13:58:12 -0600, 
Linas Vepstas <linas@austin.ibm.com> wrote:
>===== kernel/printk.c 1.47 vs edited =====
>--- 1.47/kernel/printk.c	2004-11-19 01:03:10 -06:00
>+++ edited/kernel/printk.c	2005-01-06 13:44:36 -06:00
>@@ -380,6 +380,23 @@ asmlinkage long sys_syslog(int type, cha
> 	return do_syslog(type, buf, len);
> }
> 
>+#ifdef   CONFIG_DEBUG_KERNEL
>+/**
>+ * Its very handy to be able to view the syslog buffer during debug.
>+ * But do_syslog() uses locks and so it will deadlock if called during 
>+ * a debugging session. The routine provides the start and end of the 
>+ * physical and logical logs, and is equivalent to do_syslog(3).
>+ */
>+
>+void debugger_syslog_data(char *syslog_data[4])
>+{
>+	syslog_data[0] = log_buf;
>+	syslog_data[1] = log_buf + __LOG_BUF_LEN;
>+	syslog_data[2] = log_buf + log_end - (logged_chars < __LOG_BUF_LEN ? logged_chars : __LOG_BUF_LEN);
>+	syslog_data[3] = log_buf + log_end;
>+}
>+#endif   /* CONFIG_DEBUG_KERNEL */
>+

Replace __LOG_BUF_LEN with log_buf_len.  __LOG_BUF_LEN is the default
size, log_buf_len is the actual size used, including boot time
overrides with log_buf_len=.

On Thu, 06 Jan 2005 21:50:17 +0100,
Andi Kleen <ak@muc.de> wrote:

AK>Better&simpler fix would be to just unstatic __log_buf

The debug caller needs to know where the ring pointers are as well.
Also __log_buf is not necessarily the current log buffer, boot with
log_buf_len= and you get a different buffer.  The caller needs the 

On Thu, 6 Jan 2005 16:12:41 -0800,
Andrew Morton <akpm@osdl.org> wrote:

AKPM>We faced the same problem in the Digeo kernel.  When the kernel oopses we
AKPM>want to grab the last kilobyte or so of the printk buffer and stash it into
AKPM>nvram.  We did this via a function which copies the data rather than
AKPM>exporting all those variables, which I think is a nicer and more
AKPM>maintainable approach:

That assumes that you have enough free space to copy the log buffer to.
In the general debugging case that is not true, especially if you want
the entire print buffer to be printed.  The only safe way to access the
complete print buffer is in situ.  Which is what the patch above does.


      parent reply	other threads:[~2005-01-08  2:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-06 19:58 [PATCH] kernel/printk.c lockless access Linas Vepstas
2005-01-06 20:50 ` Andi Kleen
2005-01-07  0:12 ` Andrew Morton
2005-01-07  0:26   ` Anton Blanchard
2005-01-07  0:25     ` Randy.Dunlap
2005-01-07  1:54       ` Alan Cox
2005-01-09 10:44         ` Frank van Maarseveen
2005-01-09 22:31           ` David Wagner
2005-01-09 23:00           ` Alan Cox
2005-01-10 20:43             ` Matt Mackall
2005-01-08  2:37 ` Keith Owens [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7552.1105151864@ocs3.ocs.com.au \
    --to=kaos@sgi.com \
    --cc=akpm@osdl.org \
    --cc=linas@austin.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).