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: <YFiZuXWYmxPIaQH9@hovoldconsulting.com>
Date:   Mon, 22 Mar 2021 14:20:57 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
        Sam Nobs <samuel.nobs@...tradio.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] serial: imx: drop workaround for forced irq threading

On Mon, Mar 22, 2021 at 12:55:36PM +0100, Uwe Kleine-König wrote:
> Hallo Sebastian,
> 
> On Mon, Mar 22, 2021 at 12:39:18PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2021-03-22 12:34:02 [+0100], Uwe Kleine-König wrote:
> > > On Mon, Mar 22, 2021 at 12:10:36PM +0100, Johan Hovold wrote:
> > > > Force-threaded interrupt handlers used to run with interrupts enabled,
> > > > something which could lead to deadlocks in case a threaded handler
> > > > shared a lock with code running in hard interrupt context (e.g. timer
> > > > callbacks) and did not explicitly disable interrupts.
> > > > 
> > > > This was specifically the case for serial drivers that take the port
> > > > lock in their console write path as printk can be called from hard
> > > > interrupt context also with forced threading ("threadirqs").
> > > > 
> > > > Since commit 81e2073c175b ("genirq: Disable interrupts for force
> > > > threaded handlers") interrupt handlers always run with interrupts
> > > > disabled on non-RT so that drivers no longer need to do handle this.
> > > 
> > > So we're breaking RT knowingly here? If this is the case I'm not happy
> > > with your change. (And if RT is not affected a different wording would
> > > be good.)
> > 
> > Which wording, could you be more specific? It looks good from here and
> > no, RT is not affected.
> 
> The commit log says essentially: "The change is fine on non-RT" which
> suggests there is a problem on RT.

I don't think you can read that into the commit message. Why would I
knowingly break RT? And why would RT depend on patching individual
serial drivers in the first place?

That interrupt handlers run with interrupts enabled in RT is kind of
given. The unfortunate (buggy) bit was that they weren't always disabled
for non-RT.

Johan

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ