Re: [PATCH] drm: make drm_get_format_name thread-safe

Jani Nikula
2016-08-15T13:14:01Z

On Mon, 15 Aug 2016, Eric Engestrom <eric.engestrom@imgtec.com> wrote:
> On Mon, Aug 15, 2016 at 12:54:01PM +0300, Jani Nikula wrote:
>> On Mon, 15 Aug 2016, Eric Engestrom <eric@engestrom.ch> wrote:
>> > Signed-off-by: Eric Engestrom <eric@engestrom.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.

BR,
Jani.

--
Jani Nikula, Intel Open Source Technology Center