linux-kernel - Re: [RFC PATCH v5 0/3] printk: new ringbuffer implementation

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: <20191206141653.1199-1-prarit@redhat.com>
Date:   Fri,  6 Dec 2019 09:16:53 -0500
From:   Prarit Bhargava <prarit@...hat.com>
To:     prarit@...hat.com
Cc:     andrea.parri@...rulasolutions.com, brendanhiggins@...gle.com,
        gregkh@...uxfoundation.org, john.ogness@...utronix.de,
        kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
        peterz@...radead.org, pmladek@...e.com, rostedt@...dmis.org,
        sergey.senozhatsky@...il.com, sergey.senozhatsky.work@...il.com,
        tglx@...utronix.de, torvalds@...ux-foundation.org
Subject: Re: [RFC PATCH v5 0/3] printk: new ringbuffer implementation

  John Ogness <john.ogness@...utronix.de> wrote:
> Hi Prarit,
> 
> On 2019-12-05, Prarit Bhargava <prarit@...hat.com> wrote:
> > Based on the comments there is going to be a v6 but in any case I am
> > starting testing of this patchset on several large core systems across
> > multiple architectures (x86_64, ARM64, s390, ppc64le).  Some of those
> > systems are known to fail boot due to the large amount of printk output so
> > it will be good to see if these changes resolve those issues.
> 
> Right now the patches only include the ringbuffer as a separate entity
> with a test module. So they do not yet have any effect on printk.
> 
> If you apply the patches and then build the "modules" target, you will
> have a new test_prb.ko module. Loading that module will start some heavy
> testing of the ringbuffer. As long as the testing is successful, the
> module will keep testing. During this time the machine will be very
> slow, but should still respond.
> 
> The test can be stopped by unloading the module. If the test stops on
> its own, then a problem was found. The output of the test is put into
> the ftrace buffer.
> 
> It would be nice if you could run the test module on some fat machines,
> at least for a few minutes to see if anything explodes. ARM64 and
> ppc64le will probably be the most interesting, due to memory barrier
> testing.
> 

I've run the module overnight on all 4 arches I mentioned above.  I didn't
see any failures but IIUC the module test runs at max.  I'm going to put a
load test on these systems that introduces a variable load to interfere
with the prbtest module to see if that kicks anything.

> Otherwise I will definitely be reaching out to you when we are ready to
> perform actual printk testing with the newly agreed up semantics
> (lockless, per-console printing threads, synchronous panic
> consoles). Thanks for your help with this.
>

np :) but I should be the one thanking you ;)

P.

> John Ogness