06:54dolphin: daniels: Do we have a process for AI slop security reports? https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15882 06:57dolphin: (More details at: https://lists.freedesktop.org/archives/intel-gfx/2026-March/388178.html) 07:44dolphin: airlied, sima: drm-intel-fixes PR sent
08:25sima: Company, airlied I think unless it would have read&understood all the m-l discussions the past few years probably no way, because not even the kerneldoc spells out the common pattern in how drivers tend to be buggy
08:26sima: there's some FIXME in there though that I think should have at least humans started wondering about the bigger context of this entire area
08:27sima: mlankhorst, maybe follow-up rule of thumb for use-after-free on hotunplug: unless the memory is refcounted like for devm_drm_dev_alloc it's generally a bug if you free memory from devm/hotunplug/remove
08:27sima: or "devm_kmalloc considered harmful"
08:28sima: and at least the current design we have is that we pile everything up on top of the one drm_device refcount
08:29sima: airlied, I think the generated one is surprisingly good, but it misses even super-basic big picture stuff like "hey don't put two bugfixes into one patch"
08:30sima: or "hey your changing calling context of fb cleanup, this needs to be consistent everywhere and needs driver consensus and updated kerneldoc"
08:31sima: I do wonder whether clear instructions to chase down kerneldoc plus trying to improve that would actually net us much improved kerneldoc as a side benefit of lighting up all that vc cash and boiling all that water
08:32sima: at least for api-usage details it should be able to infer important rules
08:35sima: the stuff in there at least looks like it's stuck at "I've read the functions you're calling" and not anything more in-depth
10:07mlankhorst: Yeah it came from the wrong assumption that since I touched the display code for xe, we've mostly been able to beat constructors/destructors into a well-behaving shape