[PATCH] ntoskrnl.exe: Implement Ke(Initialize|Insert|Remove)DeviceQueue.

[Rémi Bernon]

On 6/22/21 5:20 PM, Zebediah Figura (she/her) wrote:
> On 6/22/21 7:02 AM, Rémi Bernon wrote:
>> Signed-off-by: Rémi Bernon <rbernon at codeweavers.com>
>> ---
>>
>> MSDN says that the cancel spinlock has to be held whenever these device
>> queues are used, when setting cancel routines, but it's not clear to me
>> why, as IRP cancellation has apparently no effect on these functions
>> behavior (I initially thought they should check and not queue cancelled
>> IRPs, but it looks like they don't).
> 
> Where do you see this? I couldn't find any mention of it from a brief 
> search.
> 

For instance [1]:

"A driver must hold the system cancel spin lock when calling this 
routine if the driver uses the I/O manager-supplied device queue in the 
device object. The driver runs at IRQL = DISPATCH_LEVEL after calling 
IoAcquireCancelSpinLock until it releases the cancel spin lock with 
IoReleaseCancelSpinLock."

[1] 
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-iosetcancelroutine

I understand the "I/O manager-supplied device queue in the device 
object" is the "KDEVICE_QUEUE DeviceQueue" member that I wanted to use 
with these functions instead of re-implementing a queue and a lock again.

>> +
>> +static void test_queue(void)
>> +{
>> +    KDEVICE_QUEUE_ENTRY *entry;
>> +    KDEVICE_QUEUE queue;
>> +    BOOLEAN ret;
>> +    KIRQL irql;
>> +    IRP *irp;
>> +
>> +    irp = IoAllocateIrp(1, FALSE);
>> +
>> +    memset(&queue, 0xcd, sizeof(queue));
>> +    KeInitializeDeviceQueue(&queue);
>> +    ok(!queue.Busy, "unexpected Busy state\n");
>> +    ok(queue.Size == sizeof(queue), "unexpected Size %x\n", queue.Size);
>> +    ok(queue.Type == IO_TYPE_DEVICE_QUEUE, "unexpected Type %x\n", 
>> queue.Type);
> 
> Could we test the actual contents of the queue list after all these calls?
> 

I guess. It's hopefully going to be empty?
-- 
Rémi Bernon <rbernon at codeweavers.com>