linux-kernel - Re: [PATCH RT 1/1] remoteproc: Prevent schedule while atomic

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:   Fri, 24 Mar 2017 09:38:20 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Julia Cartwright <julia@...com>
cc:     Grygorii Strashko <grygorii.strashko@...com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Lionel Debieve <lionel.debieve@...com>,
        linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org,
        bigeasy@...utronix.de
Subject: Re: [PATCH RT 1/1] remoteproc: Prevent schedule while atomic

On Wed, 22 Mar 2017, Julia Cartwright wrote:
> On Wed, Mar 22, 2017 at 01:30:12PM -0500, Grygorii Strashko wrote:
> > It will not be threaded because there are IRQF_ONESHOT used.
> > 
> > 	ret = devm_request_threaded_irq(&pdev->dev, irq,
> > 					sti_mbox_irq_handler,
> > 					sti_mbox_thread_handler,
> > 					IRQF_ONESHOT, mdev->name, mdev);
> 
> Indeed.  I had skipped over this important detail when I was skimming
> through the code.
> 
> Thanks for clarifying!
> 
> Is IRQF_ONESHOT really necessary for this device?  The primary handler
> invokes sti_mbox_disable_channel() on the interrupting channel, which I
> would hope would acquiesce the pending interrupt at the device-level?

Well, this is a typical case of well done split into primary and threaded
handler. There is no advantage on RT to force this into double threaded
handling. Making the lock raw is definitely the proper solution here.

Thanks,

	tglx