Hi Christian,
Aha, thanks, that explains it. Then the KCSAN report must be false positive.
Kind regards,
Mirsad
On 8/25/23 09:05, Christian König wrote:
Hi Mirsad,
the name SPSC stands for SingleProducerSingleConsumer, so yes even by the name
of the component we make it clear that this can only be used by one producer
and one consumer thread at the same time.
Here disabling preemption is just done so that the consumer thread doesn't busy
loop for the producer thread to be scheduled in again.
Regards,
Christian.
Am 24.08.23 um 19:46 schrieb Mirsad Goran Todorovac:
Thank you, Christian.
Glad to hear about that.
However, I guess this assumes that this piece of code between
-----<>-----
preempt_disable();
tail = (struct spsc_node **)atomic_long_xchg(&queue->tail,
(long)&node->next);
WRITE_ONCE(*tail, node);
atomic_inc(&queue->job_count);
/*
* In case of first element verify new node will be visible to the consumer
* thread when we ping the kernel thread that there is new work to do.
*/
smp_wmb();
preempt_enable();
-----<>-----
... executes only on one CPU/core/thread?
I understood that preempt_disable() disables only interrupts on one core/CPU:
https://kernelnewbies.kernelnewbies.narkive.com/6LTlgsAe/preempt-disable-disables-preemption-on-all-processors
So, we might have a race in theory between WRITE_ONCE() and atomic_inc().
Kind regards,
Mirsad
On 8/21/2023 8:22 PM, Christian König wrote:
I'm not sure about that.
On the one hand it might generate some noise. I know tons of cases where logic
is: Ok if we see the updated value immediately it will optimize things, but if
not it's unproblematic because there is another check after the next memory
barrier.
On the other hand we probably have cases where this is not correctly
implemented. So double checking those would most like be good idea.
Regards,
Christian.
Am 21.08.23 um 16:28 schrieb Mirsad Todorovac:
Hi Christian,
Thank you for the update.
Should I continue reporting what KCSAN gives? I will try to filter these to
save your time for
evaluation ...
Kind regards,
Mirsad
On 8/21/23 15:20, Christian König wrote:
Hi Mirsad,
well this is a false positive.
That drm_sched_entity_is_ready() doesn't see the data written by
drm_sched_entity_push_job() is part of the logic here.
Regards,
Christian.
Am 18.08.23 um 15:44 schrieb Mirsad Todorovac:
On 8/17/23 21:54, Mirsad Todorovac wrote:
Hi,
This is your friendly bug reporter.
The environment is vanilla torvalds tree kernel on Ubuntu 22.04 LTS and a Ryzen
7950X box.
Please find attached the complete dmesg output from the ring buffer and lshw
output.
NOTE: The kernel reports tainted kernel, but to my knowledge there are no
proprietary (G) modules,
but this taint is turned on by the previous bugs.
dmesg excerpt:
[ 8791.864576]
==================================================================
[ 8791.864648] BUG: KCSAN: data-race in drm_sched_entity_is_ready [gpu_sched] /
drm_sched_entity_push_job [gpu_sched]
[ 8791.864776] write (marked) to 0xffff9b74491b7c40 of 8 bytes by task 3807 on
cpu 18:
[ 8791.864788] drm_sched_entity_push_job+0xf4/0x2a0 [gpu_sched]
[ 8791.864852] amdgpu_cs_ioctl+0x3888/0x3de0 [amdgpu]
[ 8791.868731] drm_ioctl_kernel+0x127/0x210 [drm]
[ 8791.869222] drm_ioctl+0x38f/0x6f0 [drm]
[ 8791.869711] amdgpu_drm_ioctl+0x7e/0xe0 [amdgpu]
[ 8791.873660] __x64_sys_ioctl+0xd2/0x120
[ 8791.873676] do_syscall_64+0x58/0x90
[ 8791.873688] entry_SYSCALL_64_after_hwframe+0x73/0xdd
[ 8791.873710] read to 0xffff9b74491b7c40 of 8 bytes by task 1119 on cpu 27:
[ 8791.873722] drm_sched_entity_is_ready+0x16/0x50 [gpu_sched]
[ 8791.873786] drm_sched_select_entity+0x1c7/0x220 [gpu_sched]
[ 8791.873849] drm_sched_main+0xd2/0x500 [gpu_sched]
[ 8791.873912] kthread+0x18b/0x1d0
[ 8791.873924] ret_from_fork+0x43/0x70
[ 8791.873939] ret_from_fork_asm+0x1b/0x30
[ 8791.873955] value changed: 0x0000000000000000 -> 0xffff9b750ebcfc00
[ 8791.873971] Reported by Kernel Concurrency Sanitizer on:
[ 8791.873980] CPU: 27 PID: 1119 Comm: gfx_0.0.0 Tainted: G L
6.5.0-rc6-net-cfg-kcsan-00038-g16931859a650 #35
[ 8791.873994] Hardware name: ASRock X670E PG Lightning/X670E PG Lightning,
BIOS 1.21 04/26/2023
[ 8791.874002]
==================================================================
P.S.
According to Mr. Heo's instructions, I am adding the unwound trace here:
[ 1879.706518]
==================================================================
[ 1879.706616] BUG: KCSAN: data-race in drm_sched_entity_is_ready [gpu_sched] /
drm_sched_entity_push_job [gpu_sched]
[ 1879.706737] write (marked) to 0xffff8f3672748c40 of 8 bytes by task 4087 on
cpu 10:
[ 1879.706748] drm_sched_entity_push_job (./include/drm/spsc_queue.h:74
drivers/gpu/drm/scheduler/sched_entity.c:574) gpu_sched
[ 1879.706808] amdgpu_cs_ioctl (drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1375
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1469) amdgpu
[ 1879.710589] drm_ioctl_kernel (drivers/gpu/drm/drm_ioctl.c:788) drm
[ 1879.711068] drm_ioctl (drivers/gpu/drm/drm_ioctl.c:892) drm
[ 1879.711551] amdgpu_drm_ioctl (drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:2748)
amdgpu
[ 1879.715319] __x64_sys_ioctl (fs/ioctl.c:51 fs/ioctl.c:870 fs/ioctl.c:856
fs/ioctl.c:856)
[ 1879.715334] do_syscall_64 (arch/x86/entry/common.c:50
arch/x86/entry/common.c:80)
[ 1879.715345] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
[ 1879.715365] read to 0xffff8f3672748c40 of 8 bytes by task 1098 on cpu 11:
[ 1879.715376] drm_sched_entity_is_ready
(drivers/gpu/drm/scheduler/sched_entity.c:134) gpu_sched
[ 1879.715435] drm_sched_select_entity
(drivers/gpu/drm/scheduler/sched_main.c:248
drivers/gpu/drm/scheduler/sched_main.c:893) gpu_sched
[ 1879.715495] drm_sched_main (drivers/gpu/drm/scheduler/sched_main.c:1019)
gpu_sched
[ 1879.715554] kthread (kernel/kthread.c:389)
[ 1879.715563] ret_from_fork (arch/x86/kernel/process.c:145)
[ 1879.715575] ret_from_fork_asm (arch/x86/entry/entry_64.S:312)
[ 1879.715590] value changed: 0x0000000000000000 -> 0xffff8f360663dc00
[ 1879.715604] Reported by Kernel Concurrency Sanitizer on:
[ 1879.715612] CPU: 11 PID: 1098 Comm: gfx_0.0.0 Tainted: G L
6.5.0-rc6+ #47
[ 1879.715624] Hardware name: ASRock X670E PG Lightning/X670E PG Lightning,
BIOS 1.21 04/26/2023
[ 1879.715631]
==================================================================
It seems that the line in question might be:
first = spsc_queue_push(&entity->job_queue, &sched_job->queue_node);
which expands to:
static inline bool spsc_queue_push(struct spsc_queue *queue, struct spsc_node
*node)
{
struct spsc_node **tail;
node->next = NULL;
preempt_disable();
tail = (struct spsc_node **)atomic_long_xchg(&queue->tail,
(long)&node->next);
WRITE_ONCE(*tail, node);
atomic_inc(&queue->job_count);
/*
* In case of first element verify new node will be visible to the consumer
* thread when we ping the kernel thread that there is new work to do.
*/
smp_wmb();
preempt_enable();
return tail == &queue->head;
}
According to the manual, preempt_disable() only guaranteed exclusion on a
single CPU/core/thread, so
we might be plagued with the slow, old fashioned locking unless anyone had a
better idea.
Best regards,
Mirsad Todorovac
