[PATCH 20/51] drm: Handle dev->unique with drmm_

Daniel Vetter daniel at ffwll.ch
Mon Mar 23 10:54:48 UTC 2020


On Fri, Mar 06, 2020 at 09:37:10PM +0100, Sam Ravnborg wrote:
> On Mon, Mar 02, 2020 at 11:26:00PM +0100, Daniel Vetter wrote:
> > We need to add a drmm_kstrdup for this, but let's start somewhere.
> > 
> > This is not exactly perfect onion unwinding, but it's jsut a kfree so
> > doesn't really matter at all.
> > 
> > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> 
> Reluctanlyt... But anyway
> Reviewed-by: Sam Ravnborg <sam at ravnborg.org>
> 
> See below for a few comments.
> 
> 
> > ---
> >  drivers/gpu/drm/drm_drv.c     |  5 ++---
> >  drivers/gpu/drm/drm_managed.c | 16 ++++++++++++++++
> >  include/drm/drm_managed.h     |  1 +
> >  3 files changed, 19 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 1a048325f30e..ef79c03e311c 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -777,7 +777,6 @@ void drm_dev_fini(struct drm_device *dev)
> >  	mutex_destroy(&dev->filelist_mutex);
> >  	mutex_destroy(&dev->struct_mutex);
> >  	drm_legacy_destroy_members(dev);
> > -	kfree(dev->unique);
> >  }
> >  EXPORT_SYMBOL(drm_dev_fini);
> >  
> > @@ -1068,8 +1067,8 @@ EXPORT_SYMBOL(drm_dev_unregister);
> >   */
> >  int drm_dev_set_unique(struct drm_device *dev, const char *name)
> >  {
> > -	kfree(dev->unique);
> > -	dev->unique = kstrdup(name, GFP_KERNEL);
> > +	drmm_kfree(dev, dev->unique);
> > +	dev->unique = drmm_kstrdup(dev, name, GFP_KERNEL);
> >  
> >  	return dev->unique ? 0 : -ENOMEM;
> >  }
> > diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
> > index 57dc79fa90af..514d5bd42446 100644
> > --- a/drivers/gpu/drm/drm_managed.c
> > +++ b/drivers/gpu/drm/drm_managed.c
> > @@ -160,6 +160,22 @@ void *drmm_kmalloc(struct drm_device *dev, size_t size, gfp_t gfp)
> >  }
> >  EXPORT_SYMBOL(drmm_kmalloc);
> >  
> > +char *drmm_kstrdup(struct drm_device *dev, const char *s, gfp_t gfp)
> 
> So we need this gfp for all users - just because i915 is special and
> uses "GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN" in to places -
> sigh.

Nope, that's not the reason. That NOWARN is not in a driver load path, so
won't ever get converted to drmm_.

Sole reason for adding gfp_flags is consisteny with everything else -
devm_ also has them (and I'd question anyone who does stuff like
GFP_ATOMIC in their driver load path). I guess you can make a case that
some memory allocation functions shouldn't have a gfp_flags parameter
because the only thing you can use that for is create bugs (everyone
should set GFP_KERNEL, maybe with the GFP_ZERO flag set on top). But not
really what I'm aiming for in this series :-)

Hope that explains why I'm sticking with this here.
-Daniel

> 
> 
> 
> > +{
> > +	size_t size;
> > +	char *buf;
> > +
> > +	if (!s)
> > +		return NULL;
> > +
> > +	size = strlen(s) + 1;
> > +	buf = drmm_kmalloc(dev, size, gfp);
> > +	if (buf)
> > +		memcpy(buf, s, size);
> > +	return buf;
> > +}
> > +EXPORT_SYMBOL_GPL(drmm_kstrdup);
> > +
> >  void drmm_kfree(struct drm_device *dev, void *data)
> >  {
> >  	struct drmres *dr_match = NULL, *dr;
> > diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h
> > index 7b5df7d09b19..89e6fce9f689 100644
> > --- a/include/drm/drm_managed.h
> > +++ b/include/drm/drm_managed.h
> > @@ -24,6 +24,7 @@ static inline void *drmm_kzalloc(struct drm_device *dev, size_t size, gfp_t gfp)
> >  {
> >  	return drmm_kmalloc(dev, size, gfp | __GFP_ZERO);
> >  }
> > +char *drmm_kstrdup(struct drm_device *dev, const char *s, gfp_t gfp);
> Missing empty line above. But it is fixed later IIRC
> 
> >  
> >  void drmm_kfree(struct drm_device *dev, void *data);
> >  
> > -- 
> > 2.24.1
> > 
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list