почему мы можем получить доступ к памяти из невыгружаемого пула на уровне DISPATCH LEVEL или выше

«почему мы можем получить доступ к памяти из невыгружаемого пула на уровне DISPATCH или выше» — это утверждение, вопрос в том, почему мы не можем получить доступ к памяти из выгружаемого пула IRQL >= DISPATCH_LEVEL?

Что ж...

«Любая подпрограмма, работающая с IRQL выше APC_LEVEL, не может ни выделить память из выгружаемого пула, ни безопасно получить доступ к памяти в выгружаемом пуле. Если подпрограмма, работающая с IRQL выше APC_LEVEL, вызывает сбой страницы, это фатальная ошибка».

-- http://msdn.microsoft.com/en-us/library/windows/hardware/ff554368%28v=vs.85%29.aspx

Почему это:

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

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

Теперь происходит еще одно прерывание, но поскольку вы все еще ждете загрузки данных, как вы думаете, что произойдет сейчас?

Знаю это,

«Удерживание спин-блокировки в течение неоправданно длительного времени может повредить общесистемной производительности».

поскольку ваш драйвер дольше ждет, пока что-то произойдет, ваше ядро ​​зависнет.

Также,

«Обратите внимание, что поток не может блокироваться, удерживая спин-блокировку, потому что это может привести к взаимоблокировке. Кроме того, вытеснение отключено на данном процессоре, пока удерживается спин-блокировка».

-- https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/synchronization/synchronization.html

в любом случае, читайте это дальше:

«Код драйвера, работающий с IRQL > PASSIVE_LEVEL, должен выполняться как можно быстрее. Чем выше IRQL, с которым выполняется подпрограмма, тем важнее для хорошей общей производительности настроить эту подпрограмму на выполнение как можно быстрее. Например, любой Драйвер, который вызывает KeRaiseIrql, должен сделать ответный вызов KeLowerIrql, как только сможет».

-- http://msdn.microsoft.com/en-us/library/windows/hardware/ff554368%28v=vs.85%29.aspx

Ошибка страницы — это исключение, которое должно быть быстро обработано диспетчером памяти. Пока ваш драйвер удерживает спин-блокировку и держит этот процессор в заложниках, этот процессор сейчас практически мертв.

MSDN говорит:

«Хотя подпрограмма драйвера удерживает циклическую блокировку, она не может вызвать аппаратное или программное исключение без отключения системы. Другими словами, ISR драйвера и любая подпрограмма SynchCritSection, предоставляемая драйвером при вызове KeSynchronizeExecution, не должна вызывать ошибка или ловушка, такая как сбой страницы или арифметическое исключение, и не может вызывать исключение программного обеспечения. больше не работает на уровне IRQL = DISPATCH_LEVEL».

-- http://msdn.microsoft.com/en-us/library/windows/hardware/ff559854%28v=vs.85%29.aspx

Все это отвечает на вопрос, что произойдет или что может произойти. Что касается ответа, почему мы не можем использовать выгружаемую память выше или на уровне DISPATCH_LEVEL:

1. В большинстве случаев это приводит к взаимоблокировке, что в мире ядра является сбоем ядра.
2. Это вызовет задержку в ядре, что плохо.
3. Обратитесь к 1, это важно.

Я попытался получить как можно больше соответствующей информации, если вы все еще не проданы, попробуйте прочитать о спин-блокировках, функциях повторного входа, обработке прерываний, пейджинге. Попробуйте прочитать для Linux, Windows и ядра ОС Apple. Все они говорят одно и то же с разными подробностями.