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

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

On Tue, Apr 3, 2012 at 04:36, Joe Perches <joe@...ches.com> wrote:
> On Tue, 2012-04-03 at 03:18 +0200, Kay Sievers wrote:

>>   hpet0: at MMIO 0xfed00000, IRQs
>>    2
>>   , 8
>>   , 0

> You are going to find many, many _hundreds_ of these.

Yeah, and they should all be fixed over time. It's 2012 and time to
make kernel log messages readable for machines, not for humans to
puzzle them together. :)

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

I'm confident, that only callers who are willing to take that 'risk'
of interleaved messages should be exposed to the problem, and never
ones who print proper single lines.

In other words, we should guarantee that there is no garbage left from
any earlier printk() for someone who does not want to play this
continuation print() game.

> A couple of other trivial comments:
>
> It's better to try to coalesce multiple printks(KERN_CONT
> (perhaps it's better to use pr_cont instead too)
>
> Branches with the same printks should be hoisted where
> possible.

Sure, please send patches for anything that is more appropriate to use here.

I did not want to change any logic which needs to be tested. I just
trivially added the obviously missing prefix, which solved the
problem, and which could be applied right away.

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