Re: Re: Re: [PATCH 0/2] [BUGFIX] printk: Fix message continuationbreakage involved with structured printk

From: Yoshihiro YUNOMAE
Date: Mon Dec 23 2013 - 23:54:52 EST


(2013/12/24 12:00), Kay Sievers wrote:
On Tue, Dec 24, 2013 at 3:50 AM, Yoshihiro YUNOMAE
<yoshihiro.yunomae.ez@xxxxxxxxxxx> wrote:
(2013/12/20 20:29), Kay Sievers wrote:

On Fri, Dec 20, 2013 at 10:41 AM, Yoshihiro YUNOMAE
<yoshihiro.yunomae.ez@xxxxxxxxxxx> wrote:

This patch set fixes message continuation breakage involved with
structured
printk. A SCSI driver may output two continuation error messages like
scmd_printk("foo");
printf("bar\n");


Which is the absolutely wrong thing to do. Structured logging and racy
printk continuation must never be mixed. Userspace needs to be sure
that dictionary entries are not subject to racy continuation hackery,
and that these mwssages atomic, whole and intact.


I see.
As you say, user tools need to support messages output in multiple lines
for SMP environments even if this patch set is introduced.

They cannot really, they can try to re-construct, but Information and
context is sometimes lost with the use of continuation lines.
Structured logging need to be reliable and trustable, and it it is not
"best effort", hence it cannot use continuation lines.

Continuation lines are a nice debugging tool for humans only.
Structured logging carries the human readable string but also
machine-readable context and that alwasy needs to be safely
machine-readable and recognizable.

I understand. I think if we make machine(user tools) handle important
messages, those messages need to be output in single line even if those
are not structured printk.

Please do not mix the both and do not apply these patches.

OK, I'll make important messages with KERN_CONT or no-prefix printk()
output those in single line.

Yes, it should use the plain printk versions and not the one which add
structured data.

If structured logging is really wanted for more complex continuation
lines, it might be the simplest to buffer the line locally, instead of
the single printk-owned buffer, before the line is emitted to printk.

Yes, I'll do that.

Thanks,
Yoshihiro YUNOMAE

--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae.ez@xxxxxxxxxxx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/