linux-kernel - Re: [PATCH v2 0/6] 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]

Message-ID: <1405612760.12363.14.camel@joe-AO725>
Date:	Thu, 17 Jul 2014 08:59:20 -0700
From:	Joe Perches <joe@...ches.com>
To:	Alex Elder <elder@...aro.org>, Kay Sievers <kay@...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 v2 0/6] printk: start simplifying some flags

Again adding Kay Sievers.

Kay wrote almost all of this originally and should
be able to review it.

Alex, if this series is resubmitted, do please cc Kay.

It does seem reasonable to me, thanks for doing it.

On Thu, 2014-07-17 at 09:09 -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 changes how two global variables are initialized,
> allowing the second patch to assume they always hold certain values.
> 
> The second patch simplifies some code based on the observation that
> the LOG_CONT and LOG_NEWLINE flags are mutually exclusive.
> 
> The third and fourth patch fix a bug in two places.  The bug is
> that a LOG_PREFIX in a record should implicitly terminate its
> predecessor, even if the predecessor was marked LOG_CONT.
> 
> The fifth patch inserts a newline in /dev/kmsg output in the
> event a LOG_PREFIX record follows a LOG_CONT record.
> 
> One trivial final patch is included at the end of the series.
> 
> 					-Alex
> 
> History:
> v2: - Added a patch to initialize two globals with LOG_NEWLINE.
>     - Changed the (now) second patch to argue that LOG_CONT and
>       LOG_NEWLINES are mutally exclusive.
>     - Added a patch to insert a newline in one case in devkmsg_read().
>     - Added some extra parentheses in some conditions, as requested.
>     - Fixed and updated some header commentary.
>     - Deleted a hunk in the typo patch, as requested.
> 
> This series, based on v3.16-rc5, is available here:
>     http://git.linaro.org/landing-teams/working/broadcom/kernel.git
>     Branch review/printk-flags-v2
> 
> Alex Elder (6):
>   printk: initialize syslog_prev and console_prev
>   printk: LOG_CONT and LOG_NEWLINE are opposites
>   printk: honor LOG_PREFIX in devkmsg_read()
>   printk: honor LOG_PREFIX in msg_print_text()
>   printk: insert newline in devkmsg_read()
>   printk: correct some more typos
> 
>  kernel/printk/printk.c | 63 +++++++++++++++++++++++++++-----------------------
>  1 file changed, 34 insertions(+), 29 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/