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] [day] [month] [year] [list]
Date:   Thu, 21 Feb 2019 20:46:31 +0000
From:   Julien Grall <Julien.Grall@....com>
To:     Roger Pau Monné <roger.pau@...rix.com>,
        Julien Grall <julien.grall@...il.com>
CC:     Andrew Cooper <Andrew.Cooper3@...rix.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Dave P Martin <Dave.Martin@....com>,
        Jan Beulich <JBeulich@...e.com>,
        Juergen Gross <jgross@...e.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        xen-devel <xen-devel@...ts.xenproject.org>,
        Marc Zyngier <Marc.Zyngier@....com>
Subject: Re: [Xen-devel] xen/evtchn and forced threaded irq

Hi Roger,

On 21/02/2019 09:14, Roger Pau Monné wrote:
> On Thu, Feb 21, 2019 at 08:38:39AM +0000, Julien Grall wrote:
>> Hi Roger,
>>
>> On Thu, 21 Feb 2019, 08:08 Roger Pau Monné, <roger.pau@...rix.com> wrote:
>>
>>> FWIW, you can also mask the interrupt while waiting for the thread to
>>> execute the interrupt handler. Ie:
>>>
>>
>> Thank you for providing steps, however where would the masking be done? By
>> the irqchip or a custom solution?
>
> I'm not familiar with the irqchip infrastructure in Linux, what I
> proposed below is what FreeBSD does when running interrupt handlers in
> deferred threads IIRC.
>
> If irqchip has a specific handler to dispatch to a thread, then that's
> the place where the masking should happen. Likely, the unmasking
> should be done by the irq handling infrastructure after the thread
> executing the interrupt handler has finished.
>
> Isn't there a similar way to handle interrupts in threads for Linux?

Linux has a flag (IRQF_ONESHOT) to mask interrupt until the interrupt
handler has been run. It is set for all interrupts handler that have
been forced to be threaded.

However, it looks like the flag is been ignored by the irqchip handler
we use (handle_edge_irq). Doing a bit of digging, IRQF_ONESHOT use to be
handled in handle_edge_irq until the following commit from 2009:

commit 4dbc9ca219b0f294332e734528f7b82211700170
Author: Thomas Gleixner <tglx@...utronix.de>
Date:   Thu Aug 27 09:38:49 2009 +0200

     genirq: Do not mask oneshot edge type interrupts

     Masking oneshot edge type interrupts is wrong as we might lose an
     interrupt which is issued when the threaded handler is handling the
     device. We can keep the irq unmasked safely as with edge type
     interrupts there is no danger of interrupt floods. If the threaded
     handler has not yet finished then IRQTF_RUNTHREAD is set which will
     keep the handler thread active.

     Debugged and verified in preempt-rt.

     Signed-off-by: Thomas Gleixner <tglx@...utronix.de>

Furthermore, it is pretty clear from the comment on top of
handle_edge_irq that the same interrupt can come-up before the first one
is one is handled by the associated event handler.

I am still trying to figure out whether the issue lies in the evtchn
driver or the Xen irqchip (events_base.c). I will have a closer look and
come back with updates here.

Cheers,

--
Julien Grall
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ