linux-kernel - Re: [PATCH 3/3] 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: <20150430151534.97ab742f82313478c99a8775@linux-foundation.org>
Date:	Thu, 30 Apr 2015 15:15:34 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	pmladek@...e.cz, davem@...emloft.net, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, Kay Sievers <kay@...y.org>
Subject: Re: [PATCH 3/3] printk: implement support for extended console
 drivers

On Thu, 30 Apr 2015 18:12:31 -0400 Tejun Heo <tj@...nel.org> wrote:

> Hello, Andrew.
> 
> On Thu, Apr 30, 2015 at 02:31:28PM -0700, Andrew Morton wrote:
> > So if I'm understanding this correctly, the /dev/kmsg output is altered
> > (different cont handling) if some console registers with CON_EXTENDED
> > (and there are no such consoles yet, so the patch is a no-op).
> 
> Yeah, that's mostly right.  /dev/kmsg output already has
> "continuation" flag which indicates whether a message should be
> concatenated which gets triggered occassionally currently.  This would
> make use of that behavior a lot more frequently.

OK, sounds reasonable.

> > If correct, this seems undesirable - registration of a CON_EXTENDED
> > console collaterally damages the /dev/kmsg interface?  If the user has
> > an app which depends on the original /dev/kmsg format then they'll be
> > wondered what-the-heck-just-happened?
> 
> For applications which ignore the continuation flags, this would lead
> to a different output.  We can fake it for /dev/kmsg (concatenate from
> the kernel side and then output empty message for the later fragments)
> but that'd be piling more hacks on top of already unnecessary hack
> which is the cont buffer.
> 
> We can generate a log message indicating that the new mode is enabled
> to make it easier to figure out why it changed.  Given that this is
> not an entirely new behavior and the usage of extended console is
> likely to stay fairly specific, transitioning this way is unlikely to
> cause too much trouble especially given that most traditional tools
> use the older interfaces w/o metadata which aren't affected by this
> change.
> 
> What do you think?

Yes, I suppose a printk is worthwhile.  Maybe a paragraph in
Documentation/ABI/testing/dev-kmsg also.

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