Paul Kocialkowski <[email protected]> writes: > Since the OOM interrupt directly deals with the binner bo, it doesn't > make sense to try and handle it without a binner buffer registered. > > Signed-off-by: Paul Kocialkowski <[email protected]> > --- > drivers/gpu/drm/vc4/vc4_irq.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c > index ffd0a4388752..723dc86b4511 100644 > --- a/drivers/gpu/drm/vc4/vc4_irq.c > +++ b/drivers/gpu/drm/vc4/vc4_irq.c > @@ -64,6 +64,9 @@ vc4_overflow_mem_work(struct work_struct *work) > struct vc4_exec_info *exec; > unsigned long irqflags; > > + if (!bo) > + return; > + > bin_bo_slot = vc4_v3d_get_bin_slot(vc4); > if (bin_bo_slot < 0) { > DRM_ERROR("Couldn't allocate binner overflow mem\n"); > -- > 2.21.0
I don't think this is going to be race-free. You're checking outside of a lock, then proceeding to use it even if (in patch 4) the bin BO was in the process of being freed during the file close path. Can we put all of the overflow process here under the same lock as freeing?
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
