Использование CmRegisterCallback. Синхронизация с user mode.

[Erithron]

Здравствуйте.
Речь пойдет о передаче данных после перехвата из kernel в user.
Например обернем в мьютексы вида:
*процедура RegisterCallback*
1)Захватываем мьютекс
2)записываем перехваченные данные в буфер
3)Отпираем мьютекс


*процедура приема, user mode*
while(1)
{
1)Захватываем мьютекс
2)обрабатываем данные из буфера и очищаем его.
3)Отпираем мьютекс
}

Так вот, какова по вашему вероятность того, что во время ожидания мьютекса процедурой перехвата(с учетом, что мы перехватываем все обращения) к реестру произойдет несколько обращений?) Насколько я понял только одно из них в итоге сможет оказаться в буфере, а остальные уйдут в небытие.
Стоит ли делать систему без ожиданий  в RegisterCallback?

[resource]

Во-первых описано всё крайне непонятно. Надо поконкретнее относительно кода.
Во-вторых, опять же непонятно, в юзермоде и кернелмоде используется один и тот же мьютекс? Я так полагаю, что да, иначе вообще не было бы синхронизации. Но в итоге это очень странный, если не сказать неправильный способ синхронизации.

[sss]

Erithron, следующие обращения к реестру будут происходить  других потоках и блокироваться на захвате мьютекса. А вот какой поток, в конце концов, захватит мьютекс первым - один из потоков "*процедура RegisterCallback*" или  поток "*процедура приема, user mode*" - будет решаться теорией вероятности и телепатическими способностями. Данная проблема называется "состояние гонок"....

[Erithron]

Во-первых описано всё крайне непонятно. Надо поконкретнее относительно кода.
Во-вторых, опять же непонятно, в юзермоде и кернелмоде используется один и тот же мьютекс? Я так полагаю, что да, иначе вообще не было бы синхронизации. Но в итоге это очень странный, если не сказать неправильный способ синхронизации.

Да, мьуютекс один. Относительно кода не описываю, т.к. его нету)

Erithron, следующие обращения к реестру будут происходить  других потоках и блокироваться на захвате мьютекса. А вот какой поток, в конце концов, захватит мьютекс первым - один из потоков "*процедура RegisterCallback*" или  поток "*процедура приема, user mode*" - будет решаться теорией вероятности и телепатическими способностями. Данная проблема называется "состояние гонок"....

А точно, не заметил)


Не подскажите тогда, как это лучше синхронизировать? Дабы достичь максимальной скорости. "Усложнить" мьютексо-обверточный тип или использовать другие способы(например ивенты, или как писал выше, попробывать обойтись без синхро-операций)?

[resource]

Всё зависит от того, как организован буфер, и как данные передаются в юзермод. Я почему и говорил, что надо обсуждать не абстрактно, а относительно кода.
Как я вижу из всех этих абстракций, мьютексами сблокирован доступ к буферу. Я не пойму зачем это нужно, до тех пор пока не узнаю как организован буфер. Навскидку, похоже на мапинг.

[PredatorAlpha]

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

[resource]

Ну если не применять никакой синхронизации, то как в данном случае чтение и запись могут производиться не асинхронно?

[Ochkarik]

имеется в виду одновременная запись из двух потоков.
или одновременное чтение из двух потоков.

"один поток чтения - один поток записи", действительно можно без мьютексов синхронизировать.

[Ochkarik]

PS хотя....я бы и многопоточную запись обошел бы, без мьютексов) чисто на атомарных перестановках. (блочную, разумеется!)
для НЕКОТОРЫХ случаев очень красиво может получится)

[resource]

Что-то я уже совсем ничего не понимаю.
Callback срабатывает в контексте того потока, который осуществляет обращение к реестру. Одновременно обращаться к реестру могут много потоков. Вопрос о том, что надо блокировать, а что не надо, упирается в способ передачи данных в юзермод. Судя по всему - это маппинг, иначе вообще не было бы никакого смысла во всех этих мьютексах со стороны юзермода. Но это всё какой-то беспредметный разговор до тех пор, пока ТС не соблаговолит объяснить эти начала.

Но вот поскольку обращаться к реестру могут одновременно много потоков, то как минимум в самом драйвере полюбому надо будет сблокировать запись в буфер.

[Erithron]

Вообще вопрос о синхронизации растет из неполного понимая работы коллбаков. Может кто сможет объяснить как это происходит?
Создается отдельный поток в котором вызывается ф-ия перехвата при изменениях в реестре? И что будет если мы поставим wait в перехватчик, что случиться если за время ожидания произойдет 10 изменений в реестре?
Пробовал ставить wait, все сильно начинает виснуть и без перезагрузки не обойтись(как будто, wait останавливает весь драйвер). И допустим если я поставил wait 5 секунд, первый перехват реестра идет через 5 секунд как и надо но последующие начинают идти раньше)

"один поток чтения - один поток записи"

Вот такое мне и надо) Однако основная проблема по моему мнению может возникнуть из-за того что user не успеет за kernel и в итоге, если без синхронизации будет переполнение, если с синхронизацией не все данные могут достигнуть user. Насколько я понимаю kernel работает по шустрее user(а как часто происходит этот отлов реестра по сравнению со скоростью работы user я не представляю), поэтому нужен оптимальный вариант. Или я слишком "загоняюсь" и создаю проблемы которых не существует?)

[resource]

Создается отдельный поток в котором вызывается ф-ия перехвата при изменениях в реестре?

Никаких отдельных потоков не создается. Еще раз повторяю, callback вызывается в контексте потока, который обращается к реестру.

И что будет если мы поставим wait в перехватчик

Что за wait? Это функция или что? Если функция, то откуда?

[Erithron]

Ну использовал я KeWaitForSingleObject, где ожидался эвент.
Однако если я вставлял wait в процедуру обработки IRP_MJ_DEVICE_CONTROL, ожидание шло, однако коллбак работал и отлавливал все изменения в реестре. Или это уже IRP_MJ_DEVICE_CONTROL как-то "многопоточно" работает?)

[resource]

Я уже не понимаю. Что за ивент ты ждешь? Может какие куски кода привести и пояснить, а то мы тут долго так будем говорить ни о чём

[Ochkarik]

запоздалое сообщение: (в ответ на https://forum.shelek.ru/index.php/topic,24188.msg233318.html#msg233318):

1. Имелось в виду то, что в данном случае (если я правильно понял) можно в качестве FIFO использовать кольцевой буфер для передачи данных.
Хотя бы просто потому, что в промежутках между двумя операциями "2)обрабатываем данные из буфера и очищаем его"
может произойти довольно большое число "2)записываем перехваченные данные в буфер".

2. Раз речь зашла о кольцевых буферах, то для случаев, когда один-поток-пишет/один-поток-читает, синхронизация операций чтения/записи может быть выполнена на interlocked функциях, БЕЗ МЬЮТЕКСОВ. И использование циклиического буфера- отчасти разрешает проблему "состояния гонок".

3. Я же, на вскидку заметил, что чисто ради эстетического наслаждения и интереса, без использования мьютексов, можно попробовать реализовать систему синхронизации операций многопоточной записи  _и_ многопоточного чтения блоков кольцевого буфера) В стиле а-ля SList.

PS а то что маппинг - никто и не спорит... вопрос логической организации обмена данными)

[Erithron]

Я уже не понимаю. Что за ивент ты ждешь? Может какие куски кода привести и пояснить, а то мы тут долго так будем говорить ни о чём

Ну смысл в том, что мне нужно понять как работает коллбак)
То есть если у меня есть простенький драйвер с коллбаком, то мой драйвер вместе с коллбаком будет работать в один поток, и вызывая ф-ии вида KeWaitxxx останавливаться будет весь драйвер?

Но экспериментируя я заметил следующее:
1)Если поставить KeWaitxxx с бесконечным ожиданием в процедуру коллбака, то замирает, видимо, весь драйвер(очень сильно все зависает, драйвер не принимает команды, коллбак не перехватывает изменения в реестре).
2)Если поставить KeWaitxxx с бесконечным ожиданием в процедуру обработки IRP_MJ_DEVICE_CONTROL, то никаких видных на лицо зависаний нету и процедура коллбака нормально работает(не останавливается).

[Ochkarik]

читайте Руссиновича. раздел про переключение потоков.
кажется у вас в этом небольшой пробел...

[Erithron]

Ну вот допустим грубый код:
ntStatus = CmRegisterCallback(RegWatcher,ext,&Cookie);
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = DriverDeviceControl;

NTSTATUS RegWatcher(IN PVOID Data,IN PVOID CallType,IN PVOID CallData)
{
  KeWaitxxx //Если KeWaitxxx стоит с бесконечным ожиданием, то все повисает) Команды типа TEST_SMTH драйвер уже не принимает и не выводит сообщений + почему-то начинает глючть пуск и сама система почти усмирает.
DbgPrint("!!!");
  
}


NTSTATUS DriverDeviceControl(IN PDEVICE_OBJECT DeviceObject,IN PIRP Irp)
{
case TEST_SMTH:
{
KeWaitxxx //Если KeWaitxxx стоит с бесконечным ожиданием, то ожидание идет, до вывода "aaa", не доходит но вывод "!!!" из  RegWatcher идет.
DbgPrint("aaa");
}
}

читайте Руссиновича. раздел про переключение потоков.
кажется у вас с этим небольшой пробел...

Спасибо, почитаю.
ЗЫ: В прицнипе приведенный выше код не актуален, т.к. иду читать теорию)

[Ochkarik]

то есть большой...)
правда почитайте. я не к тому что мне объяснять лень - просто там ооочень хорошо изложено.

[Erithron]

Вроде разобрался)
1)Драйверы в основном однопотоковая штука
2)IRP_MJ_DEVICE_CONTROL есть прерывания и поэтому выполняются не в контексте потока драйвера. Поэтому при KeWaitxxx в обработчике прерываний, драйвер продолжает функционировать.
3)RegisterCallback выполняется в контексте потока драйвера. Представляет собой что-то вроде "подключения к системе", и система  оповещает драйвер о махинациях с реестром. Однако, система запрашивает так же ответ, поэтому если вставить в обработчик KeWaitxxx с бесконечным ожиданием, то все начинает к хреням виснуть, т.к. не могут быть выполнены эти самые перехваченные махинации в реестре.
Так же насколько я понял RegisterCallback все же уязвима и отлавливает не все махинации с реестром. То есть, если во время обработки RegisterCallback-процедурой одного события реестра, произойдет второе, то второе пройдет мимо обработчика.

Все правильно уяснил?). Особенно интересует часть с RegisterCallback.

[resource]

Ужас. Весь мир с ног на голову поставил. Тут слишком много объяснять надо, на целую книгу потянет, а потому следует всётаки внять рекомендациям в постах #16 и #18.

[Erithron]

В общем да, IRP_MJ_DEVICE_CONTROL совершенно не то, что я написал. С этим я уже точно разобрался)

Однако остается вопрос насчет RegisterCallback. Коллбак представляет собой "фильтр". Происходит "событие"-> оно отправляется в фильтр->фильтр обрабатывает его->отправляет дальше.
Но нужен ответ на вопрос: что будет если во время обработки события фильтром, произойдет еще n событий? Они станут в "очередь"(сколько тогда эта очередь может может вместить таких событий)? Или пройдут мимо фильтра?

[resource]

Да это всё пустое. Надо сначала теорию почитать. Тут надо понимать как функционируют потоки. Никакой очереди не будет (я так думаю), потому что пока один вызов не завершен, то другой вызов в этом же потоке просто никак не может произойти.

[Ochkarik]

http://msdn.microsoft.com/en-us/library/ff560903(VS.85).aspx
ремарка
"RegistryCallback executes at IRQL = PASSIVE_LEVEL and in the context of the thread that is performing the registry operation."
это исчерпываюащя информация, но чтобы ей воспользоваться.... еще раз, повторяю: ЧИТАЙТЕ КНИГУ. иначе у вас полная каша в голове будет.
там нет очереди ТАКИХ событий. там есть процессы и переключение контекстов.

[Erithron]

Спасибо, разобрался)

Последний вопрос:
Допустим мне необходимо передать полный путь к измененному разделу. Однако судя по всему в XP это путь может быть бесконечно длинным и ограничен только общей памятью машины(или я не прав?).
И вот как такое тогда передавать? Или может можно передать "хэндл ключа" и уже в user приложении вытянуть оттуда путь?

ЗЫ: Передачу планирую делать через маппинг, но наверное разница как передавать небольшая.