On Thu, Jan 30, 2020 at 01:51:36PM +0000, Chris Wilson wrote: > Avoid releasing the same stolen nodes causing a use-after-free and/or > explosions as the self-checks fail, as __intel_fbc_cleanup_cfb() may be > called multiple times during module unload. > > Signed-off-by: Chris Wilson <[email protected]> > Cc: Ville Syrjälä <[email protected]> > --- > drivers/gpu/drm/i915/display/intel_fbc.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c > b/drivers/gpu/drm/i915/display/intel_fbc.c > index 2a3f1333c8ff..ab676c6756af 100644 > --- a/drivers/gpu/drm/i915/display/intel_fbc.c > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c > @@ -537,13 +537,15 @@ static void __intel_fbc_cleanup_cfb(struct > drm_i915_private *dev_priv) > { > struct intel_fbc *fbc = &dev_priv->fbc; > > - if (drm_mm_node_allocated(&fbc->compressed_fb)) > - i915_gem_stolen_remove_node(dev_priv, &fbc->compressed_fb); > + if (!drm_mm_node_allocated(&fbc->compressed_fb)) > + return; > > if (fbc->compressed_llb) { > i915_gem_stolen_remove_node(dev_priv, fbc->compressed_llb); > kfree(fbc->compressed_llb); > }
Had to double check that we don't have some funny cases where we have the llb allocated without the cfb. And leaving the stale pointer behind doesn't seem like it can cause any other issues. Reviewed-by: Ville Syrjälä <[email protected]> > + > + i915_gem_stolen_remove_node(dev_priv, &fbc->compressed_fb); > } > > void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv) > -- > 2.25.0 -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
