linux-kernel - Re: [PATCH] printk(): add KERN

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] [day] [month] [year] [list]

Date:	Mon, 09 Apr 2012 16:37:46 -0700
From:	Joe Perches <joe@...ches.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Kay Sievers <kay@...y.org>, linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Len Brown <lenb@...nel.org>
Subject: Re: [PATCH] printk(): add KERN_CONT where needed

On Mon, 2012-04-09 at 16:08 -0700, Andrew Morton wrote:
> On Tue, 3 Apr 2012 05:00:10 +0200
> Kay Sievers <kay@...y.org> wrote:
> 
> > > Maybe it'd be better to aggregate content rather like
> > > printk does. __Aggregate until you get a newline or a
> > > new KERN_<LEVEL>
> > 
> > The continuation printk() can can always go wrong when multiple
> > threads do that in parallel. We can try to make it better with a
> > per-cpu buffer, but I guess there will always be a situation where
> > this can happen.
> 
> Maybe we can be a bit smarter.  For example, if `current' is unchanged
> and __builtin_return_address(0) is unchanged, keep on buffering.

There are dozens to hundreds of existing sequences
like:

void some_func(...)
{
	printk("some additional data");
}

...

void some_device_init(...)
{
	...
	printk([KERN_LEVEL or not] "some initiator")
	some_func();
	printk("\n");
}

> It's all a bit hacky, but weeding out all those thousands of printks
> which never get printed anyway doesn't sound much fun either.

Nope.  That isn't any fun.

So given the example above, maybe check if the
initial printk's __builtin_return_address(0) exists
in some level of the stack say up to 3 deep for each
subsequent printk.

I don't remember any threads spun off to emit printk
continuation lines so maybe that'd work reasonably
well.

> All a bit of a pain.

Too true.


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