linux-kernel - Re: [PATCH 0/4] printk: start simplifying some flags

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]

Date:	Wed, 16 Jul 2014 10:55:06 -0700
From:	Joe Perches <joe@...ches.com>
To:	Alex Elder <elder@...aro.org>, "kay.sievers" <kay.sievers@...y.org>
Cc:	akpm@...ux-foundation.org, pmladek@...e.cz, bp@...e.de,
	john.stultz@...aro.org, jack@...e.cz, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] printk: start simplifying some flags

(adding Kay Sievers)

On Wed, 2014-07-16 at 12:26 -0500, Alex Elder wrote:
> Each log record has a "flags" field.  The flags keep track of, for
> instance, whether the record was saved in its entirety (as opposed
> to being one of multiple records that should be merged as a single
> unit).  A log record's flags field alone is not currently sufficient
> to know how the record should be formatted; you need to know the
> previous record's flags field as well.  I found understanding the
> real effect of various combinations of these flags to be very
> difficult, and was moved to try to do something about that.
> 
> This series includes three patches that begin the process of
> simplifying how these flags are used and interpreted.  They include
> very long, detailed explanations (as small patches often do) because
> I want my reasoning to be very clear and examined very closely.  I
> really don't want to break printk()...
> 
> The first patch simplifies some code based on the observation that
> certain flag combinations never occur.
> 
> The second and third patch fix what I assert is a bug in two places.
> The bug is that a LOG_PREFIX in a message should implicitly
> terminate its predecessor, even if the predecessor was marked
> LOG_CONT.  I would really like to have someone else confirm
> they agree my assertion here.
> 
> One trivial extra patch is included at the end of the series.
> 
> 					-Alex
> 
> This series, based on v3.16-rc4, is available here:
>     http://git.linaro.org/landing-teams/working/broadcom/kernel.git
>     Branch review/printk-flags
> 
> Alex Elder (4):
>   printk: LOG_CONT and LOG_NEWLINE are separate
>   printk: honor LOG_PREFIX in devkmsg_read()
>   printk: honor LOG_PREFIX in msg_print_text()
>   printk: correct some more typos
> 
>  kernel/printk/printk.c | 40 ++++++++++++++++++----------------------
>  1 file changed, 18 insertions(+), 22 deletions(-)
> 



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