linux-kernel - Re: [RFC V2] printk: add warning while drop partial text in msg

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: <CAOVJa8EGdM6ezt25BNN6=+6_wnWD3QyN8uhBewPhJ5i8chyAOA@mail.gmail.com>
Date:   Wed, 18 Oct 2017 01:10:08 +0800
From:   pierre kuo <vichy.kuo@...il.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        rostedt@...dmis.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC V2] printk: add warning while drop partial text in msg

hi Petr and Sergey:
> I wonder what is the motivation for the extra buffering. Did you
> have troubles with direct printk() calls? For example, because
> of performance, mixed messages, deadlocks?

Yes, when using direct printk() calls, we suffer performance and mix
message issues.
(Since originally we try to collect the status of hardware and driver
at different places,
then use a work queue periodically for printk() the results of above
collections or
also do some simple analysis and calculation before printk().)

>
> Note that any buffering is potentially dangerous. You might miss
> the messages if the system dies before they are flushed. Also
> you might lose messages if the buffer is too small.
> You might go around this by flushing the buffer line by line.

Yes, you are right.
Except flushing the buffer line by line, we try to shrink the buffer size
to the number that plus prefix words will not over the size of
textbuf[], say 992 Bytes.
(that mean "size of buffer + 18*(number of "\n") < 992 Bytes")


> Well, it might get quite complicated, see printk_safe_flush_buffer().

BTW,  after checking printk_safe_flush_buffer() and related functions,
we have one question:
a) Why in printk_safe_log_store(), we need to use  atomic_xxxx operation in it?
    printk_safe_log_store() will be called in either one of below case
    i) PRINTK_NMI_CONTEXT_MASK
    ii) PRINTK_SAFE_CONTEXT_MASK
    and each of them will bring each CPU's own nmi_print_seq or
safe_print_seq separately.
    why it still need atomic_xxx operations like below *** show?

kernel/printk/printk_safe.c
-->static __printf(2, 0) int printk_safe_log_store(struct
printk_safe_seq_buf *s,
                                                const char *fmt, va_list args)
{
        int add;
        size_t len;
again:
        len = atomic_read(&s->len);          **************************


> Another question is if the buffering makes sense then.
We explained our initial thought above.

Appreciate you and Sergey's great comment and help,