linux-kernel - Re: [PATCH] drm: move allocation out of 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]

Date:   Mon, 7 Nov 2016 00:47:13 +0000
From:   Eric Engestrom <eric@...estrom.ch>
To:     Rob Clark <robdclark@...il.com>
Cc:     Christian König <christian.koenig@....com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        Wei Yongjun <yongjun_wei@...ndmicro.com.cn>,
        Daniel Vetter <daniel.vetter@...el.com>,
        Flora Cui <Flora.Cui@....com>,
        Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
        Tom St Denis <tom.stdenis@....com>,
        Thomas Hellstrom <thellstrom@...are.com>,
        Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
        Xinliang Liu <z.liuxinliang@...ilicon.com>,
        VMware Graphics <linux-graphics-maintainer@...are.com>,
        Vitaly Prosyak <vitaly.prosyak@....com>,
        Alexandre Demers <alexandre.f.demers@...il.com>,
        Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
        Emily Deng <Emily.Deng@....com>,
        Ken Wang <Qingqing.Wang@....com>,
        Junwei Zhang <Jerry.Zhang@....com>,
        Michel Dänzer <michel.daenzer@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Alex Deucher <alexander.deucher@....com>,
        Colin Ian King <colin.king@...onical.com>
Subject: Re: [PATCH] drm: move allocation out of drm_get_format_name()

On Sunday, 2016-11-06 08:03:47 -0500, Rob Clark wrote:
> On Sun, Nov 6, 2016 at 4:47 AM, Christian König
> <christian.koenig@....com> wrote:
> > Am 05.11.2016 um 17:49 schrieb Rob Clark:
> >>
> >> On Sat, Nov 5, 2016 at 12:38 PM, Eric Engestrom <eric@...estrom.ch> wrote:
> >>>
> >>> On Saturday, 2016-11-05 13:11:36 +0100, Christian König wrote:
> >>>>
> >>>> Am 05.11.2016 um 02:33 schrieb Eric Engestrom:
> >>>>>
> >>>>> +typedef char drm_format_name_buf[32];
> >>>>
> >>>> Please don't use a typedef for this, just define the maximum size of
> >>>> characters the function might write somewhere.
> >>>>
> >>>> See the kernel coding style as well:
> >>>>>
> >>>>> In general, a pointer, or a struct that has elements that can
> >>>>> reasonably
> >>>>> be directly accessed should **never** be a typedef.
> >>>
> >>> I would normally agree as I tend to hate typedefs ($DAYJOB {ab,mis}uses
> >>> them way too much), and your way was what I wrote at first, but Rob
> >>> Clark's
> >>> typedef idea makes it much harder for someone to allocate a buffer of
> >>> the wrong size, which IMO is good thing here.
> >>
> >> IMHO I would make a small test program to verify this actually helps
> >> the compiler catch problems.  And if it does, I would stick with it.
> >> The coding-style should be guidelines, not something that supersedes
> >> common sense / practicality.
> >
> >
> > Well completely agree that we should be able to question the coding style
> > rules, but when we do it we discuss this on a the mailing list first and
> > then start to use it in code. Not the other way around.
> 
> if I'm not mistaken, that is what we are doing ;-)
> 
> >>
> >> That is my $0.02 anyways.. if others vehemently disagree and want to
> >> dogmatically stick to the coding-style guidelines, ok then.  OTOH, if
> >> this approach doesn't help the compiler catch issues, then it isn't
> >> worth it.
> >
> >
> > Yeah, exactly that's the point. If I'm not completely mistaken the compiler
> > won't issue a warning here if you pass an array with the wrong size.
> >
> > I think you need something like "struct drm_format_name_buf { char str[32];
> > };" to trigger this.
> 
> hmm, actually the struct is a nice idea then if the compiler wouldn't
> catch the wrong-size-array

Sending the patch in a minute.

> 
> > apart from that is this function really called so often that using
> > kasprintf() is a problem here? or is there another motivation behind the
> > change?
> 
> two things trouble me about the kasprintf approach.. (ignoring the
> fact that atm it is not gfp_atomic)
> 1) you can't do drm_debug("format: %s\n", drm_get_format_name(..)) so
> it pulls the memory allocation and sprintf outside of the drm_debug
> check
> 2) seems awfully easy to forget the kfree...

I actually found a couple of these memory leaks while doing this patch,
look for files where i don't remove kfree :)
(eg. vmwgfx at the end of the patch)

> i wouldn't have even
> known that now you need to free the result (with some patches i'm
> working on) if it weren't for the fact that lockdep alerted me to the
> gfp_kernel allocation in atomic ctx ;-)
> 
> br,
> -r