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:	Thu, 17 Jul 2014 11:04:31 -0500
From:	Alex Elder <elder@...aro.org>
To:	Joe Perches <joe@...ches.com>, 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

On 07/17/2014 10:59 AM, Joe Perches wrote:
> 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.

Yes, sorry about that.  I meant to but forgot.  Thanks for
forwarding.

					-Alex

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ