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>,
	 Igor Mammedov <imammedo@redhat.com>
Subject: Re: [PATCH v6 3/6] hw/loongarch/virt: Fix error handling in cpu unplug
Date: Fri, 21 Mar 2025 08:21:53 +0100	[thread overview]
Message-ID: <87ldsy7sry.fsf@pond.sub.org> (raw)
In-Reply-To: <87d1b58e-1b8b-f582-753b-574c4ba44a6b@loongson.cn> (bibo mao's message of "Fri, 21 Mar 2025 15:00:34 +0800")

bibo mao <maobibo@loongson.cn> writes:

> +Igor
>
>
> On 2025/3/21 下午2:47, Markus Armbruster wrote:
>> Bibo Mao <maobibo@loongson.cn> writes:
>> 
>>> In function virt_cpu_unplug(), it will send cpu unplug message to
>>> interrupt controller extioi and ipi irqchip. If there is problem in
>>> this function, system should continue to run and keep state the same
>>> before cpu is removed.
>>>
>>> If error happends in cpu unplug stage, send cpu plug message to extioi
>>> and ipi irqchip to restore to previous stage, and then return immediately.
>>>
>>> Fixes: 2cd6857f6f5b (hw/loongarch/virt: Implement cpu unplug interface)
>>> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
>>> ---
>>>   hw/loongarch/virt.c | 6 ++++++
>>>   1 file changed, 6 insertions(+)
>>>
>>> diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
>>> index 8563967c8b..503362a69e 100644
>>> --- a/hw/loongarch/virt.c
>>> +++ b/hw/loongarch/virt.c
>>> @@ -958,6 +958,8 @@ static void virt_cpu_unplug(HotplugHandler *hotplug_dev,
>>>       hotplug_handler_unplug(HOTPLUG_HANDLER(lvms->extioi), dev, &err);
>>>       if (err) {
>>>           error_propagate(errp, err);
>>> +        hotplug_handler_plug(HOTPLUG_HANDLER(lvms->ipi), dev,
>>> +                             &error_abort);
>>>           return;
>>>       }
>>>   
>>> @@ -965,6 +967,10 @@ static void virt_cpu_unplug(HotplugHandler *hotplug_dev,
>>>       hotplug_handler_unplug(HOTPLUG_HANDLER(lvms->acpi_ged), dev, &err);
>>>       if (err) {
>>>           error_propagate(errp, err);
>>> +        hotplug_handler_plug(HOTPLUG_HANDLER(lvms->ipi), dev,
>>> +                             &error_abort);
>>> +        hotplug_handler_plug(HOTPLUG_HANDLER(lvms->extioi), dev,
>>> +                             &error_abort);
>>>           return;
>>>       }
>> 
>> virt_cpu_unplug() calls hotplug_handler_unplug() three times to notify
>> ipi, extioi, and acpi_get.  If any notification fails, virt_cpu_unplug()
>> calls hotplug_handler_plug() to "un-notify" the preceeding ones, if any.
>> This must not fail.
>> 
>> virt_cpu_plug() does it the other way round (see previous patch).
>> 
>> So, hotplug_handler_plug() must not fail in virt_cpu_unplug(), yet we
>> check for it to fail in virt_cpu_plug().
>> 
>> Can it really fail in virt_cpu_plug()?
>> 
>> If yes, why can't it fail in virt_cpu_unplug()?
> you can check function acpi_cpu_plug_cb()/loongarch_ipi_cpu_plug(), that 
> is cpuplug callback for acpi_ged and ipi. it will not fail.
>
> If *virt_cpu_pre_plug()* pass, it will succeed.
>
> Regards
> Bibo Mao
>
>> 
>> Same questions for hotplug_handler_unplug().

Let me restate my argument.

We call hotplug_handler_plug() on the happy path, and on error recovery
paths.  Four cases:

1. Can fail on the happy path

   Error recovery is required.

1.1 Can fail on the error recovery path

    Error recovery is required, but broken.

1.2 Can't fail on the error recovery path

    Error recovery is required and works, but why it works is not
    obvious.  Deserves a comment explaining why hotplug_handler_plug()
    can't fail here even though it can fail on the happy path next door.

2. Can't fail on the happy path

   Error recovery is unreachable.

2.1 Can fail on the error recovery path

    Error recovery is unreachable and broken.  Possibly a time bomb, and
    possibly misleading readers.

2.2 Can't fail on the error recovery path

    Error recovery is unreachable and would work, but why it would work
    is again a not obvious.

Which of the four cases is it?



  reply	other threads:[~2025-03-21  7:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-21  3:12 [PATCH v6 0/6] target/loongarch: Fix some issues reported from coccinelle Bibo Mao
2025-03-21  3:12 ` [PATCH v6 1/6] target/loongarch: Fix error handling of KVM feature checks Bibo Mao
2025-03-21  3:12 ` [PATCH v6 2/6] hw/loongarch/virt: Fix error handling in cpu plug Bibo Mao
2025-04-04 12:06   ` Igor Mammedov
2025-03-21  3:12 ` [PATCH v6 3/6] hw/loongarch/virt: Fix error handling in cpu unplug Bibo Mao
2025-03-21  6:47   ` Markus Armbruster
2025-03-21  7:00     ` bibo mao
2025-03-21  7:21       ` Markus Armbruster [this message]
2025-03-21  7:35         ` bibo mao
2025-03-21  8:08           ` Markus Armbruster
2025-03-21  8:21             ` bibo mao
2025-04-04 11:59           ` Igor Mammedov
2025-04-08  2:07             ` bibo mao
2025-03-21  7:09     ` bibo mao
2025-04-04 12:08   ` Igor Mammedov
2025-03-21  3:12 ` [PATCH v6 4/6] hw/loongarch/virt: Eliminate error_propagate() Bibo Mao
2025-03-21  3:12 ` [PATCH v6 5/6] target/loongarch: Remove unnecessary temporary variable assignment Bibo Mao
2025-03-21  3:12 ` [PATCH v6 6/6] target/loongarch: Clean up virt_cpu_irq_init() error handling Bibo Mao

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=87ldsy7sry.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=gaosong@loongson.cn \
    --cc=imammedo@redhat.com \
    --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.