Hey,
Den 2025-10-24 kl. 10:39, skrev Johannes Berg:
On Fri, 2025-10-24 at 10:37 +0200, Maarten Lankhorst wrote:
CPU 0 CPU 1
dev_coredump_put() devcd_del() -> devcd_free() -> locked -> !deleted -> __devcd_del() -> __devcd_del()
no?
johannes
Yeah don't you love the races in the design? All intricate and subtle.
:)
In this case it's handled by disable_delayed_work_sync(), which waits for devcd_del() to be completed. devcd_del is called from the workqueue, and the first step devcd_free does is calling disable_delayed_work_sync, which means devcd_del() either fully completed or was not run at all.
Oh... right, I totally missed the _sync. My bad, sorry.
I guess I really should say
Reviewed-by: Johannes Berg johannes@sipsolutions.net
since I finally _did_ review it carefully. Sorry it took forever.
johannes
No worries. It's an extremely tricky and prone to races part of code especially with the various ways a coredump can be destroyed.
I almost replied with another potential bug, calling read() after calling write(), but that's worked around by the reference kept on the devcd device.
Kind regards, ~Maarten Lankhorst