s390/entry: Mark IRQ entries to fix stack depot warnings

In the Linux kernel, the following vulnerability has been resolved:

s390/entry: Mark IRQ entries to fix stack depot warnings

The stack depot filters out everything outside of the top interrupt

context as an uninteresting or irrelevant part of the stack traces. This

helps with stack trace de-duplication, avoiding an explosion of saved

stack traces that share the same IRQ context code path but originate

from different randomly interrupted points, eventually exhausting the

stack depot.

Filtering uses in_irqentry_text() to identify functions within the

.irqentry.text and .softirqentry.text sections, which then become the

last stack trace entries being saved.

While __do_softirq() is placed into the .softirqentry.text section by

common code, populating .irqentry.text is architecture-specific.

Currently, the .irqentry.text section on s390 is empty, which prevents

stack depot filtering and de-duplication and could result in warnings

like:

Stack depot reached limit capacity

WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8

with PREEMPT and KASAN enabled.

Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into

the .irqentry.text section and updating the kprobes blacklist to include

the .irqentry.text section.

This is done only for asynchronous interrupts and explicitly not for

program checks, which are synchronous and where the context beyond the

program check is important to preserve. Despite machine checks being

somewhat in between, they are extremely rare, and preserving context

when possible is also of value.

SVCs and Restart Interrupts are not relevant, one being always at the

boundary to user space and the other being a one-time thing.

IRQ entries filtering is also optionally used in ftrace function graph,

where the same logic applies.