All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Nicholas Mc Guire <hofrat@osadl.org>
Cc: David Airlie <airlied@linux.ie>,
	linux-kernel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,
	dri-devel@lists.freedesktop.org, "Andrew F. Davis" <afd@ti.com>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>
Subject: Re: [PATCH] drm/omap: dss: do not allow devm_kasprintf() to fail
Date: Fri, 23 Nov 2018 16:39:59 +0200	[thread overview]
Message-ID: <3550363.0Jm6vJdJjr@avalon> (raw)
In-Reply-To: <1542974495-12387-1-git-send-email-hofrat@osadl.org>

Hello Nicholas,

On Friday, 23 November 2018 14:01:35 EET Nicholas Mc Guire wrote:
> omapdss_display_init() is called by multiple drivers and does not expect
> a return value so without changing all call-sites the low-probability
> failure of devm_kasprintf() can not be reported up the call stack. As
> the amount allocated here is very small (<= 16 bytes) and it is an
> initialization function that most likely will be called during system
> initialization it should be OK to use __GFP_NOFAIL here to prevent
> devm_kasprintf() from returning NULL.
> 
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> Fixes: 36c61ae2b755 ("drm/omap: dss: Remove display ordering from
> dss/display.c")
> ---
> 
> Problem located with experimental coccinelle script
> 
> While the use of __GFP_NOFAIL is to be limited (small infrequent
> allocations) this case does seems suitable as it is rare and small
> (initialization) .As all the current drivers using
> omapdss_display_init() currently seem not to initialize dssdev->name
> prior to calling omapdss_display_init() and the unlikely failure
> case can not be reasonably responded (returns void) not allowing
> a allocation failure here should be acceptable.

Given that my plan is to eventually drop omapdss_display_init(), this looks 
fine to me.

Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> Patch was compile tested with: omap2plus_defconfig (implies OMAP_DSS_BASE=m)
> 
> Patch is against 4.20-rc3 (localversion-next is next-20181123)
> 
>  drivers/gpu/drm/omapdrm/dss/display.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/display.c
> b/drivers/gpu/drm/omapdrm/dss/display.c index 34b2a4e..7dbe874 100644
> --- a/drivers/gpu/drm/omapdrm/dss/display.c
> +++ b/drivers/gpu/drm/omapdrm/dss/display.c
> @@ -45,7 +45,8 @@ void omapdss_display_init(struct omap_dss_device *dssdev)
>  	of_property_read_string(dssdev->dev->of_node, "label", &dssdev->name);
> 
>  	if (dssdev->name == NULL)
> -		dssdev->name = devm_kasprintf(dssdev->dev, GFP_KERNEL,
> +		dssdev->name = devm_kasprintf(dssdev->dev,
> +					      GFP_KERNEL | __GFP_NOFAIL,
>  					      "display%u", id);
>  }
>  EXPORT_SYMBOL_GPL(omapdss_display_init);

-- 
Regards,

Laurent Pinchart



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Nicholas Mc Guire <hofrat@osadl.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>,
	David Airlie <airlied@linux.ie>,
	Sebastian Reichel <sre@kernel.org>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	"Andrew F. Davis" <afd@ti.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/omap: dss: do not allow devm_kasprintf() to fail
Date: Fri, 23 Nov 2018 16:39:59 +0200	[thread overview]
Message-ID: <3550363.0Jm6vJdJjr@avalon> (raw)
In-Reply-To: <1542974495-12387-1-git-send-email-hofrat@osadl.org>

Hello Nicholas,

On Friday, 23 November 2018 14:01:35 EET Nicholas Mc Guire wrote:
> omapdss_display_init() is called by multiple drivers and does not expect
> a return value so without changing all call-sites the low-probability
> failure of devm_kasprintf() can not be reported up the call stack. As
> the amount allocated here is very small (<= 16 bytes) and it is an
> initialization function that most likely will be called during system
> initialization it should be OK to use __GFP_NOFAIL here to prevent
> devm_kasprintf() from returning NULL.
> 
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> Fixes: 36c61ae2b755 ("drm/omap: dss: Remove display ordering from
> dss/display.c")
> ---
> 
> Problem located with experimental coccinelle script
> 
> While the use of __GFP_NOFAIL is to be limited (small infrequent
> allocations) this case does seems suitable as it is rare and small
> (initialization) .As all the current drivers using
> omapdss_display_init() currently seem not to initialize dssdev->name
> prior to calling omapdss_display_init() and the unlikely failure
> case can not be reasonably responded (returns void) not allowing
> a allocation failure here should be acceptable.

Given that my plan is to eventually drop omapdss_display_init(), this looks 
fine to me.

Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> Patch was compile tested with: omap2plus_defconfig (implies OMAP_DSS_BASE=m)
> 
> Patch is against 4.20-rc3 (localversion-next is next-20181123)
> 
>  drivers/gpu/drm/omapdrm/dss/display.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/display.c
> b/drivers/gpu/drm/omapdrm/dss/display.c index 34b2a4e..7dbe874 100644
> --- a/drivers/gpu/drm/omapdrm/dss/display.c
> +++ b/drivers/gpu/drm/omapdrm/dss/display.c
> @@ -45,7 +45,8 @@ void omapdss_display_init(struct omap_dss_device *dssdev)
>  	of_property_read_string(dssdev->dev->of_node, "label", &dssdev->name);
> 
>  	if (dssdev->name == NULL)
> -		dssdev->name = devm_kasprintf(dssdev->dev, GFP_KERNEL,
> +		dssdev->name = devm_kasprintf(dssdev->dev,
> +					      GFP_KERNEL | __GFP_NOFAIL,
>  					      "display%u", id);
>  }
>  EXPORT_SYMBOL_GPL(omapdss_display_init);

-- 
Regards,

Laurent Pinchart




  reply	other threads:[~2018-11-23 14:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-23 12:01 [PATCH] drm/omap: dss: do not allow devm_kasprintf() to fail Nicholas Mc Guire
2018-11-23 14:39 ` Laurent Pinchart [this message]
2018-11-23 14:39   ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3550363.0Jm6vJdJjr@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=afd@ti.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hofrat@osadl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter.ujfalusi@ti.com \
    --cc=sre@kernel.org \
    --cc=tomi.valkeinen@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.