Как синхронизировать PFLT_POST_OPERATION_CALLBACK и поток -
От: LimyKurn  
Дата: 13.09.18 22:22
Оценка:
Имеется исходник драйвера минифильтра, который ведет лог разных IRP-операций с файлами.
Архитектура довольно прикольная — своей простотой...

В PRE_OPERATION_CALLBACK ничего нет.

Есть POST_OPERATION_CALLBACK — он из операций и всяких собранных данных (вроде PID процесса) формирует готовые строки и добавляет их в "очередь" на логирование.
И есть отдельный поток, запущен он таким образом:
PsCreateSystemThread(hThread, (ACCESS_MASK)0,
NULL,
(HANDLE) 0,
NULL,
loggerThread,
NULL);
В потоке каждые 10 минут проверяется, не наполнилась ли "очередь", и если да, то она грузится в лог (лог — это файл, но там еще всякая обработка буфера, который в этом файл запишется — есть сжатие и еще что-то — все прямо здесь, в драйвере) и опустошается.

А "очередь" представляет собой не что иное, как простой PWCHAR (даже не UNICODE_STRING). Прямо так и объявлено, в глобальной области:
PWCHAR szLogQueue;

Резюмируя: каллбек аппендит данные в глобальный PWCHAR, а совершенно не зависящий от него поток каждые свои 10 минут проверяет PWCHAR, открывает-пишет-закрывает файл лога и заново allocatит PWCHAR (в NonPagedPool).

И вроде бы все это работает, да только код течёт. За несколько часов забивает все ОЗУ. Написал ускоренный тест — все подтвердилось.

И мне, еще очень начинающему в NT, нужно исправить это — проставив ExFreePoolWithTag везде, где нужно.
Делать что-либо радикальное, типа вынести логирование в юзермод или хотя бы переписать на UNICODE_STRING, я пока не могу. Код лапша, да и я не потяну.

Казалось бы, все просто. В потоке перед alloc ставим ExFreePoolWithTag. А чтобы не было такого, когда поток уже очистил, но не выделил заново, а тут к указателю обращается каллбак — для этого используем мьютексы, то есть и обращения из потока, и обращения из каллбака заворачиваем в lockи.

Только вот беда — согласно MSDN, POST_OPERATION_CALLBACK не должен сам по себе создавать мьютексы. Причем про ждать не сказано, а вот создавать — да.
Правда, тот же MSDN разрешает делать это через FltDoCompletionProcessingWhenSafe и FltQueueDeferredIoWorkItem.
Но уже в этих функциях написано, что в случае IRP_MJ_WRITE их опять же применять нельзя — а этому драйверу нужна и эта операция в том числе — он пишет число записанных байт и др.
В итоге имеем, что никаких lockов сюда вообще нельзя. И как тогда поступить?
Отредактировано 13.09.2018 22:23 LimyKurn . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.