search for: wq_max_active

Using the kernel global workqueue to signal fences can lead to unexpected deadlocks. Some other work (e.g. from a different driver) could directly or indirectly depend on this fence to be signaled. However, if the WQ_MAX_ACTIVE limit is reached by waiters, this can prevent the work signaling the fence from running. While this seems fairly unlikely, it's potentially exploitable. Fixes: 39126abc5e20 ("nouveau: offload fence uevents work to workqueue") Signed-off-by: Danilo Krummrich <dakr at redhat.com&gt...

...h <dakr at redhat.com> wrote: > > > > Using the kernel global workqueue to signal fences can lead to > > unexpected deadlocks. Some other work (e.g. from a different driver) > > could directly or indirectly depend on this fence to be signaled. > > However, if the WQ_MAX_ACTIVE limit is reached by waiters, this can > > prevent the work signaling the fence from running. > > > > While this seems fairly unlikely, it's potentially exploitable. > > LGTM > > Reviewed-by: Dave Airlie <airlied at redhat.com> > > probably should go...

...t; > drivers / kernel code that, by chance, makes use of the kernel global wq as > > > > > > > well. > > > > > > > > > > > > > > Admittedly, even if, it's gonna be extremely unlikely given that > > > > > > > WQ_MAX_ACTIVE == 512. But maybe it'd be safer to use a dedicated wq. > > > > > > > > > > > > > > Also, do we need to CC stable? > > > > > > > > > > > > I pushed this to Linus at the end of last week, since the hangs in 6.7 > &...