Re: [PATCH net-next v2] declance: Remove IRQF_ONESHOT

Maciej W. Rozycki
2026-03-29T20:27:58Z

On Tue, 27 Jan 2026, Maciej W. Rozycki wrote:

> > > I need more data to conclude whether this is the right change to make I'm
> > > afraid. Thank you for looking into it though.
> >
> > Fair enough. Would it work for you if we scratch this from net-next and
> > you route this or something else via the mips tree?
>
> No need to, I think I understand the situation now. Surely the comment
> referring IRQF_ONESHOT in arch/mips/dec/ioasic-irq.c needs to be removed,
> but otherwise this is:
>
> Acked-by: Maciej W. Rozycki <macro@orcam.me.uk>
>
> Thank you for clarifying this to me, and doing the clean-up in the first
> place!

I've now got back to it and while preparing the justification for the
removal of the IRQF_ONESHOT recommendation and having looked through
Documentation/core-api/real-time/differences.rst I became stumped and
need a further clarification after all.

I read in the document that:

"However, on a PREEMPT_RT system, interrupts are forced-threaded and no
longer run in hard IRQ context."

and:

"All interrupts are forced-threaded in a PREEMPT_RT system. The exceptions
are interrupts that are requested with the IRQF_NO_THREAD, IRQF_PERCPU, or
IRQF_ONESHOT flags."

-- do I infer correctly that on a PREEMPT_RT system in the absence of any
flags passed to request_irq() the handler requested such as one concerned
here (i.e. lance_dma_merr_int()) will run with interrupts locally enabled
on the CPU?

If so, then either we need to go back and make sure the originating IRQ
line is masked throughout the execution of the handler (and no standard
irq-flow method provides it), or any IOASIC DMA error interrupt handlers,
including this one, have to use the IRQF_NO_THREAD flag instead or the CPU
will hang looping on the interrupt being retriggered at enable time, as in
the absence of masking the interrupt output of the interrupt controller
remains active until the final EOI action. Have I missed anything?

Mind that this is somewhat theoretical, given that declance.c is only for
systems using the MIPS CPU and arch/mips does not enable ARCH_SUPPORTS_RT,
however should it do sometime, I'd rather all the hell didn't break loose.
And there's previous art already as I can see IRQF_NO_THREAD used through
arch/mips, following commit 5a4a4ad851dd ("MIPS: Mark cascade and low
level interrupts IRQF_NO_THREAD").

Maciej