Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753620AbcKILn1 (ORCPT ); Wed, 9 Nov 2016 06:43:27 -0500 Received: from mailapp01.imgtec.com ([195.59.15.196]:49847 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932393AbcKILnU (ORCPT ); Wed, 9 Nov 2016 06:43:20 -0500 Date: Wed, 9 Nov 2016 11:42:17 +0000 From: Eric Engestrom To: Eric Engestrom , , David Airlie , , Wei Yongjun , Daniel Vetter , Flora Cui , Gustavo Padovan , Tom St Denis , Chunming Zhou , Thomas Hellstrom , Laurent Pinchart , Sinclair Yeh , Xinliang Liu , Xinwei Kong , VMware Graphics , Vitaly Prosyak , Alexandre Demers , Jani Nikula , , Emily Deng , Colin Ian King , Junwei Zhang , Michel =?utf-8?Q?D=C3=A4nzer?= , Alex Deucher , Christian =?utf-8?B?S8O2bmln?= Subject: Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name() Message-ID: <20161109114217.GO25290@imgtec.com> References: <20161108101558.ihvrprbbdqjwu5wg@phenom.ffwll.local> <20161109001805.10628-1-eric@engestrom.ch> <20161109010916.rpsqcswnlyxggovd@phenom.ffwll.local> <20161109011325.hvvfsvpq734nduxd@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20161109011325.hvvfsvpq734nduxd@phenom.ffwll.local> User-Agent: Mutt/1.7.1 (2016-10-04) X-Originating-IP: [10.60.4.28] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2602 Lines: 54 On Wednesday, 2016-11-09 02:13:25 +0100, Daniel Vetter wrote: > On Wed, Nov 09, 2016 at 02:09:16AM +0100, Daniel Vetter wrote: > > On Wed, Nov 09, 2016 at 12:17:52AM +0000, Eric Engestrom wrote: > > > The function's behaviour was changed in 90844f00049e, without changing > > > its signature, causing people to keep using it the old way without > > > realising they were now leaking memory. > > > Rob Clark also noticed it was also allocating GFP_KERNEL memory in > > > atomic contexts, breaking them. > > > > > > Instead of having to allocate GFP_ATOMIC memory and fixing the callers > > > to make them cleanup the memory afterwards, let's change the function's > > > signature by having the caller take care of the memory and passing it to > > > the function. > > > The new parameter is a single-field struct in order to enforce the size > > > of its buffer and help callers to correctly manage their memory. > > > > > > Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe") > > > Cc: Rob Clark > > > Cc: Christian König > > > Acked-by: Christian König > > > Acked-by: Rob Clark > > > Acked-by: Sinclair Yeh (vmwgfx) > > > Reviewed-by: Jani Nikula > > > Suggested-by: Ville Syrjälä > > > Signed-off-by: Eric Engestrom > > > --- > > > v3 - fix "Fixes" tag, replace it with an actual commit message > > > - collect ack & r-b > > > > > > v2 - use single-field struct instead of typedef to let the compiler > > > enforce the type (Christian König) > > > > Applied to drm-misc, thanks. > > Well, had to drop it again since it didn't compile: > > > CC [M] drivers/gpu/drm/drm_blend.o > drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’: > drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function ‘drm_get_format_name’ > drm_get_format_name(fb->pixel_format)); > ^~~~~~~~~~~~~~~~~~~ > In file included from ./include/drm/drmP.h:71:0, > from drivers/gpu/drm/drm_atomic.c:29: > ./include/drm/drm_fourcc.h:65:7: note: declared here > char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf); > ^~~~~~~~~~~~~~~~~~~ > > Can you pls rebase onto drm-misc or linux-next or something? That was based on airlied/drm-next (last fetched on Sunday I think), I can rebase it on drm-misc if it helps, but it seems older than drm-next. Should I just rebase on top of current head of drm-next?