From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753002AbcHONOB (ORCPT ); Mon, 15 Aug 2016 09:14:01 -0400 Received: from mga04.intel.com ([192.55.52.120]:9485 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752785AbcHONOA (ORCPT ); Mon, 15 Aug 2016 09:14:00 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,525,1464678000"; d="scan'208";a="1041381856" From: Jani Nikula To: Eric Engestrom Cc: Eric Engestrom , linux-kernel@vger.kernel.org, Tom St Denis , intel-gfx@lists.freedesktop.org, Michel =?utf-8?Q?D=C3=A4nzer?= , Wei Yongjun , dri-devel@lists.freedesktop.org, Junwei Zhang , Xinliang Liu , David Zhang , Vitaly Prosyak , Alex Deucher , Daniel Vetter , Flora Cui , Gustavo Padovan , Christian =?utf-8?Q?K=C3=B6nig?= Subject: Re: [PATCH] drm: make drm_get_format_name thread-safe In-Reply-To: <20160815125928.GC10429@imgtec.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20160815000247.20063-1-eric@engestrom.ch> <87eg5quzly.fsf@intel.com> <20160815125928.GC10429@imgtec.com> User-Agent: Notmuch/0.22.1+63~g648dcc7 (https://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 15 Aug 2016 16:13:54 +0300 Message-ID: <87y43ytbsd.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 15 Aug 2016, Eric Engestrom wrote: > On Mon, Aug 15, 2016 at 12:54:01PM +0300, Jani Nikula wrote: >> On Mon, 15 Aug 2016, Eric Engestrom wrote: >> > Signed-off-by: Eric Engestrom >> > --- >> > >> > 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