All of lore.kernel.org
 help / color / mirror / Atom feed
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 :)
>

  reply	other threads:[~2015-12-10 14:12 UTC|newest]

Thread overview: 33+ 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
2015-12-10 10:29   ` 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 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.