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]
Date:   Tue, 13 Jul 2021 12:09:35 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Vignesh Raghavendra <vigneshr@...com>
Cc:     "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        Jan Kiszka <jan.kiszka@...mens.com>,
        Tony Lindgren <tony@...mide.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
        Linux ARM Mailing List <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] serial: 8250: 8250_omap: Fix possible interrupt storm

On Tue, Jul 13, 2021 at 11:54 AM Vignesh Raghavendra <vigneshr@...com> wrote:
> On 7/13/21 1:57 AM, andy@...facebook.localdomain wrote:
> > Tue, Jun 22, 2021 at 11:53:38AM +0530, Vignesh Raghavendra kirjoitti:
> >> On 6/22/21 11:45 AM, Jan Kiszka wrote:
> >>>>> Vignesh, it seems this quirk needs some soc specific flag added to
> >>>>> it maybe? Or maybe UART_OMAP_RX_LVL register is not available for
> >>>>> all the SoCs?
> >>>>>
> >>>> Yes indeed :(
> >>>>
> >>>>> I think it's best to drop this patch until the issues are resolved,
> >>>>> also there are some open comments above that might be answered by
> >>>>> limiting this quirk to a specific range of SoCs :)
> >>>>>
> >>>> Oops, I did test patch AM33xx assuming its equivalent to OMAP3, but UART
> >>>> IP is quite different. I will respin the patch making sure, workaround
> >>>> applies only to AM65x and K3 SoCs.
> >>>>
> >>>> Regards
> >>>> Vignesh
> >>>>
> >>> What's the status here for AM65x? The issue remains present on that
> >>> platform, and I was hoping to see a quick follow up that limit the fix
> >>> to that target.
> >>
> >> Sorry for the delay, I am trying to find which other TI SoCs are
> >> affected by this issue. But that exercise will need a bit more time.
> >> Will send a fix to address K3 SoCs like AM65x today/tomo.
> >
> > This all reminds me the very similar issue one found on Intel integrated
> > (Synopsys DesignWare based) UARTs:
> >
>
> Hmm, yes, seems like common problem with some 8250 UARTs although not
> all TI SoCs show this behavior even though they all claim 8250 compatible.
>
> > https://lore.kernel.org/linux-serial/20170206233000.3021-1-dianders@chromium.org/
>
> I am not sure if reading UART_LSR is a good idea in the above patch.
> Some flags in LSR register are cleared on read (at least that's the case
> for UARTs on TI SoCs) and thus can result in loss of error/FIFO status
> information.
>
> > https://lore.kernel.org/linux-serial/1440015124-28393-1-git-send-email-california.l.sullivan@intel.com/
> >
>
> Looks like this never made it.
>
> Given the quirks associated with 8250 UARTs, workarounds would need to
> be tied to specific variants, so I don't know if its possible to
> implement the fix in 8250 core IRQ handler.

I believe they are all are derivatives from Synopsys DesignWare one or
another version of it.

> PS: v2 of $patch is already merged.

I noticed after sending that email.

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ