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@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-ios...
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?