Dzień dobry,
czy jest możliwość, by na pewien czas Państwa zakład produkcyjny mógł zrezygnować z części lub całości zużywanej energii?
W zamian za gotowość do redukcji i jej wykonanie mogą otrzymać Państwo stałe wynagrodzenie, które w przeliczeniu na 1 MW redukcji mocy wynosi od 500 do 720 tys. zł w zależności od czasu zdolności do redukcji.
Uczestnictwo w programie DSR (Demand Side Response) to dla Państwa brak kosztów implementacji i wzrost bezpieczeństwa energetycznego.
Jeśli interesuje Państwa generowanie wieloletnich przychodów z programu DSR, proszę o wiadomość.
Pozdrawiam
Dawid Jarocki
Hi all,
This is v2 to the linked patch series; thanks to everyone for reviewing
the initial version. I've moved this out of a pure DRM scope and into
the general userspace-API design section. Hopefully it helps others and
answers a bunch of questions.
I think it'd be great to have input/links/reflections from other
subsystems as well here.
Cheers,
Daniel
From: Rob Clark <robdclark(a)chromium.org>
If a signal callback releases the sw_sync fence, that will trigger a
deadlock as the timeline_fence_release recurses onto the fence->lock
(used both for signaling and the the timeline tree).
To avoid that, temporarily hold an extra reference to the signalled
fences until after we drop the lock.
(This is an alternative implementation of https://patchwork.kernel.org/patch/11664717/
which avoids some potential UAF issues with the original patch.)
v2: Remove now obsolete comment, use list_move_tail() and
list_del_init()
Reported-by: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl>
Fixes: d3c6dd1fb30d ("dma-buf/sw_sync: Synchronize signal vs syncpt free")
Signed-off-by: Rob Clark <robdclark(a)chromium.org>
---
drivers/dma-buf/sw_sync.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 63f0aeb66db6..f0a35277fd84 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -191,6 +191,7 @@ static const struct dma_fence_ops timeline_fence_ops = {
*/
static void sync_timeline_signal(struct sync_timeline *obj, unsigned int inc)
{
+ LIST_HEAD(signalled);
struct sync_pt *pt, *next;
trace_sync_timeline(obj);
@@ -203,21 +204,20 @@ static void sync_timeline_signal(struct sync_timeline *obj, unsigned int inc)
if (!timeline_fence_signaled(&pt->base))
break;
- list_del_init(&pt->link);
+ dma_fence_get(&pt->base);
+
+ list_move_tail(&pt->link, &signalled);
rb_erase(&pt->node, &obj->pt_tree);
- /*
- * A signal callback may release the last reference to this
- * fence, causing it to be freed. That operation has to be
- * last to avoid a use after free inside this loop, and must
- * be after we remove the fence from the timeline in order to
- * prevent deadlocking on timeline->lock inside
- * timeline_fence_release().
- */
dma_fence_signal_locked(&pt->base);
}
spin_unlock_irq(&obj->lock);
+
+ list_for_each_entry_safe(pt, next, &signalled, link) {
+ list_del_init(&pt->link);
+ dma_fence_put(&pt->base);
+ }
}
/**
--
2.41.0
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] ==================================================================
Best regards,
Mirsad Todorovac
Documentation for drm_crtc_init_with_planes() in
drivers/gpu/drm/drm_crtc.c states: «The crtc structure should not be
allocated with devm_kzalloc()».
However, in drivers/gpu/drm/stm/ltdc.c
the 2nd argument of the function drm_crtc_init_with_planes()
is a structure allocated with devm_kzalloc()
Also, in
drivers/gpu/drm/mediatek/mtk_drm_crtc.c
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
drivers/gpu/drm/logicvc/logicvc_crtc.c
drivers/gpu/drm/meson/meson_crtc.c
drivers/gpu/drm/mxsfb/lcdif_kms.c
drivers/gpu/drm/mxsfb/mxsfb_kms.c
drivers/gpu/drm/renesas/shmobile/shmob_drm_crtc.c
drivers/gpu/drm/rockchip/rockchip_drm_vop.c
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
drivers/gpu/drm/sun4i/sun4i_crtc.c
drivers/gpu/drm/tegra/dc.c
drivers/gpu/drm/tilcdc/tilcdc_crtc.c
the 2nd argument of the function drm_crtc_init_with_planes()
is a field of the structure allocated with devm_kzalloc()
Is it correct or can it lead to any problems?
--
Ekaterina Orlova
Linux Verification Center, ISPRAS