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: <X8+KA7+sYUYPlEiU@alley>
Date:   Tue, 8 Dec 2020 15:13:23 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH next v3 0/3] printk: remove logbuf_lock protection of
 ringbuffer

On Mon 2020-12-07 23:26:17, John Ogness wrote:
> Hello,
> 
> Here is a v3 of the series to remove logbuf_lock. v2 is
> here[0]. Rather than completely removing logbuf_lock, this
> version only removes logbuf_lock usage protecting the
> ringbuffer. I have tried to keep the changes minimal so that
> we can feel comfortable for the upcoming 5.11 merge window.
> 
> Although small, this series is significant because it allows
> printk callers direct lockless access to the ringbuffer and
> it replaces the use of a temporary static sprint buffer with
> sprint'ing directly to the reserved ringbuffer data block.

Yes, it might allow to see eventual races in the ring buffer
code. It is great that we do the switch in many "small" steps.

> The other changes from v2 (recursion limiting, introduction
> of syslog_lock, using clear_seq as seqcount_latch, and full
> removal of logbuf_lock) will be included in a later series,
> which may or may not make the 5.11 merge window.

I am slightly nervous when such changes could not spend longer
time in linux-next. On the other hand, I do not want to block
it too much. The races will hopefully be hard to hit if there
are any. And it is good that there are no other big changes
waiting for 5.11.

Let's see how the patches look like in the end...

Best Regards,
Petr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ