On Fri, Nov 04, 2016 at 11:32:45AM -0400, Rob Clark wrote:
> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>
> drm: make drm_get_format_name thread-safe
>
> Signed-off-by: Eric Engestrom <eric@xxxxxxxxxxxx>
> [danvet: Clarify that the returned pointer must be freed with
> kfree().]
> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
>
> Note: I think we need to be a bit careful about follow-up audits of
> callers of this.. now that you need to kfree the return value I think
> it is fairly easy for new patches to introduce new callers which leak
> the return value. We probably should have left the function as-is and
> introduce a new variant, or something like that.
>
> Signed-off-by: Rob Clark <robdclark@xxxxxxxxx>
> ---
> drivers/gpu/drm/drm_fourcc.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index cbb8b77..2be9ea8 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -87,7 +87,10 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format);
> */
> char *drm_get_format_name(uint32_t format)
> {
> - char *buf = kmalloc(32, GFP_KERNEL);
> + char *buf = kmalloc(32, GFP_ATOMIC);
> +
> + if (!buf)
> + return NULL;
>
> snprintf(buf, 32,
> "%c%c%c%c %s-endian (0x%08x)",
Why aren't we using kasprintf()?
Or we could have just made the caller provide the buffer...
> --
> 2.7.4
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
