From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Daniel Vetter <daniel@ffwll.ch>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Jani Nikula <jani.nikula@linux.intel.com>
Subject: Re: [PATCH] drm/i915: Use kcalloc more
Date: Sat, 21 Sep 2013 00:37:42 +0200 [thread overview]
Message-ID: <20130920223741.GT32145@phenom.ffwll.local> (raw)
In-Reply-To: <20130919125809.GJ6566@nuc-i3427.alporthouse.com>
On Thu, Sep 19, 2013 at 01:58:09PM +0100, Chris Wilson wrote:
> On Thu, Sep 19, 2013 at 02:51:10PM +0200, Daniel Vetter wrote:
> > On Thu, Sep 19, 2013 at 01:41:53PM +0100, Chris Wilson wrote:
> > > On Thu, Sep 19, 2013 at 02:35:42PM +0200, Daniel Vetter wrote:
> > > > On Thu, Sep 19, 2013 at 2:30 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > > > > On Thu, Sep 19, 2013 at 02:06:39PM +0200, Daniel Vetter wrote:
> > > > >> No buffer overflows here, but better safe than sorry.
> > > > >>
> > > > >> v2:
> > > > >> - Fixup the sizeof conversion, I've missed the pointer deref (Jani).
> > > > >> - Drop the redundant GFP_ZERO, kcalloc alreads memsets (Jani).
> > > > >> - Use kmalloc_array for the execbuf fastpath to avoid the memset
> > > > >> (Chris). I've opted to leave all other conversions as-is since they
> > > > >> aren't in a fastpath and dealing with cleared memory instead of
> > > > >> random garbage is just generally nicer.
> > > > >
> > > > > I still don't agree with this change to kmalloc_array. The code is
> > > > > written explicitly such that an invalid buffer_count is reported as
> > > > > EINVAL and not ENOMEM.
> > > >
> > > > It's just paranoia - imo consistently using kcalloc/kmalloc array
> > > > where possible is just safer. Note also that the subtest I've added
> > > > explicitly checks for EINVAL, so if we ever botch this it should get
> > > > caught.
> > >
> > > Paranoia for what? Checking the same thing twice in case the compiler
> > > changes it mind?
> >
> > The compiler actually removes the 2nd check since it's the same ;-) I just
> > like the consisten pattern and cozy feeling that we'll have less to worry
> > for potential overflows. I can ditch it if you deem it too offensive.
>
> Having been along this road before, I preferred the explicit checking
> that also gets the right return value. The goal here is perform all
> sanity checks as early as possible - but I'm not going to fight to move
> the cliprects test as cliprects are broken by design.
I've dropped the contentious hunk and merged all the reviewed patches.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2013-09-20 22:37 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-19 10:18 [PATCH 1/5] drm/i915: use pointer = k[cmz...]alloc(sizeof(*pointer), ...) pattern Daniel Vetter
2013-09-19 10:18 ` [PATCH 2/5] drm/i915: Use kcalloc more Daniel Vetter
2013-09-19 10:38 ` Jani Nikula
2013-09-19 10:50 ` Chris Wilson
2013-09-19 11:00 ` Jani Nikula
2013-09-19 11:12 ` Chris Wilson
2013-09-19 10:46 ` Chris Wilson
2013-09-19 11:53 ` Daniel Vetter
2013-09-19 12:06 ` [PATCH] " Daniel Vetter
2013-09-19 12:30 ` Chris Wilson
2013-09-19 12:35 ` Daniel Vetter
2013-09-19 12:41 ` Chris Wilson
2013-09-19 12:51 ` Daniel Vetter
2013-09-19 12:58 ` Chris Wilson
2013-09-20 22:37 ` Daniel Vetter [this message]
2013-09-19 13:40 ` Jani Nikula
2013-09-19 10:18 ` [PATCH 3/5] drm/i915: Ditch INTELFB_CONN_LIMIT Daniel Vetter
2013-09-19 10:53 ` Jani Nikula
2013-09-19 12:05 ` [PATCH] " Daniel Vetter
2013-09-19 13:32 ` Jani Nikula
2013-09-19 10:18 ` [PATCH 4/5] drm/i915: check for allocation overflow in error state capture Daniel Vetter
2013-09-20 23:39 ` Ben Widawsky
2013-09-19 10:18 ` [PATCH 5/5] drm/i915: Use unsigned for overflow checks in execbuf Daniel Vetter
2013-09-19 10:44 ` Chris Wilson
2013-09-19 12:00 ` [PATCH] " Daniel Vetter
2013-09-19 12:53 ` Daniel Vetter
2013-09-19 13:05 ` Chris Wilson
2013-09-19 10:46 ` [PATCH 5/5] " Jani Nikula
2013-09-19 10:34 ` [PATCH 1/5] drm/i915: use pointer = k[cmz...]alloc(sizeof(*pointer), ...) pattern Jani Nikula
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130920223741.GT32145@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox