[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPXgP11FbLbWs3GoHpYngAGJ+whe8PZ=5dXqR8ufdMkLT5AX0Q@mail.gmail.com>
Date: Tue, 24 Dec 2013 04:00:33 +0100
From: Kay Sievers <kay@...y.org>
To: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Eiichi Tsukata <eiichi.tsukata.xh@...achi.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Tejun Heo <tj@...nel.org>, yrl.pp-manager.tt@...achi.com,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
Joe Perches <joe@...ches.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>
Subject: Re: Re: [PATCH 0/2] [BUGFIX] printk: Fix message continuation
breakage involved with structured printk
On Tue, Dec 24, 2013 at 3:50 AM, Yoshihiro YUNOMAE
<yoshihiro.yunomae.ez@...achi.com> wrote:
> (2013/12/20 20:29), Kay Sievers wrote:
>>
>> On Fri, Dec 20, 2013 at 10:41 AM, Yoshihiro YUNOMAE
>> <yoshihiro.yunomae.ez@...achi.com> 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.
>> 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.
That way there will be no race with other print users but structured
data can still safely be added.
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/
Powered by blists - more mailing lists