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]

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

On Mon, 23 Jul 2007 14:19:12 -0400
Robin Getz <rgetz@...ckfin.uclinux.org> wrote:

> On Sun 22 Jul 2007 19:50, Mike Frysinger pondered:
> >
> > i think the attached two functions account for what Robin and Andrew
> > were thinking ...
> 
> A note about why/when grab_lock would be set to zero (pre-kernel init, or 
> OOPs) might be nice. 

Definitely.

The pre-kernel init shouldn't be an issue: logbuf_lock is initialised at
compile time.

At oops time we could possibly use oops_in_progress to work out whether to
avoid taking the lock.  That's not terribly nice, but nor is it nice for
callers to know about printk internals.

> Or - remove it - and tell people they should be using do_syslog interface in 
> a "normal" kernel environment (where log_end or log_start can be updated).

You can't (or al least, shouldn't) use do_syslog() from within kernel code?

> Either would be fine with me. Andrew?

The interface is pretty bad, IMO:

 /*
+ * Read the log buffer into the supplied buffer.  The len option
+ * tells whether to copy from the beginning (> 0), the end (< 0), or
+ * just query the number of existing chars.   The number of bytes
+ * actually copied is returned.
+ */
+int log_buf_read(int len, char *buf, int grab_lock)

The magical interpretation of len isn't very nice.  This code would be
simpler if it did not attempt to read more than one char at a time.  It
will be plenty fast enough.

If the caller knows the length of the buffer, why is there any need for the
index-from-the-end function?

I think a sufficient implementation is

	int log_buf_len(void);

and

	int log_buf_read(int index);

which will return the character at `index', or -1 if `index' is out of
bounds.

-
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/