linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Aneesh Kumar K.V (IBM) <aneesh.kumar@kernel.org>
To: Nathan Lynch <nathanl@linux.ibm.com>,
	Nathan Lynch via B4 Relay
	<devnull+nathanl.linux.ibm.com@kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>
Cc: tyreld@linux.ibm.com, "Michal Suchánek" <msuchanek@suse.de>,
	linuxppc-dev@lists.ozlabs.org, gcwilson@linux.ibm.com
Subject: Re: [PATCH v4 06/13] powerpc/rtas: Serialize firmware activation sequences
Date: Tue, 28 Nov 2023 21:16:30 +0530	[thread overview]
Message-ID: <875y1lev8p.fsf@kernel.org> (raw)
In-Reply-To: <87zfyx28rf.fsf@li-e15d104c-2135-11b2-a85c-d7ef17e56be6.ibm.com>

Nathan Lynch <nathanl@linux.ibm.com> writes:

> "Aneesh Kumar K.V (IBM)" <aneesh.kumar@kernel.org> writes:
>> Nathan Lynch via B4 Relay <devnull+nathanl.linux.ibm.com@kernel.org>
>> writes:
>>
>>>
>>> Use the function lock API to prevent interleaving call sequences of
>>> the ibm,activate-firmware RTAS function, which typically requires
>>> multiple calls to complete the update. While the spec does not
>>> specifically prohibit interleaved sequences, there's almost certainly
>>> no advantage to allowing them.
>>>
>>
>> Can we document what is the equivalent thing the userspace does?
>
> I'm not sure what we would document.
>
> As best I can tell, the activate_firmware command in powerpc-utils does
> not make any effort to protect its use of the ibm,activate-firmware RTAS
> function. The command is not intended to be run manually and I guess
> it's relying on the platform's management console to serialize its
> invocations.
>
> drmgr (also from powerpc-utils) has some dead code for LPM that calls
> ibm,activate-firmware; it should probably be removed. The command uses a
> lock file to serialize all of its executions.
>
> Something that could happen with interleaved ibm,activate-firmware
> sequences is something like this:
>
> 1. Process A initiates an ibm,activate-firmware sequence and receives a
>    "retry" status (-2/990x).
> 2. Process B calls ibm,activate-firmware and receives the "done" status
>    (0), concluding the sequence A began.
> 3. Process A, unaware of B, calls ibm,activate-firmware again,
>    inadvertently beginning a new sequence.
>

So this patch won't protect us against a parallel userspace invocation.
We can add static bool call_in_progress to track the ongoing
ibm,activate-firmware call from userspace? My only concern is we are
adding locks to protect against parallel calls in the kernel, but at the
same time, we ignore any userspace call regarding the same. We should at
least document this if this is not important to be fixed.

-aneesh

  reply	other threads:[~2023-11-28 15:47 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-18  5:14 [PATCH v4 00/13] powerpc/pseries: New character devices for system parameters and VPD Nathan Lynch via B4 Relay
2023-11-18  5:14 ` [PATCH v4 01/13] powerpc/rtas: Add for_each_rtas_function() iterator Nathan Lynch via B4 Relay
2023-11-20  8:07   ` Aneesh Kumar K.V
2023-11-18  5:14 ` [PATCH v4 02/13] powerpc/rtas: Fall back to linear search on failed token->function lookup Nathan Lynch via B4 Relay
2023-11-20  8:07   ` Aneesh Kumar K.V
2023-11-18  5:14 ` [PATCH v4 03/13] powerpc/rtas: Add function return status constants Nathan Lynch via B4 Relay
2023-11-20  8:08   ` Aneesh Kumar K.V
2023-11-18  5:14 ` [PATCH v4 04/13] powerpc/rtas: Factor out function descriptor lookup Nathan Lynch via B4 Relay
2023-11-20  8:08   ` Aneesh Kumar K.V
2023-11-18  5:14 ` [PATCH v4 05/13] powerpc/rtas: Facilitate high-level call sequences Nathan Lynch via B4 Relay
2023-11-20  8:10   ` Aneesh Kumar K.V
2023-11-28 15:35     ` Nathan Lynch
2023-11-28 22:30   ` Michael Ellerman
2023-11-28 23:05     ` Nathan Lynch
2023-11-29 13:20       ` Michael Ellerman
2023-11-30 18:26         ` Nathan Lynch
2023-11-30 21:41           ` Nathan Lynch
2023-11-30 22:46           ` Michael Ellerman
2023-11-30 23:53             ` Nathan Lynch
2023-12-05 16:51               ` Nathan Lynch
2023-12-07  1:02                 ` Michael Ellerman
2023-11-29  2:11   ` Michael Ellerman
2023-11-29  2:37     ` Nathan Lynch
2023-11-29  3:16       ` Michael Ellerman
2023-11-18  5:14 ` [PATCH v4 06/13] powerpc/rtas: Serialize firmware activation sequences Nathan Lynch via B4 Relay
2023-11-20  8:12   ` Aneesh Kumar K.V
2023-11-28 15:32     ` Nathan Lynch
2023-11-28 15:46       ` Aneesh Kumar K.V [this message]
2023-11-28 16:16         ` Nathan Lynch
2023-11-28 16:41           ` Nathan Lynch
2023-11-18  5:14 ` [PATCH v4 07/13] powerpc/rtas: Warn if per-function lock isn't held Nathan Lynch via B4 Relay
2023-11-20  8:13   ` Aneesh Kumar K.V
2023-11-18  5:14 ` [PATCH v4 08/13] powerpc/uapi: Export papr-miscdev.h header Nathan Lynch via B4 Relay
2023-11-18  5:14 ` [PATCH v4 09/13] powerpc/pseries: Add papr-vpd character driver for VPD retrieval Nathan Lynch via B4 Relay
2023-11-21  8:31   ` Michal Suchánek
2023-11-28 15:38     ` Nathan Lynch
2023-11-29  2:07   ` Michael Ellerman
2023-11-29  2:41     ` Nathan Lynch
2023-11-29  3:13       ` Michael Ellerman
2023-11-18  5:14 ` [PATCH v4 10/13] powerpc/pseries/papr-sysparm: Validate buffer object lengths Nathan Lynch via B4 Relay
2023-11-18  5:14 ` [PATCH v4 11/13] powerpc/pseries/papr-sysparm: Expose character device to user space Nathan Lynch via B4 Relay
2023-11-18  5:14 ` [PATCH v4 12/13] powerpc/selftests: Add test for papr-vpd Nathan Lynch via B4 Relay
2023-11-18  5:14 ` [PATCH v4 13/13] powerpc/selftests: Add test for papr-sysparm Nathan Lynch via B4 Relay
2023-11-29  1:08   ` Michael Ellerman

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=875y1lev8p.fsf@kernel.org \
    --to=aneesh.kumar@kernel.org \
    --cc=devnull+nathanl.linux.ibm.com@kernel.org \
    --cc=gcwilson@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=msuchanek@suse.de \
    --cc=nathanl@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=tyreld@linux.ibm.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 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).