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]

Message-ID: <1333463572.26079.31.camel@joe2Laptop>
Date:	Tue, 03 Apr 2012 07:32:52 -0700
From:	Joe Perches <joe@...ches.com>
To:	Kay Sievers <kay@...y.org>
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, 2012-04-03 at 12:30 +0200, Kay Sievers wrote:
> On Tue, Apr 3, 2012 at 05:47, Joe Perches <joe@...ches.com> wrote:
> > I think you should do it "right" rather than add
> > trivial markers.
> 
> The trivial markers _are_ correct. And they really fix things as soon
> as we start storing machine-readable records with printk(), instead of
> blindly glueing bytes together with each printk() call, for humans to
> puzzle with them if things go wrong.

These KERN_CONT changes don't _fix_ things,
they just make it less likely to cause problems.

Imagine two threads with printks extended with
KERN_CONT

Thread 1:                                 Thread 2:
printk(KERN_INFO "info message: ");
                                          printk(KERN_ERR "err message: ");
printk(KERN_CONT "online\n");
                                          printk(KERN_CONT "offline\n");

Instead of a guarantee of "info message: online" and
"err message: offline", buffering could still join
the messages to "err message: online".

I believe the only _guaranteed_ way to correctly
assemble these messages is to use a initiator with
a cookie and pass that cookie to assembling printks.

Something like:

	cookie = multi_printk_start()
	multi_printk(cookie, level fmt, ...);
	...
	multi_printk_end(cookie);

Though get_current() might be a reasonable cookie
so perhaps the multi_ variants aren't needed.

git.kernel.org isn't responding right now.  I
can't read the link you sent me privately to
check if you are using get_current() or some
other current_thread_info() constuct.

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