Messages in this thread | | | Date | Wed, 22 Feb 2023 10:34:42 +0100 | From | Peter Zijlstra <> | Subject | Re: [syzbot] WARNING: locking bug in umh_complete |
| |
On Tue, Feb 14, 2023 at 10:31:58AM +0800, Schspa Shi wrote: > Peter Zijlstra <peterz@infradead.org> writes:
> > If so, perhaps the simplest rule would to be ensure there is an > > unconditional uninterruptible wait-for-completion() before going out of > > scope. > > > > This latter can be spelled like wait_for_completion() or > > wait_for_completion_state(TASK_UNINTERRUPTIBLE). More specifically, > > TASK_INTERRUPTIBLE and TASK_WAKEKILL must not be set in the state mask > > for the wait to be uninterruptible. > > > > If it cannot be proven, raise a warning and audit or somesuch. > > This is a good suggestion. I have written a SmPL patch to complete this > check, and now I need to rule out the situation that the driver has > added an additional lock to protect it. > > And I have found a lot of bad usage, should we consider adding a new > helper API to simplify the fix this?
Please first share some of the locations where this would be applied.
| |