On Thu, Oct 19 2023 at 12:31, Andrzej Hajda wrote: > On 13.10.2023 15:15, Thomas Gleixner wrote: >> It cannot be freed. If that happens then the calling code will have an >> UAF problem on the tracked item too. > > Yes, and I have assumed that debugobjects are created also for detecting > UAFs. Kinda. > They should be able to handle/detect 'issues due to incorrectly > serialized concurrent accesses' scenarios as well, at least some of > them. And even if it cannot recover it should at least provide reliable > reporting. Fair enough. > Now we can have scenario: > 1. Thread tries to deactivate destroyed object, debugobjects detects it, > spin lock is released, thread is preempted. > 2. Other thread frees debugobject, then allocates new one on the same > memory location, ie 'obj' variable from 1st thread point to it - it is > possible because there is no locking. > 3. Then preemption occurs, and 1st thread reports error for wrong object. > > This seems the most drastic for me, but also with lowest chances to > happen due to delayed freeing, but there are also other more probable > scenarios when we print the same object but in state different from the > one when debugobject detected issue, due to modification by concurrent > thread. Now I understand what you mean. This information should be in the changelog, no? Let me stare at the patch once more.
