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-next>] [day] [month] [year] [list]
Message-Id: <20200819232632.13418-1-john.ogness@linutronix.de>
Date:   Thu, 20 Aug 2020 01:32:27 +0206
From:   John Ogness <john.ogness@...utronix.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        linux-kernel@...r.kernel.org
Subject: [RFC PATCH 0/5] printk: new log_cont implementation

Hello,

My recent series [0] to perform log_cont handling by the readers
was not received well, mainly because of the blank lines in the
output for existing dmesg and journalctl tools. This caused a
discussion about alternative methods of handling log_cont. This
RFC series is the result of that discussion.

Rather than storing individual log_cont parts into the ringbuffer,
this series will buffer the parts until flushed or the message is
complete (just as mainline does it now). The difference to mainline
is that a new API is used that allows the printk subsystem to
effectively track the caller while making use of separate
per-caller buffers.

The API is designed such that:

1. The API calls map clearly to the mainline log_cont calls. This
   is important because all current log_cont users will need to
   be updated.

2. The underlying implementation can be changed/improved at some
   later time without requiring the code of log_cont users to
   change (again).

The mainline log_cont syntax:

    printk(KERN_INFO "text");
    printk(KERN_CONT " continued");
    printk(KERN_CONT "\n");

The new RFC log_cont syntax:

    pr_cont_t c;

    pr_cont_begin(&c, KERN_INFO "text");
    pr_cont_append(&c, " continued");
    pr_cont_end(&c);

Note that both methods can co-exist until all users of the old
mechanism have been converted over.

For this RFC series, 10KiB of memory are set aside to allow up to 10
simultaneous log_cont users. Obviously that might be adjusted based
on the number of CPUs or whatever.

The first patch implements the new log_cont mechanism. The following
4 patches convert existing log_cont user code, with each patch
taking on a more complex example.

This RFC series not only improves log_cont output generally, but
also addresses the lockless printk issue related to log_cont.

John Ogness

[0] https://lkml.kernel.org/r/20200717234818.8622-1-john.ogness@linutronix.de

John Ogness (5):
  printk: implement pr_cont_t
  sysrq: use pr_cont_t for cont messages
  workqueue: use pr_cont_t for cont messages
  locking/selftest: use pr_cont_t for cont messages
  lockdep: use pr_cont_t for cont messages

 based on next-20200819

 drivers/tty/sysrq.c      |   8 +-
 include/linux/printk.h   |  19 ++
 kernel/locking/lockdep.c | 463 +++++++++++++++++++++++----------------
 kernel/printk/printk.c   | 137 ++++++++++++
 kernel/workqueue.c       |  71 +++---
 lib/locking-selftest.c   |  85 +++----
 6 files changed, 519 insertions(+), 264 deletions(-)

-- 
2.20.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ