Отмена IRP

[urock]

Добрый день!

Мой очередной вопрос связан с отменой IRP_MJ_READ/WRITE. Допустим, что я хочу отменять запросы ввода-выводы на чтение/запись, если он не завершаются за разумное время (скажем 10 сек). Можно ли делать следующим образом? (я отталкиваюсь от известного кода У. Они)
1. инициализировать событие cansel_event
2. в DispatchReadWrite:
    --  сбрасывать это событие
    --  вызывать StartPacket для начала обработки IRP
    --  далее ожидать KeWaitForSingleObject по cansel_event с таймаутом 10 сек
    --  если ожидание заканчивается со статусом STATUS_TIMEOUT завершать запрос IRP со статусом STATUS_CANSELLED, а из DispatchReadWrite возвращать STATUS_SUCCESS
    -- если ожидание заканчивается со статусом STATUS_SUCCESS, то запрос уже был завершен в течение 10 сек, я ничего не делаю, а просто возвращаю STATUS_SUCCESS из DispatchReadWrite
3. устанавливается событие при завершении запроса нормальным образом в функции DPC.
4. Никаких IoCanselIrp и функций отмены я использовать тут не предполагаю

Меня тут смущает 1 момент, получается моя DispatchReadWrite не вернет управление стороне, вызвавшей IoCallDriver (I/O Manager или вышестоящему драйверу) в течение довольно долго времени (пока запрос либо не будет завершен, либо не истечет таймаут). Обычно она возвращала управление после того, как StartIo пошлет запрос на выполнение операции оборудованию, с результатом STATUS_PENDING. Нормально ли это?

У. Они предлагает следующую альтернативу данному подходу (стратегия Отмена "Чужих" IRP с ожиданием): в вышестоящем драйвере устанавливать функцию завершения для запроса, передавать этот запрос вниз, далее ожидать по событию с таймаутом, событие устанавливать в функции завершения, отменять запрос в случае окончания ожидания по таймауту.
Я правильно понимаю, что эту функцию должен выполнять предоставленный мной драйвер-фильтр? И вообще может есть другие подходы к отмене запросов обращения к оборудованию по таймауту?

Спасибо, что прочитали)

[sss]

urock, вот перечитал несколько раз и так и не понял. Ты создаешь новый IRP? Что делает функция StartPacket? Передает входящий IRP вниз по стеку или строит новый IRP?

[urock]

Ни то ни другое. Никакого нового IRP не создается, вниз ничего не передается. У меня функциональный драйвер устройства, который сам обращается к оборудованию, обрабатывает и завершает запрос. StartPacket соответственно либо сразу начинает обработку запроса, либо ставит его в очередь, если устройство занято.

Меня собственно вот что смущает: в обязанности диспетчерской функции обработки какого-либо IRP входит выбор одного из трех вариантов: 1. Немедленно завершить запрос. 2. Передать его вниз по стеку. 3. Поставить IRP в очередь на обработку, при этом возвращая значение STATUS_PENDING.

Мой вариант получается, что не подходит ни под какой из вышеперечисленных. С одной стороны, запрос ставится в очередь на обработку, но из диспетчерской функции ничего не возвращается до тех пор, пока запрос либо не завершится нормальным образом, либо не истечет таймаут.

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

[Ochkarik]

urock, если этот запрос был от приложения, то на время вашей паузы (до 10 сек) процесс отправивший этот запрос будет фактически повешен наглухо.
кроме того, нельзя будет использовать ReadFile/WriteFile без ожидания завершения IRP (OVERLAPPED) - это существеннее. это не хорошо для таких пауз. соблазн сделать ожидание не выходя из драйвера - велик, но...
ЗЫ хотя я сам грешен) ожиданиями в IRP да еще и на APC... срочно приходилось выкручиваться а времени не было)