В сторону: нет никаких оснований предполагать, что «управление памятью» отключено при загрузке нового статуса процессора; на самом деле, в процессорах по моему опыту такого бы не было. Но это не имеет отношения к этому ответу.
Мы выполняем в пользовательском режиме и извлекаем инструкцию TRAP. Счетчик программы (скажем так) указывает на инструкцию после TRAP.
Теперь процессор выполняет TRAP. Он загружает новый статус процессора, который переключает процессор в режим ядра. Предположим, что это само по себе не запрещает прерывания устройства.
СЕЙЧАС ... устройство прерывается. Аппаратный или программный механизм сохраняет состояние процессора (= режим ядра) и счетчик программы (= адрес пользовательского режима команды после TRAP). Процедура обработки прерываний устройства выполняет свою функцию и выполняет возврат из прерывания для восстановления счетчика программы и состояния процессора. Мы не можем возобновить «половину инструкции TRAP» - единственное, что может произойти, - это то, что мы начинаем выполнять инструкцию, на которую указывает PC, т.е. мы выполняем инструкцию после TRAP, но в режиме ядра.
Точная проблема зависит от архитектуры системы:
Если карта адресов ядра является надмножеством карты адресов пользователя (типично для ОС, где пользовательское пространство составляет половину общего адресного пространства), то мы выполняем предоставленный пользователем код в режиме ядра, что является по меньшей мере серьезной привилегией проблема, и может привести к сбою страницы из-за сбоя страницы, когда мы не можем ее решить
Если карта адресов ядра не включает в себя пространство пользователя (часто это происходит в системах с ограниченным размером виртуального адреса), то это эквивалентно произвольному переходу в ядро.
Суть в том, что вам нужно как состояние процессора, так и счетчик программы, чтобы определить «где вы находитесь», и оба они должны быть сохранены / обновлены вместе; или другими словами, никакое изменение управления (такое как прерывание) не может быть разрешено в середине.