All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: bibo mao <maobibo@loongson.cn>
Cc: Song Gao <gaosong@loongson.cn>,
	 Jiaxun Yang <jiaxun.yang@flygoat.com>,
	qemu-devel@nongnu.org,  Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v4 4/4] target/loongarch: Set dest error with error_abort in virt_cpu_irq_init
Date: Wed, 19 Mar 2025 09:52:54 +0100	[thread overview]
Message-ID: <8734f91jx5.fsf@pond.sub.org> (raw)
In-Reply-To: <3d9c1bff-c1a5-5e87-e912-7246c2c8f512@loongson.cn> (bibo mao's message of "Wed, 19 Mar 2025 15:58:37 +0800")

bibo mao <maobibo@loongson.cn> writes:

On 2025/3/19 下午2:09, Markus Armbruster wrote:
>> Bibo Mao <maobibo@loongson.cn> writes:
>> 
>>> In function virt_cpu_irq_init(), there is notification with ipi and extioi
>>> interrupt controller for cpu creation. Local variable with error type is
>>> used, however there is no check with its return value.
>> 
>> Good catch.
>> 
>> When the first call fails, we pass non-null @err to the second call,
>> which is wrong.  If that one also fails, it'll likely trip
>> error_setv()'s assertion.
>> 
>>> Here set dest error object with error_abort, rather than local variable, so
>>> application will abort to run if there is error.
>> 
>> Why is failure impossible there?
> In plug hanlder of extioi/ipi, there is only warn_report() if object is 
> not TYPE_LOONGARCH_CPU, parameter errp is not changed.
>
> With caller funciton virt_cpu_irq_init(), DEVICE(cs) is object with type 
> TYPE_LOONGARCH_CPU always, so failure is impossible here.
>
>> 
>> If failure is impossible, the code before the patch is harmlessly wrong.
> yes, it is harmlessly wrong.

Could use something like

    target/loongarch: Clean up virt_cpu_irq_init() error handling

    The Error ** argument must be NULL, &error_abort, &error_fatal, or a
    pointer to a variable containing NULL.  Passing an argument of the
    latter kind twice without clearing it in between is wrong: if the
    first call sets an error, it no longer points to NULL for the second
    call.
    
    virt_cpu_irq_init() is wrong that way: it passes &err to
    hotplug_handler_plug() twice.  If both calls failed, this could trip
    error_setv()'s assertion.  Moreover, if just one fails, the Error
    object leaks.  Fortunately, these calls can't actually fail.

    Messed up in commit 50ebc3fc47f7 (hw/intc/loongarch_ipi: Notify ipi
    object when cpu is plugged) and commit 087a23a87c57
    (hw/intc/loongarch_extioi: Use cpu plug notification).

    Clean this up by clearing passing &error_abort instead.

    Signed-off-by: Bibo Mao <maobibo@loongson.cn>

Note: I replaced the Fixes: tags by a "Messed up ..." paragraph, because
there is no bug to fix according to your explanation.

With something like that:
Acked-by: Markus Armbruster <armbru@redhat.com>

> Regards
> Bibo Mao
>> 
>> If failure is possible, the code before the patch has a crash bug, and
>> the patch makes it crash harder, i.e. when either call fails instead of
>> when both fail.
>> 
>>> Fixes: 50ebc3fc47fe (hw/intc/loongarch_ipi: Notify ipi object when cpu is plugged)
>>> Fixes: 087a23a87c57 (hw/intc/loongarch_extioi: Use cpu plug notification)
>>> Signed-off-by: Bibo Mao <maobibo@loongson.cn>



      reply	other threads:[~2025-03-19  8:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-19  2:08 [PATCH v4 0/4] target/loongarch: Solve some issues reported from coccinelle Bibo Mao
2025-03-19  2:08 ` [PATCH v4 1/4] target/loongarch: Fix error handling of KVM feature checks Bibo Mao
2025-03-19  2:08 ` [PATCH v4 2/4] hw/loongarch/virt: Remove unnecessary NULL pointer Bibo Mao
2025-03-19  6:50   ` Markus Armbruster
2025-03-19  8:14     ` bibo mao
2025-03-19  8:43       ` Markus Armbruster
2025-03-19  2:08 ` [PATCH v4 3/4] target/loongarch: Remove unnecessary temporary variable assignment Bibo Mao
2025-03-19  2:08 ` [PATCH v4 4/4] target/loongarch: Set dest error with error_abort in virt_cpu_irq_init Bibo Mao
2025-03-19  6:09   ` Markus Armbruster
2025-03-19  7:58     ` bibo mao
2025-03-19  8:52       ` Markus Armbruster [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=8734f91jx5.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=gaosong@loongson.cn \
    --cc=jiaxun.yang@flygoat.com \
    --cc=maobibo@loongson.cn \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.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 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.