Messages in this thread | | | Date | Thu, 13 Dec 2018 18:00:27 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH] debugobjects: Move printk out of db lock critical sections |
| |
On (12/13/18 05:54), Dmitry Safonov wrote: > > I thought about it for a second, but couldn't figure out if this race > > was real. > > > > E.g. uart case - if there are two paths which concurrently free and > > access debug object, then the same race condition should exist for > > the xmit.buf page. debug object's lifespan should be the same as the > > lifespan of, ummm, whatever the thing that debug object is attached > > to? I'm surely missing something here. > > I think the point of debugobjects is to reduce the damage caused > by an improper life-time of objects. > > IIUC: > 1. alloc_page() > 2. dynamically allocate a workqueue on a new page > 3. schedule some work > 4. until the work has run free_page()
Hmm, if we free() that page then __debug_check_no_obj_freed() should ->fixup all ODEBUG_STATE_ACTIVE objects first. Maybe we are talking about different scenarios.
-ss
| |