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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1609222239500.5640@nanos>
Date:   Thu, 22 Sep 2016 22:47:13 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Leo Li <pku.leo@...il.com>
cc:     Marc Zyngier <marc.zyngier@....com>,
        Marc Zyngier <maz@...terjones.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: recommended use of request_any_context_irq()

On Thu, 22 Sep 2016, Leo Li wrote:
> On Thu, Sep 22, 2016 at 3:10 AM, Marc Zyngier <marc.zyngier@....com> wrote:
> > There is strictly no reason to perform a blanket change of all the
> > drivers. What would be the reason to change them other than to cater for
> > a contrived use case that may never happen?
> 
> Maybe we could do blanket change to drivers that meet certain
> criteria?  At least we should improve the messaging when a driver
> cannot request interrupt due to nested threading.

Nested threading is a result of requesting an any context interrupt not
something which is there already.

> Right now, it might take quite some time for a developer unfamiliar with
> the threaded interrupt to figure out the problem.

Did you have issues with a driver which was not able to request an
interrupt? If yes, please explain in detail what the failure was and why
you think that this should be changed. If not, please explain which problem
you are trying to solve.

Thanks,

	tglx



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ