06:54 dolphin: daniels: Do we have a process for AI slop security reports? https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15882
06:57 dolphin: (More details at: https://lists.freedesktop.org/archives/intel-gfx/2026-March/388178.html)
07:44 dolphin: airlied, sima: drm-intel-fixes PR sent
08:25 sima: 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:26 sima: 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:27 sima: 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:27 sima: or "devm_kmalloc considered harmful"
08:28 sima: and at least the current design we have is that we pile everything up on top of the one drm_device refcount
08:29 sima: 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:30 sima: or "hey your changing calling context of fb cleanup, this needs to be consistent everywhere and needs driver consensus and updated kerneldoc"
08:31 sima: 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:32 sima: at least for api-usage details it should be able to infer important rules
08:35 sima: 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:07 mlankhorst: 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