| 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
| ||
|
Message-ID: <53C7F40F.7040404@linaro.org> 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