我讀了一些相關(guān)的帖子：

You cannot sleep in an interrupt handler because interrupts do not have a backing

process context, and thus there is nothing to reschedule back into. In other

words, interrupt handlers are not associated with a task, so there is nothing to

"put to sleep" and (more importantly) "nothing to wake up". They must run

atomically.

If sleep is allowed, then the linux cannot schedule them and finally cause a

kernel panic with a dequeue_task error. The interrupt context does not even

have a data structure describing the register info, so they can never be scheduled

by linux. If it is designed to have that structure and can be scheduled, the

performance for interrupt handling process will be effected.

所以在我的理解中,中斷處理程序在中斷上下文中運(yùn)行,并且無(wú)法休眠,也就是說(shuō),不能像正常進(jìn)程那樣使用支持機(jī)制執(zhí)行上下文切換.

但是中斷處理程序可能被另一個(gè)中斷中斷.當(dāng)?shù)诙€(gè)中斷處理程序完成其工作時(shí),控制流將跳回第一個(gè)中斷處理程序.

如果沒(méi)有正常的上下文切換,這種“恢復(fù)”是如何實(shí)現(xiàn)的？它是否像普通函數(shù)調(diào)用一樣,所有寄存器和其他相關(guān)內(nèi)容都存儲(chǔ)在某個(gè)堆棧中？

解決方法:

簡(jiǎn)短的回答是,如果中斷處理程序可以被中斷中斷,則中斷處理程序的中斷方式與中斷中斷的任何其他內(nèi)容完全相同.

假設(shè)進(jìn)程X正在運(yùn)行.如果進(jìn)程X被中斷,則中斷處理程序運(yùn)行.在某種程度上存在上下文的情況下,它仍然處理X,盡管它現(xiàn)在在內(nèi)核中運(yùn)行中斷代碼(如果你愿意,可以將狀態(tài)視為X->中斷).如果發(fā)生另一個(gè)中斷,則中斷被中斷,但仍然沒(méi)有特殊的進(jìn)程上下文.現(xiàn)在狀態(tài)是X-> first_interrupt-> second_interrupt.當(dāng)?shù)诙€(gè)中斷結(jié)束時(shí),第一個(gè)中斷將恢復(fù),就像第一個(gè)中斷結(jié)束時(shí)X將恢復(fù)一樣.但是,唯一的過(guò)程上下文是過(guò)程X.

您可以將它們描述為上下文切換,但它們與流程上下文切換不同.它們更類似于進(jìn)入和退出內(nèi)核 – 進(jìn)程上下文保持不變,但執(zhí)行級(jí)別和代碼單元可能會(huì)發(fā)生變化.

標(biāo)簽：linux,interrupt,linux-kernel

來(lái)源： https://codeday.me/bug/20190725/1532068.html

總結(jié)

以上是生活随笔為你收集整理的linux进程被中断打断,linux – 当中断处理程序被另一个中断中断时,中断上下文如何“恢复”？...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。