Why are there "<IRQ>" and "</IRQ>" in the call trace section? What does them imply?

[Valdis Kl=?utf-8?Q?=c4=93?=tnieks]

On Fri, 10 Jul 2020 13:29:29 +0800, "e- d8 i> sunshilong" said:

> [72873.713473]  <IRQ>
> [72873.713474]  switch_mm_irqs_off+0x31b/0x4e0
> [72873.713475]  xnarch_switch_to+0x2f/0x80
> [72873.713476]  ___xnsched_run.part.74+0x154/0x480
> [72873.713476]  ___xnsched_run+0x35/0x50
> [72873.713477]  xnintr_irq_handler+0x346/0x4c0
> [72873.713478]  ? xnintr_core_clock_handler+0x1b6/0x360
> [72873.713479]  dispatch_irq_head+0x8e/0x110
> [72873.713479]  ? xnintr_irq_handler+0x5/0x4c0
> [72873.713481]  ? dispatch_irq_head+0x8e/0x110
> [72873.713482]  __ipipe_dispatch_irq+0xd9/0x1c0
> [72873.713483]  __ipipe_handle_irq+0x86/0x1e0
> [72873.713483]  common_interrupt+0xf/0x2c
> [72873.713484]  </IRQ>
>
> Maybe, the later one(i.e. </IRQ>) implies there was an interrupt
> request and the common_interuppt() function handler it.

No.  It's possible for the kernel traceback to include some routines that
were in an IRQ, and some more that were outside IRQ context.  So you
can tell which are which, the stack dump is formatted as:

<IRQ>
function that was running when the trace was called for
the function that call it
another function back
(...)
interrupt_handler  of some sort
</IRQ>
function that was running when the interrupt hit
this caller
and its parent
etc


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20200710/0fbba8f3/attachment.sig>