linux-kernel - Re: [PATCH 04/16] printk: implement support for extended console drivers

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: <20150421100300.GC4589@pathway.suse.cz>
Date:	Tue, 21 Apr 2015 12:03:00 +0200
From:	Petr Mladek <pmladek@...e.cz>
To:	Tejun Heo <tj@...nel.org>
Cc:	akpm@...ux-foundation.org, davem@...emloft.net,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	Kay Sievers <kay@...y.org>
Subject: Re: [PATCH 04/16] printk: implement support for extended console
 drivers

On Mon 2015-04-20 17:43:07, Petr Mladek wrote:
> On Thu 2015-04-16 19:03:41, Tejun Heo wrote:
> > printk log_buf keeps various metadata for each message including its
> > sequence number and timestamp.  The metadata is currently available
> > only through /dev/kmsg and stripped out before passed onto console
> > drivers.  We want this metadata to be available to console drivers
> > too.  Immediately, it's to implement reliable netconsole but may be
> > useful for other console devices too.
> > 
> > This patch implements support for extended console drivers.  Consoles
> > can indicate that they process extended messages by setting the new
> > CON_EXTENDED flag and they'll fed messages formatted the same way as
> > /dev/kmsg output as follows.
> > 
> >  <level>,<sequnum>,<timestamp>,<contflag>;<message text>
> > 
> > One special case is fragments.  Message fragments are output
> > immediately to consoles to avoid losing them in case of crashes.  For
> > normal consoles, this is handled by later suppressing the assembled
> > result and /dev/kmsg only shows fully assembled message; however,
> > extended consoles would need both the fragments, to avoid losing
> > message in case of a crash, and the assembled result, to tell how the
> > fragments are assembled and which sequence number got assigned to it.
> > 
> > To help matching up the fragments with the resulting message,
> > fragments are emitted in the following format.
> > 
> >  <level>,-,<timestamp>,-,fragid=<fragid>;<message fragment>
> > 
> > And later when the assembly is complete, the following is transmitted,
> > 
> >  <level>,<sequnum>,<timestamp>,<contflag>,fragid=<fragid>;<message text>
> > 
> > * Extended message formatting for console drivers is enabled iff there

[...]

> Sigh, it adds another twist into the already complex printk code.
> 
> Another solution would be to allow to disable the continuous buffer
> via some boot option or /sys/kernel/debug entry if you want to debug
> such a problem and have problem with the partial flushing.
> 
> Hmm, I wonder what are the typical values passed via "dict" and if we
> need to handle this entry such a special way. It would make sense to
> always print dict values to the ext consoles and handle this as a
> yet another "normal" dict value. It would allow us to remove
> some hacks at least.

Another solution would be to always flush cont buffer when it is being
printed to the console. Then the messages might by distinguished by
the seqnum and fragid won't be needed. The question is if the cont
buffer will still have any affect after this change.

Best Regards,
Petr
--
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/