Опасности Printk или I/O в обработчике прерываний

Question

Почему printk или (I/O) запрещено в обработчике прерываний в linux.? В каком состоянии I/O в обработчике прерываний может вызвать тупик в Linux-системе?

Answer 1

Относительно printk(), это навязчиво. Например, проблема, которую вы отлаживаете, может исчезнуть, добавив printk. В зависимости от настроек он может выводиться на консоль, которая может быть медленной. Вместо этого рекомендуется использовать trace_printk() из ftrace.

Что касается I/O внутри прерывания, помните, что Прерываниям работать на более высокий приоритет, чем другие потоки исполнения, так что любой задержки - будь I/O или что-то еще - будет иметь стук влияние на остальной части система.

Тупики могут произойти из-за конфликта ресурсов. Например, прерывание поступает в тот момент, когда один ресурс, например mutex, уже занят потоком ядра, запущенным в контексте процесса. Теперь попытка подпрограммы обслуживания прерывания хочет получить тот же ресурс приведет к тупиковой ситуации: поток ядра не может быть запущен, потому что ISR имеет более высокий приоритет, а ISR не может завершить, потому что он ожидает ресурса, хранящегося в потоке ядра.

Надеюсь, он ответит на ваш запрос.

ОБНОВЛЕНИЕ: Будет ли вызов printk в обработчике прерываний вызвать тупик? Нет. Например, this extract from makelinux

Одним из свойств printk(), который быстро считается само собой разумеющимся, является его прочность. Функция printk() доступна в любом месте ядра в любое время. Его можно вызвать из контекста прерывания или процесса . Он может быть вызван во время блокировки. Его можно назвать одновременно на нескольких процессорах, но для блокировки не требуется вызывающий абонент .

UPDATE2: Word of caution благодаря tc2keats.

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