Quoting Thomas Gleixner (2021-09-19 05:41:18) > > Again, it cannot do that from a softirq because > synchronize_rcu_expedited() might sleep. > > > Is it possible that object_is_on_stack() doesn't work in IRQ context? > > I'm not really following along on x86 but I could see where > > task_stack_page() gets the wrong "stack" pointer because the task has one > > stack and the irq stack is some per-cpu dedicated allocation? > > Even if debug objects would support objects on irq stacks, the above is > still bogus. But it does not and will not because the operations here > have to be fully synchronous: > > init() -> queue() or arm() -> wait() -> destroy() > > because you obviously cannot queue work or arm a timer which are on stack > and then leave the function without waiting for the operation to complete. Is there some way to make it more obvious that initializing a timer or work on the stack in an irq context is a NONO because we can't wait for it? Maybe some sort of debugobjects call to might_sleep() when it's being told the object is on the stack, or throwing a might_sleep() into the initialization of any stack based timer or workqueue, or both? > > So these operations have to be synchronous which is a NONO when running > in hard or soft interrupt context because waiting for the operation to > complete is not possible there. >
