All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mason <slash.tmp@free.fr>
To: Marc Zyngier <marc.zyngier@arm.com>,
	Sebastian Frias <sf84@laposte.net>,
	Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: Disabling an interrupt in the handler locks the system up
Date: Tue, 25 Oct 2016 15:56:11 +0200	[thread overview]
Message-ID: <580F647B.5000202@free.fr> (raw)
In-Reply-To: <534c4588-f220-25a3-e7aa-84484f348bd1@arm.com>

On 25/10/2016 12:45, Marc Zyngier wrote:
> On 25/10/16 09:36, Mason wrote:
>> On 25/10/2016 10:29, Sebastian Frias wrote:
>>
>>> On 10/24/2016 06:55 PM, Thomas Gleixner wrote:
>>>
>>>> On Mon, 24 Oct 2016, Mason wrote:
>>>>
>>>>> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device
>>>>> makes the system lock-up disappear.
>>>>
>>>> The way how lazy irq disabling works is:
>>>>
>>>> 1) Interrupt is marked disabled in software, but the hardware is not masked
>>>>
>>>> 2) If the interrupt fires befor the interrupt is reenabled, then it's
>>>>    masked at the hardware level in the low level interrupt flow handler.
>>>
>>> Would you mind explaining what is the intention behind?
>>> Because it does not seem obvious why there isn't a direct map between
>>> "disable_irq*()" and "mask_irq()"
>>
>> I had a similar, but slightly different question:
>>
>> What is the difference between struct irq_chip's
>>
>>  * @irq_shutdown:	shut down the interrupt (defaults to ->disable if NULL)
>>  * @irq_disable:	disable the interrupt
>>  * @irq_mask:		mask an interrupt source
> 
> One important difference between disable and mask is that disable is
> perfectly allowed not to care about pending signals, whereas mask must
> preserve an interrupt becoming pending whilst masked.

(For my information)

Is it correct to say that "mask" is supposed to defer any interrupt
until sometime later; while "disable" will simply discard incoming
interrupts, losing them forever.

Is the irq_mask() call-back exposed via some module-visible API?

include/linux/interrupt.h documents mostly enable/disable variants.

extern void disable_irq_nosync(unsigned int irq);
extern bool disable_hardirq(unsigned int irq);
extern void disable_irq(unsigned int irq);
extern void disable_percpu_irq(unsigned int irq);
extern void enable_irq(unsigned int irq);
extern void enable_percpu_irq(unsigned int irq, unsigned int type);
extern bool irq_percpu_is_enabled(unsigned int irq);
extern void irq_wake_thread(unsigned int irq, void *dev_id);

Regards.

WARNING: multiple messages have this Message-ID (diff)
From: slash.tmp@free.fr (Mason)
To: linux-arm-kernel@lists.infradead.org
Subject: Disabling an interrupt in the handler locks the system up
Date: Tue, 25 Oct 2016 15:56:11 +0200	[thread overview]
Message-ID: <580F647B.5000202@free.fr> (raw)
In-Reply-To: <534c4588-f220-25a3-e7aa-84484f348bd1@arm.com>

On 25/10/2016 12:45, Marc Zyngier wrote:
> On 25/10/16 09:36, Mason wrote:
>> On 25/10/2016 10:29, Sebastian Frias wrote:
>>
>>> On 10/24/2016 06:55 PM, Thomas Gleixner wrote:
>>>
>>>> On Mon, 24 Oct 2016, Mason wrote:
>>>>
>>>>> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device
>>>>> makes the system lock-up disappear.
>>>>
>>>> The way how lazy irq disabling works is:
>>>>
>>>> 1) Interrupt is marked disabled in software, but the hardware is not masked
>>>>
>>>> 2) If the interrupt fires befor the interrupt is reenabled, then it's
>>>>    masked at the hardware level in the low level interrupt flow handler.
>>>
>>> Would you mind explaining what is the intention behind?
>>> Because it does not seem obvious why there isn't a direct map between
>>> "disable_irq*()" and "mask_irq()"
>>
>> I had a similar, but slightly different question:
>>
>> What is the difference between struct irq_chip's
>>
>>  * @irq_shutdown:	shut down the interrupt (defaults to ->disable if NULL)
>>  * @irq_disable:	disable the interrupt
>>  * @irq_mask:		mask an interrupt source
> 
> One important difference between disable and mask is that disable is
> perfectly allowed not to care about pending signals, whereas mask must
> preserve an interrupt becoming pending whilst masked.

(For my information)

Is it correct to say that "mask" is supposed to defer any interrupt
until sometime later; while "disable" will simply discard incoming
interrupts, losing them forever.

Is the irq_mask() call-back exposed via some module-visible API?

include/linux/interrupt.h documents mostly enable/disable variants.

extern void disable_irq_nosync(unsigned int irq);
extern bool disable_hardirq(unsigned int irq);
extern void disable_irq(unsigned int irq);
extern void disable_percpu_irq(unsigned int irq);
extern void enable_irq(unsigned int irq);
extern void enable_percpu_irq(unsigned int irq, unsigned int type);
extern bool irq_percpu_is_enabled(unsigned int irq);
extern void irq_wake_thread(unsigned int irq, void *dev_id);

Regards.

  reply	other threads:[~2016-10-25 13:56 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-21 16:37 Disabling an interrupt in the handler locks the system up Mason
2016-10-21 16:37 ` Mason
2016-10-21 17:46 ` Marc Zyngier
2016-10-21 17:46   ` Marc Zyngier
2016-10-21 18:39   ` Mason
2016-10-21 18:39     ` Mason
2016-10-21 19:14     ` Marc Zyngier
2016-10-21 19:14       ` Marc Zyngier
2016-10-21 19:47       ` Mason
2016-10-21 19:47         ` Mason
2016-10-21 19:49         ` Thomas Gleixner
2016-10-21 19:49           ` Thomas Gleixner
2016-10-21 20:27           ` Mason
2016-10-21 20:27             ` Mason
2016-10-22 11:37             ` Marc Zyngier
2016-10-22 11:37               ` Marc Zyngier
2016-10-22 23:10               ` Mason
2016-10-22 23:10                 ` Mason
2016-10-24  8:17                 ` Marc Zyngier
2016-10-24  8:17                   ` Marc Zyngier
2016-10-24 16:12                 ` Mason
2016-10-24 16:12                   ` Mason
2016-10-24 16:55                   ` Thomas Gleixner
2016-10-24 16:55                     ` Thomas Gleixner
2016-10-25  8:29                     ` Sebastian Frias
2016-10-25  8:29                       ` Sebastian Frias
2016-10-25  8:36                       ` Mason
2016-10-25  8:36                         ` Mason
2016-10-25 10:45                         ` Marc Zyngier
2016-10-25 10:45                           ` Marc Zyngier
2016-10-25 13:56                           ` Mason [this message]
2016-10-25 13:56                             ` Mason
2016-10-25 13:56                             ` Thomas Gleixner
2016-10-25 13:56                               ` Thomas Gleixner
2016-10-25  9:20                       ` Thomas Gleixner
2016-10-25  9:20                         ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=580F647B.5000202@free.fr \
    --to=slash.tmp@free.fr \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=sf84@laposte.net \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.