linux-kernel - Re: [PATCH] drm: make drm_get_format

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160815135207.GG6232@phenom.ffwll.local>
Date:	Mon, 15 Aug 2016 15:52:07 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Jani Nikula <jani.nikula@...ux.intel.com>
Cc:	Eric Engestrom <eric.engestrom@...tec.com>,
	Tom St Denis <tom.stdenis@....com>,
	intel-gfx@...ts.freedesktop.org,
	Eric Engestrom <eric@...estrom.ch>,
	Michel Dänzer <michel.daenzer@....com>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	Xinliang Liu <z.liuxinliang@...ilicon.com>,
	David Zhang <david1.zhang@....com>,
	Wei Yongjun <yongjun_wei@...ndmicro.com.cn>,
	Vitaly Prosyak <vitaly.prosyak@....com>,
	Daniel Vetter <daniel.vetter@...el.com>,
	Junwei Zhang <Jerry.Zhang@....com>,
	Alex Deucher <alexander.deucher@....com>,
	Flora Cui <Flora.Cui@....com>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	Christian König <christian.koenig@....com>
Subject: Re: [PATCH] drm: make drm_get_format_name thread-safe

On Mon, Aug 15, 2016 at 04:13:54PM +0300, Jani Nikula wrote:
> On Mon, 15 Aug 2016, Eric Engestrom <eric.engestrom@...tec.com> wrote:
> > On Mon, Aug 15, 2016 at 12:54:01PM +0300, Jani Nikula wrote:
> >> On Mon, 15 Aug 2016, Eric Engestrom <eric@...estrom.ch> wrote:
> >> > Signed-off-by: Eric Engestrom <eric@...estrom.ch>
> >> > ---
> >> >
> >> > I moved the main bits to be the first diffs, shouldn't affect anything
> >> > when applying the patch, but I wanted to ask:
> >> > I don't like the hard-coded `32` the appears in both kmalloc() and
> >> > snprintf(), what do you think? If you don't like it either, what would
> >> > you suggest? Should I #define it?
> >> >
> >> > Second question is about the patch mail itself: should I send this kind
> >> > of patch separated by module, with a note requesting them to be squashed
> >> > when applying? It has to land as a single patch, but for review it might
> >> > be easier if people only see the bits they each care about, as well as
> >> > to collect ack's/r-b's.
> >> >
> >> > Cheers,
> >> >   Eric
> >> >
> >> > ---
> >> >  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c          |  6 ++--
> >> >  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c          |  6 ++--
> >> >  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c           |  6 ++--
> >> >  drivers/gpu/drm/drm_atomic.c                    |  5 ++--
> >> >  drivers/gpu/drm/drm_crtc.c                      | 21 ++++++++-----
> >> >  drivers/gpu/drm/drm_fourcc.c                    | 17 ++++++-----
> >> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  6 ++--
> >> >  drivers/gpu/drm/i915/i915_debugfs.c             | 11 ++++++-
> >> >  drivers/gpu/drm/i915/intel_atomic_plane.c       |  6 ++--
> >> >  drivers/gpu/drm/i915/intel_display.c            | 39 ++++++++++++++++---------
> >> >  drivers/gpu/drm/radeon/atombios_crtc.c          | 12 +++++---
> >> >  include/drm/drm_fourcc.h                        |  2 +-
> >> >  12 files changed, 89 insertions(+), 48 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> >> > index 0645c85..38216a1 100644
> >> > --- a/drivers/gpu/drm/drm_fourcc.c
> >> > +++ b/drivers/gpu/drm/drm_fourcc.c
> >> > @@ -39,16 +39,14 @@ static char printable_char(int c)
> >> >   * drm_get_format_name - return a string for drm fourcc format
> >> >   * @format: format to compute name of
> >> >   *
> >> > - * Note that the buffer used by this function is globally shared and owned by
> >> > - * the function itself.
> >> > - *
> >> > - * FIXME: This isn't really multithreading safe.
> >> > + * Note that the buffer returned by this function is owned by the caller
> >> > + * and will need to be freed.
> >> >   */
> >> >  const char *drm_get_format_name(uint32_t format)
> >> 
> >> I find it surprising that a function that allocates a buffer returns a
> >> const pointer. Some userspace libraries have conventions about the
> >> ownership based on constness.
> >> 
> >> (I also find it suprising that kfree() takes a const pointer; arguably
> >> that call changes the memory.)
> >> 
> >> Is there precedent for this?
> >> 
> >> BR,
> >> Jani.
> >
> > It's not a const pointer, it's a normal pointer to a const char, i.e.
> > you can do as you want with the pointer but you shouldn't change the
> > chars it points to.
> 
> Ermh, that's what I meant even if I was sloppy in my reply. And arguably
> freeing the bytes the pointer points at changes them, albeit subtly. And
> having a function return a pointer to const data is often an indication
> that the ownership of the data isn't transfered, i.e. you're not
> supposed to free it yourself.

I already applied the patch, but yes dropping the const would be a good
hint to callers that they now own that block of memory. Eric, can you pls
follow up with a fix up patch - drm-misc is non-rebasing?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch