From: Marcel Apfelbaum <marcel@redhat.com>
To: Markus Armbruster <armbru@redhat.com>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
qemu-devel@nongnu.org, "Hervé Poussineau" <hpoussin@reactos.org>,
"Aurelien Jarno" <aurelien@aurel32.net>,
"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH 10/12] isa: Clean up inappropriate hw_error()
Date: Thu, 10 Dec 2015 16:12:05 +0200 [thread overview]
Message-ID: <56698835.4000107@redhat.com> (raw)
In-Reply-To: <87poyee9hv.fsf@blackfin.pond.sub.org>
On 12/10/2015 03:09 PM, Markus Armbruster wrote:
> Marcel Apfelbaum <marcel.apfelbaum@gmail.com> writes:
>
>> On 12/10/2015 12:29 PM, Markus Armbruster wrote:
>>> isa_bus_irqs(), isa_create() and isa_try_create() call hw_error() when
>>> passed a null bus. Use of hw_error() has always been questionable,
>>> because these are used only during machine initialization, and
>>> printing CPU registers isn't useful there.
>>>
>>> Since the previous commit, passing a null bus is a programming error.
>>> Drop the hw_error() and simply let it crash.
>>
>> Maybe we can be a little nicer add an assert ? :)
>
> assert(p) before dereferencing p only converts one kind of crash into
> another one. I tend to do it only when the assert(p) does double-duty
> as useful documentation. Or perhaps when I think there's a real risk of
> running into !p in an environment where core dumps are off[*] and
> reproducing the failure with a debugger attached could be hard.
>
> To use these three functions, you need an ISABus *. How could you end
> up with a bad one?
>
> * You forget to create the ISA bus, and the compiler is too confused to
> notice. You'll pass an unitialized ISABus, and asserting it's not
> null is unlikely to help.
>
> * You create multiple ISA buses (that's the only way creating one can
> fail) *and* forget to check for errors. If you pull that off, I'd
> expect it to explode even in light testing.
This is the scenario I was referring to.
You are perfectly right that using assert will change a crash into another,
but when I am "succeeding" to crash some code (and I am good at it :)),
if I see a NULL pointer de-reference I am starting to wonder if *is possible*
to have a NULL pointer there and the developer didn't take that into account.
(it couldn't me my bug, right, it got be his :))
However, if I see an assert crash *I know* the developer did not expect a NULL
pointer to be passed at all.
For this specific scenario, (multiple ISA buses) maybe is such a strange case
that we don't need to bother with an assert.
Thanks for the detailed explanation,
Marcel
>
> * Your pointer gets corrupted between correct initialization and use.
> Asserting it's not null is unlikely to help.
>
>
> [*] Switching them off on a development machine forfeits your
> developer's license, as far as I'm concerned :)
>
next prev parent reply other threads:[~2015-12-10 14:12 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 10:29 [Qemu-devel] [PATCH 00/12] Clean up some hw_error() misuse Markus Armbruster
2015-12-10 10:29 ` [Qemu-devel] [PATCH 01/12] hw: Don't use hw_error() for machine initialization errors Markus Armbruster
2015-12-10 10:45 ` [Qemu-devel] [Qemu-arm] " Peter Maydell
2015-12-14 10:07 ` [Qemu-devel] " Thomas Huth
2015-12-14 10:48 ` Markus Armbruster
2015-12-10 10:29 ` [Qemu-devel] [PATCH 02/12] omap: Don't use hw_error() in device init() methods Markus Armbruster
2015-12-10 10:42 ` Peter Maydell
2015-12-10 12:44 ` Markus Armbruster
2015-12-10 10:29 ` [Qemu-devel] [PATCH 03/12] arm_mptimer: Don't use hw_error() in realize() method Markus Armbruster
2015-12-10 10:37 ` Peter Maydell
2015-12-10 12:45 ` Markus Armbruster
2015-12-10 10:29 ` [Qemu-devel] [PATCH 04/12] etraxfs_eth: Don't use hw_error() in init() method Markus Armbruster
2015-12-10 10:32 ` Edgar E. Iglesias
2015-12-10 10:29 ` [Qemu-devel] [PATCH 05/12] raven: Mark use of hw_error() in realize() FIXME Markus Armbruster
2015-12-14 10:09 ` Thomas Huth
2015-12-10 10:29 ` [Qemu-devel] [PATCH 06/12] hw/arm/virt: Fix property "gic-version" error handling Markus Armbruster
2015-12-15 11:38 ` Peter Maydell
2015-12-17 7:02 ` Markus Armbruster
2015-12-10 10:29 ` [Qemu-devel] [PATCH 07/12] sysbus: Don't use hw_error() in machine_init_done_notifiers Markus Armbruster
2015-12-10 10:29 ` [Qemu-devel] [PATCH 08/12] isa: Trivially convert remaining PCI-ISA bridges to realize() Markus Armbruster
2015-12-10 11:34 ` Marcel Apfelbaum
2015-12-10 10:29 ` [Qemu-devel] [PATCH 09/12] isa: Clean up error handling around isa_bus_new() Markus Armbruster
2015-12-10 11:55 ` Marcel Apfelbaum
2015-12-10 21:51 ` Hervé Poussineau
2015-12-10 10:29 ` [Qemu-devel] [PATCH 10/12] isa: Clean up inappropriate hw_error() Markus Armbruster
2015-12-10 11:59 ` Marcel Apfelbaum
2015-12-10 13:09 ` Markus Armbruster
2015-12-10 14:12 ` Marcel Apfelbaum [this message]
2015-12-10 21:53 ` Hervé Poussineau
2015-12-10 10:29 ` [Qemu-devel] [PATCH 11/12] audio: Clean up inappropriate and unreachable use of hw_error() Markus Armbruster
2015-12-15 10:07 ` Gerd Hoffmann
2015-12-10 10:29 ` [Qemu-devel] [PATCH 12/12] xen-hvm: Mark inappropriate error handling FIXME Markus Armbruster
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=56698835.4000107@redhat.com \
--to=marcel@redhat.com \
--cc=armbru@redhat.com \
--cc=aurelien@aurel32.net \
--cc=hpoussin@reactos.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).