intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: david.weinehall@linux.intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/7] device: prevent a NULL pointer dereference in __intel_peek_fd
Date: Mon, 15 Feb 2016 14:08:24 +0000	[thread overview]
Message-ID: <56C1DBD8.8060201@intel.com> (raw)
In-Reply-To: <20160215134336.GD2330@boom>

On 15/02/16 13:43, David Weinehall wrote:
> On Mon, Feb 15, 2016 at 12:24:04PM +0000, Dave Gordon wrote:
>> On 12/02/16 16:31, Martin Peres wrote:
>>> This is not a big issue to return -1 since the only codepath that uses
>>> it is for display purposes.
>>>
>>> Caught by Klockwork.
>>>
>>> Signed-off-by: Martin Peres <martin.peres@linux.intel.com>
>>> ---
>>>   src/intel_device.c | 5 ++++-
>>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/intel_device.c b/src/intel_device.c
>>> index 54c1443..35e652a 100644
>>> --- a/src/intel_device.c
>>> +++ b/src/intel_device.c
>>> @@ -650,7 +650,10 @@ int __intel_peek_fd(ScrnInfoPtr scrn)
>>>   	dev = intel_device(scrn);
>>>   	assert(dev && dev->fd != -1);
>>
>> Doesn't Klocwork recognise the assert() above?
>> I thought that would tell it that dev can't be NULL.
>
> My guess is that klockwork recognises that assert() can be a no-op
> if NDEBUG is defined and in such case won't generate code.
> In such a case neither of those two checks are performed.
>
> Kind regards, David

Klocwork is a static analysis tool, it doesn't generate code at all.
It's supposed to recognise assert() and similar macros as constraints on 
what values particular expressions may have; in particular, it knows 
that if a code path ends with a call to abort(), that path *should* 
never be taken and it will assume (for static analysis purposes) that it 
*will* not be taken. Thus any combination of values that leads to an 
abort() is considered "impossible" and need not be further checked. Then 
assert() is typically defined as:

     #define assert(x) do { if(!(x)) abort(); } while (0)

and then

     int foo(char *s)
     {
         assert(s);
         return *s;
     }

should not cause Klocwork to complain, whereas without the assert() it 
should say that 's' might be NULL when dereferenced. If it's getting 
false positives it may be that Klocwork hasn't been told the proper 
(conditional) definition for assert()?

.Dave.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-02-15 14:08 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-12 16:31 [PATCH DDX 0/7] Some issues found with Klockwork Martin Peres
2016-02-12 16:31 ` [PATCH 1/7] device: prevent a NULL pointer dereference in __intel_peek_fd Martin Peres
2016-02-12 16:40   ` Chris Wilson
2016-02-15 12:24   ` Dave Gordon
2016-02-15 13:40     ` Martin Peres
2016-02-15 13:47       ` Dave Gordon
2016-02-15 15:56         ` Martin Peres
2016-02-16  8:54           ` Dave Gordon
2016-02-16 11:09             ` Martin Peres
2016-02-15 13:43     ` David Weinehall
2016-02-15 14:08       ` Dave Gordon [this message]
2016-02-12 16:31 ` [PATCH 2/7] display: prevent a NULL pointer dereference in intel_set_scanout_pixmap Martin Peres
2016-02-12 17:34   ` Chris Wilson
2016-02-12 16:31 ` [PATCH 3/7] sna: check for NULL before dereferencing a pointer Martin Peres
2016-02-12 16:48   ` Chris Wilson
2016-02-12 16:31 ` [PATCH 4/7] sna: assert a pointer is non-NULL before dereferencing it Martin Peres
2016-02-12 16:42   ` Chris Wilson
2016-02-12 16:31 ` [PATCH 5/7] sna/cursor: add an assert on cursor->image Martin Peres
2016-02-12 16:47   ` Chris Wilson
2016-02-12 16:31 ` [PATCH 6/7] sna_video_sprite: add asserts to catch invalid pipe# Martin Peres
2016-02-12 16:45   ` Chris Wilson
2016-02-12 16:31 ` [PATCH 7/7] sna: add an assert in the lengthy sna_drawable_use_bo Martin Peres
2016-02-12 16:45   ` Chris Wilson

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=56C1DBD8.8060201@intel.com \
    --to=david.s.gordon@intel.com \
    --cc=david.weinehall@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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;
as well as URLs for NNTP newsgroup(s).