[Intel-gfx] [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 Intel-gfx
mailing list