linux-kernel - Re: [RFC PATCH v1 00/25] printk: new 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: <20200122165855.GA3485@lxhi-065.adit-jv.com>
Date:   Wed, 22 Jan 2020 17:58:55 +0100
From:   Eugeniu Rosca <erosca@...adit-jv.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
CC:     Eugeniu Rosca <erosca@...adit-jv.com>,
        John Ogness <john.ogness@...utronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        Andrew Gabbasov <andrew_gabbasov@...tor.com>,
        Sanjeev Chugh <sanjeev_chugh@...tor.com>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Daniel Wang <wonderfly@...gle.com>,
        Dean Jenkins <dean_jenkins@...tor.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Dirk Behme <dirk.behme@...bosch.com>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Jiri Slaby <jslaby@...e.com>,
        Peter Feiner <pfeiner@...gle.com>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Eugeniu Rosca <roscaeugeniu@...il.com>
Subject: Re: [RFC PATCH v1 00/25] printk: new implementation

Hi Geert,

On Wed, Jan 22, 2020 at 08:31:44AM +0100, Geert Uytterhoeven wrote:
> On Wed, Jan 22, 2020 at 3:34 AM Eugeniu Rosca <erosca@...adit-jv.com> wrote:
> >
> > So, what's specific to R-Car3, based on my testing, is that the issue
> > can only be reproduced if the printk storm originates on CPU0 (it does
> > not matter if from interrupt or task context, both have been tested). If
> > the printk storm is initiated on any other CPU (there are 7 secondary
> > ones on R-Car H3), there is no regression in the audio quality/latency.
> 
> The secure stuff is running on CPU0, isn't it?
> Is that a coincidence?

Nobody has ruled this out so far. As a side note, except for the ARMv8
generic IPs, there seems to be quite poor IRQ balancing between the
CPU cores of R-Car H3 (although this might be unrelated to the issue):

$ cat /proc/interrupts | egrep -v "(0[ ]*){8}"
         CPU0   CPU1   CPU2    CPU3 CPU4 CPU5  CPU6  CPU7       
  3:    55879  17835  14132   33882 6626 4331  6710  4532     GICv2  30 Level     arch_timer
 16:        1      0      0       0    0    0     0     0     GICv2  38 Level     e6052000.gpio
 32:      203      0      0       0    0    0     0     0     GICv2  51 Level     e66d8000.i2c
 33:       95      0      0       0    0    0     0     0     GICv2 205 Level     e60b0000.i2c
 94:    19339      0      0       0    0    0     0     0     GICv2  71 Level     eth0:ch0:rx_be
112:    20599      0      0       0    0    0     0     0     GICv2  89 Level     eth0:ch18:tx_be
118:        2      0      0       0    0    0     0     0     GICv2  95 Level     eth0:ch24:emac
122:   442092      0      0       0    0    0     0     0     GICv2 196 Level     e6e88000.serial:mux
124:  2776685      0      0       0    0    0     0     0     GICv2 352 Level     ec700000.dma-controller:0
160:     2896      0      0       0    0    0     0     0     GICv2 197 Level     ee100000.sd
161:     5652      0      0       0    0    0     0     0     GICv2 199 Level     ee140000.sd
162:      147      0      0       0    0    0     0     0     GICv2 200 Level     ee160000.sd
197:        5      0      0       0    0    0     0     0     GICv2 384 Level     ec500000.sound
208:        1      0      0       0    0    0     0     0  gpio-rcar  11 Level     e6800000.ethernet-ffffffff:00
IPI0:   12701 366358 545059 1869017 9817 8065  9327 10644       Rescheduling interrupts
IPI1:      21     34    111      86  238  191   149   161       Function call interrupts
IPI5:   16422    709    509     637    0    0  3346     0       IRQ work interrupts

BTW/FYI, I raised a bug report to Renesas and specifically asked them
to approach you, hoping that your massive experience in the serial
drivers will help. If you arrive to any conclusions in that context,
we would be delighted to hear from you.

-- 
Best Regards
Eugeniu Rosca