linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* (repost) cleaning up handling of bad IRQs
@ 2020-12-18 14:57 Enrico Weigelt, metux IT consult
  2020-12-18 14:57 ` [PATCH 01/23] kernel: irq: irqdescs: warn on spurious IRQ Enrico Weigelt, metux IT consult
                   ` (18 more replies)
  0 siblings, 19 replies; 21+ messages in thread
From: Enrico Weigelt, metux IT consult @ 2020-12-18 14:57 UTC (permalink / raw)
  To: linux-kernel
  Cc: mark.rutland, alexander.shishkin, jolsa, namhyung,
	catalin.marinas, will, msalter, jacquiot.aurelien, gerg, geert,
	tsbogend, James.Bottomley, deller, benh, paulus, ysato, dalias,
	davem, tglx, bp, x86, hpa, linus.walleij, bgolaszewski, maz,
	tony, arnd, linux-alpha, linux-c6x-dev, linux-ia64, linux-m68k,
	linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
	sparclinux, linux-gpio, linux-omap, linux-arch

Hello friends,

 << reposting, since first queue didn't go through completely, due to mailer problem >>

here's a patch queue for cleaning up the IRQ handling. Inspired by a
discussion we had on a previous patch of mine:

    "arch: fix 'unexpected IRQ trap at vector' warnings"
    https://www.spinics.net/lists/kernel/msg3763137.html

Turned out that the whole message, as it is right now, doesn't make much
sense at at all - not just incorrect wording, but also not quite useful
information. And the whole ack_bad_irq() thing deserves a cleanup anyways.

So, I've had a closer look and came to these conclusions:

1. The warning message doesn't need to be duplicated in the per architecture
   ack_bad_irq() functions. All, but one callers already do their own warning.
   Thus just adding a pr_warn() call there, printing out more useful data
   like the hardware IRQ number, and dropping all warnings from all the
   ack_bad_irq() functions.

2. Many of the ack_bad_irq()'s count up the spurious interrupts - lots of
   duplications over the various archs. Some of them using atomic_t, some
   just plain ints. Consolidating this by introducing a global counter
   with inline'd accessors and doing the upcounting in the (currently 3)
   call sites of ack_bad_irq(). After that, step by step changing all
   archs to use the new counter.

3. For all but one arch (x86), ack_bad_irq() became a no-op.

   On x86, it's just a call to ack_APIC_irq(), in order to prevent lockups
   when IRQs missed to be ack'ed on the APIC. Could we perhaps do this in
   some better place ? In that case, ack_bad_irq() could easily be removed
   entirely.

have fun,

--mtx




^ permalink raw reply	[flat|nested] 21+ messages in thread
* cleanup handling of bad IRQs
@ 2020-12-18 14:30 Enrico Weigelt, metux IT consult
  2020-12-18 14:31 ` [PATCH 15/23] arch: mips: use generic irq error counter Enrico Weigelt, metux IT consult
  0 siblings, 1 reply; 21+ messages in thread
From: Enrico Weigelt, metux IT consult @ 2020-12-18 14:30 UTC (permalink / raw)
  To: linux-kernel
  Cc: mark.rutland, alexander.shishkin, jolsa, namhyung,
	catalin.marinas, will, msalter, jacquiot.aurelien, gerg, geert,
	tsbogend, James.Bottomley, deller, benh, paulus, ysato, dalias,
	davem, tglx, bp, x86, hpa, linus.walleij, bgolaszewski, maz,
	tony, arnd, linux-alpha, linux-c6x-dev, linux-ia64, linux-m68k,
	linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
	sparclinux, linux-gpio, linux-omap, linux-arch

Hello friends,


here's a patch queue for cleaning up the IRQ handling. Inspired by a
discussion we had on a previous patch of mine:

    "arch: fix 'unexpected IRQ trap at vector' warnings"
    https://www.spinics.net/lists/kernel/msg3763137.html

Turned out that the whole message, as it is right now, doesn't make much
sense at at all - not just incorrect wording, but also not quite useful
information. And the whole ack_bad_irq() thing deserves a cleanup anyways.

So, I've had a closer look and came to these conclusions:

1. The warning message doesn't need to be duplicated in the per architecture
   ack_bad_irq() functions. All, but one callers already do their own warning.
   Thus just adding a pr_warn() call there, printing out more useful data
   like the hardware IRQ number, and dropping all warnings from all the
   ack_bad_irq() functions.

2. Many of the ack_bad_irq()'s count up the spurious interrupts - lots of
   duplications over the various archs. Some of them using atomic_t, some
   just plain ints. Consolidating this by introducing a global counter
   with inline'd accessors and doing the upcounting in the (currently 3)
   call sites of ack_bad_irq(). After that, step by step changing all
   archs to use the new counter.

3. For all but one arch (x86), ack_bad_irq() became a no-op.

   On x86, it's just a call to ack_APIC_irq(), in order to prevent lockups
   when IRQs missed to be ack'ed on the APIC. Could we perhaps do this in
   some better place ? In that case, ack_bad_irq() could easily be removed
   entirely.

have fun,

--mtx



^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2020-12-18 15:03 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-18 14:57 (repost) cleaning up handling of bad IRQs Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 01/23] kernel: irq: irqdescs: warn on spurious IRQ Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 02/23] arch: alpha: drop misleading warning " Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 03/23] arch: arm: " Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 04/23] arch: c6x: " Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 05/23] arch: ia64: " Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 06/23] arch: mips: " Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 07/23] arch: parisc: " Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 08/23] arch: powerpc: " Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 09/23] arch: s390: " Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 10/23] arch: sh: " Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 11/23] arch: sparc: " Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 12/23] arch: x86: " Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 13/23] arch: generic: " Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 14/23] kernel: generic counter for interrupt errors Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 15/23] arch: mips: use generic irq error counter Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 16/23] arch: alpha: " Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 17/23] arch: arm: " Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 18/23] arch: arm64: " Enrico Weigelt, metux IT consult
2020-12-18 14:57 ` [PATCH 19/23] arch: c6x: " Enrico Weigelt, metux IT consult
  -- strict thread matches above, loose matches on Subject: below --
2020-12-18 14:30 cleanup handling of bad IRQs Enrico Weigelt, metux IT consult
2020-12-18 14:31 ` [PATCH 15/23] arch: mips: use generic irq error counter Enrico Weigelt, metux IT consult

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).