| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Системное программирование и WinAPI > Cинхрониз. PFLT_POST_OPERATION_CALLBACK и поток |
| Автор: LimyKurn 15.9.2018, 21:08 | ||
| Имеется исходник драйвера минифильтра, который ведет лог разных IRP-операций с файлами. Архитектура довольно прикольная — своей простотой... В PRE_OPERATION_CALLBACK ничего нет. Есть POST_OPERATION_CALLBACK — он из операций и всяких собранных данных (вроде PID процесса) формирует готовые строки и добавляет их в "очередь" на логирование. И есть отдельный поток, запущен он таким образом:
В потоке каждые 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ов сюда вообще нельзя. И как тогда поступить? |