> You should only call `NtGetCurrentProcessorNumber()` once. Otherwise, the processor number can change if the thread is preempted and then re-scheduled to another processor. This leads to inconsistent values between the return value and the `process_number->Number` output.
It's not that `KeGetCurrentProcessorNumberEx()` will be highly useful, since the driver can't block scheduling by raising IRQL to DISPATCH_LEVEL. Still, it's better to at least return consistent values even if they are stale.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/824#note_8782
Jinoh Kang (@iamahuman) commented about dlls/ntoskrnl.exe/ntoskrnl.c:
>
> +/***********************************************************************
> + * KeGetCurrentProcessorNumberEx (NTOSKRNL.EXE.@)
> + */
> +ULONG WINAPI KeGetCurrentProcessorNumberEx(PPROCESSOR_NUMBER process_number)
> +{
> + FIXME("%p semi-stub\n", process_number);
> +
> + if (process_number)
> + {
> + process_number->Group = 0;
> + process_number->Reserved = 0;
> + process_number->Number = NtGetCurrentProcessorNumber();
> + }
> +
> + return NtGetCurrentProcessorNumber();
You should only call `NtGetCurrentProcessorNumber()` once. Otherwise, the processor number can change if the thread is preempted and then re-scheduled to another processor. This leads to inconsistent values between the return value and the `process_number->Number` output.
In general, you should treat `NtGetCurrentProcessorNumber()` as being volatile.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/824#note_8781
Enforce proper atomic update so that other threads do not read stale
data from IO_STATUS_BLOCK.
Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com>
--
v5: ntdll: Fix reading stale Information from IOSB.
https://gitlab.winehq.org/wine/wine/-/merge_requests/155
Enforce proper atomic update so that other threads do not read stale
data from IO_STATUS_BLOCK.
Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com>
--
v4: ntdll: Fix reading stale Information from IOSB.
https://gitlab.winehq.org/wine/wine/-/merge_requests/155
When initializing a jsstr_inline_t with a len < 3, the size passed
for the allocation is smaller then the size of the structure
(as the later is rounded up to the alignment = 4 bytes).
GCC 12.2 complains about this when dereferencing the pointer to
the structure as the size passed for allocation is smaller than the
size of the structure.
The warning is fixed by using flexible array member in
jsstr_inline_t. Given the rounding behavior in memory allocation, this
should not change the size of allocated blocks.
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/876