Как Kernel обрабатывает блокировку в контексте процесса, когда происходит прерывание?

Question

Прежде всего извините за немного двусмысленности в вопросе ... То, что я хочу, чтобы понять, по указанному ниже СЦЕНАРИЮ

Пусть porcess работает, он держит один замок, теперь после приобретения замка HW прерывания генерируются, так Как ядро ​​справится с этой ситуацией, будет ли она ждать блокировки? если да, что делать, если обработчик прерывания должен получить доступ к этой блокировке или общим данным, защищенным этой блокировкой в ​​процессе?

Answer 1

Позвольте мне объяснить некоторые основные свойства обработчика прерываний или нижней половины.

1. Обработчик не может передавать данные в пользовательское пространство или из него, поскольку он не выполняется в контексте процесса.
2. Обработчики также не могут делать ничего, что могло бы спать, например, вызов wait_event, выделение памяти с помощью чего-либо, кроме GFP_ATOMIC, или блокировка семафора
3. обработчики не могут назвать расписание.

То, что я пытаюсь сказать, заключается в том, что обработчик прерываний работает в атомном контексте. Они не могут спать, поскольку они не могут быть перенесены. прерывания не имеют контекста процесса резервного копирования

Вышеупомянутое по дизайну. Вы можете делать все, что хотите, в коде, просто будьте готовы к последствиям

Предположим, что вы приобрели блокировку в обработчике прерываний (плохой дизайн). При возникновении прерывания процесс сохраняет свой регистр в стеке и запускает ISR. теперь, после приобретения блокировки, вы оказались бы в тупике, так как их ISR не знает, что делает этот процесс.

Процесс не будет в состоянии возобновить выполнение до тех пор, пока не будет сделано это с ISR

В преимущественном ядре в ISR, и процесс может быть выгружать, но для невытесняющего ядра вы мертвы.

Answer 2

В ядре Linux есть несколько функций по приобретению спинлоков, чтобы решать проблемы, подобные тем, которые вы поднимаете здесь. В частности, есть spin_lock_irq(), который отключает прерывания (на процессоре, в котором выполняется процесс) и получает спин-блокировку. Это можно использовать, когда код знает прерывания, до того, как будет получена прямая блокировка; в случае, если функция может быть вызвана в разных контекстах, есть также spin_lock_irqsave(), которая отменяет текущее состояние прерываний перед их отключением, так что они могут быть повторно подключены на spin_unlock_irqrestore().

В любом случае, если блокировка используется как в контексте процесса, так и в контексте прерывания (что является хорошей и очень общей конструкцией, если есть данные, которые должны быть разделены между контекстами), тогда контекст обработки должен отключать прерывания (локально на процессоре, на котором он работает) при приобретении спин-блокировки, чтобы избежать взаимоблокировок. Фактически, lockdep («CONFIG_PROVE_LOCKING») проверяет это и предупреждает, если спин-блокировка используется таким образом, который восприимчив к «прерыванию, когда контекст процесса блокирует блокировку».