From: Zdenek Kabelac <zkabelac@redhat.com>
To: lvm-devel@redhat.com
Subject: [PATCH 0/5] Fix NULL dereference
Date: Tue, 26 Oct 2010 16:14:58 +0200 [thread overview]
Message-ID: <4CC6E262.2010702@redhat.com> (raw)
In-Reply-To: <20101026135759.GL29400@agk-dp.fab.redhat.com>
Dne 26.10.2010 15:57, Alasdair G Kergon napsal(a):
> On Tue, Oct 26, 2010 at 02:59:21PM +0200, Zdenek Kabelac wrote:
>> Updated patchset for NULL pointer dereferences issues reported by clang.
>>
>> Unlike the first version - this time less aggresive solution is used.
>> INTERNAL_ERRORs are reported in these moments (if they would ever happen),
>> and the execution path aborts when such conditions are met.
>> Previous version was rather ignoring these paths and could lead to
>> unwanted execution of other code parts.
>
> Well the ones I've looked at here seem to be more about dealing with
> shortcomings in the static analysis code rather than fixing real bugs.
>
Some of them can never be triggered within current LVM code.
Static analyzer is currently incapable to model data structure behavior
to understand, that some settings can never happen and sometimes it creates
very complex code path to model NULL pointer at the end.
(Also instrumentation nonnull would be handy here - but it's long term goal)
However my small patches here really just try to clean warning - the price for
checks seems to be quite low and we do not need to look into analyzer output
again and again.
We may also put them into
#ifdef __clang__
#endif
section to avoid any runtime overheads - but I don't like spreading such
ifdefs everywhere.
I can also keep these patches in my private branch - to not be always bothered
with same error.
For now I did not want to spend too much time on this so I've rather fixed
easily and quickly what I've considered to be even worth to look at.
Of course deeper analysis here will require some time - so - placing them to
my low-prio background queue....
Zdenek
prev parent reply other threads:[~2010-10-26 14:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-26 12:59 [PATCH 0/5] Fix NULL dereference Zdenek Kabelac
2010-10-26 12:59 ` [PATCH 1/5] Check type is not NULL before access Zdenek Kabelac
2010-10-26 14:02 ` Alasdair G Kergon
2010-10-26 12:59 ` [PATCH 2/5] Ensure seg is nonnull Zdenek Kabelac
2010-10-26 13:29 ` Alasdair G Kergon
2010-10-26 12:59 ` [PATCH 3/5] Ensure first is not NULL before dereference Zdenek Kabelac
2010-10-26 13:52 ` Alasdair G Kergon
2010-10-26 12:59 ` [PATCH 4/5] Fix theoretical usage of NULL pointer dereference Zdenek Kabelac
2010-10-26 13:37 ` Alasdair G Kergon
2010-10-27 10:19 ` ejt
2010-10-27 10:36 ` Zdenek Kabelac
2010-10-26 12:59 ` [PATCH 5/5] Check for NULL pointer Zdenek Kabelac
2010-10-26 13:42 ` Alasdair G Kergon
2010-10-26 13:57 ` [PATCH 0/5] Fix NULL dereference Alasdair G Kergon
2010-10-26 14:05 ` Petr Rockai
2010-10-26 14:17 ` Zdenek Kabelac
2010-10-26 14:14 ` Zdenek Kabelac [this message]
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=4CC6E262.2010702@redhat.com \
--to=zkabelac@redhat.com \
--cc=lvm-devel@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.