linux-kernel - Re: [RFC] New kernel-message logging API

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: <1190625742.12666.30.camel@localhost.localdomain>
Date:	Mon, 24 Sep 2007 11:22:22 +0200
From:	Michael Holzheu <holzheu@...ux.vnet.ibm.com>
To:	Vegard Nossum <vegard.nossum@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>, Joe Perches <joe@...ches.com>,
	Rob Landley <rob@...dley.net>,
	Dick Streefland <dick.streefland@...ium.nl>
Subject: Re: [RFC] New kernel-message logging API

Hi Vegard,

On Sat, 2007-09-22 at 21:27 +0200, Vegard Nossum wrote:
> After recent discussions on LKML and a general dissatisfaction at the
> current printk() kernel-message logging interface, I've decided to
> write down some of the ideas for a better system.

Good luck :-)

[snip]

> Example: {
> 	struct kprint_buffer buf;
> 
> 	kprint_buffer_init(&buf, KPRINT_DEBUG);
> 	kprint_buffer(&buf, "Stack trace:");
> 
> 	while(unwind_stack()) {
> 		kprint_buffer(&buf, "%p %s", address, symbol);
> 	}
> 
> 	kprint_buffer_flush(&buf);
> }
> 

Together with the idea of not allowing multiple lines in the kprint_xxx
functions, that would go with our approach having message numbers to
identify a message. Multiple lines are combined explicitly to one
message. I think it is a good idea to be able to identify, which lines
of a message belong together.

[snip]

> With such a modular interface, message attributes (for example the
> current time) and arguments can be recorded separately from the actual
> format string, instead of written formatted to a ring buffer as a
> sequence of characters. Parameters would be formatted to their own
> strings (regardless of the original type) and saved in an array.
> 
> Example: {
> 	struct kprint_message {
> 		const char *format;
> 
> 		unsigned int argc;
> 		char **argv;
> 
> 	#ifdef KPRINT_TIMESTAMP
> 		unsigned long long timestamp;
> 	#endif
> 
> 	#ifndef KPRINT_LOCATION
> 		const char *file;
> 		unsigned int line;
> 
> 		const char *function;
> 	#endif
> 	};
> }

[snip]

> The message entry and a message's arguments are kept separately. Most
> likely, there will be a huge number of tiny allocations. I am not sure
> how well this is handled in the kernel. Or we could try to merge the
> allocation of the struct kprint_message and its arguments into a
> single allocation by looking at the arguments before they're
> formatted. After all, the arguments cannot exist without the message
> or vice versa. Alternatively, a statically-sized ring buffer of struct
> kprint_message objects could be used, and then only arguments would
> need to be allocated dynamically. Either way, I think it should be
> possible to come up with a fairly memory-efficient system even for
> this method of storing the kernel log.

Would be nice to have some code here. How do you want to implement that?
You have to allocate / preallocate memory for the argv array. Something
like:

kprint_err(const char* fmt, ...)
{
	va_list   ap;
	struct kprint_message *msg;

	msg = &message_arry[current];
	
	va_start(ap, fmt);
	msg->argv = kmalloc(sizeof(long) * argc, GFP_KERNEL);
	...
	for (i = 0; i < argc, i++) {
		msg->argv[i] = va_arg(ap, long);
	}

If you do it like that, you can't support "%s", since then you would
store only the pointer and not the whole string. I think, that we can't
live without %s.

Michael

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