Re: [PATCH 4.17 55/66] ACPICA: AML Parser: ignore dispatcher error status during table load

["Rafael J. Wysocki" <rafael.j.wysocki@intel.com>]

On 7/27/2018 11:45 AM, Greg Kroah-Hartman wrote:
> 4.17-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Schmauss, Erik <erik.schmauss@intel.com>
>
> commit 73c2a01c52b657f4a0ead6c95f64c5279efbd000 upstream.
>
> The dispatcher and the executer process the parse nodes During table
> load. Error status from the evaluation confuses the AML parser. This
> results in the parser failing to complete parsing of the current
> scope op which becomes problematic. For the incorrect AML below, _ADR
> never gets created.
>
> definition_block(...)
> {
>     Scope (\_SB)
>     {
>       Device (PCI0){...}
>       Name (OBJ1, 0x0)
>       OBJ1 = PCI0 + 5 // Results in an operand error.
>     } // \_SB not closed
>
>     // parser looks for \_SB._SB.PCI0, results in AE_NOT_FOUND error
>     // Entire scope block gets skipped.
>     Scope (\_SB.PCI0)
>     {
>         Name (_ADR, 0x0)
>     }
> }
>
> Fix the above error by properly completing the initial \_SB scope
> after an error by clearing errors that occur during table load. In
> the above case, this means that OBJ1 = PIC0 + 5 is skipped.
>
> Fixes: 5088814a6e93 (ACPICA: AML parser: attempt to continue loading table after error)
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=200363
> Tested-by: Bastien Nocera <hadess@hadess.net>
> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
> Cc: 4.17+ <stable@vger.kernel.org> # 4.17+
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Has this gone in already?  If not, please hold on.

There is a fix on top of this that will go to Linus tomorrow: 
https://patchwork.kernel.org/patch/10548059/

> ---
>   drivers/acpi/acpica/psloop.c |   26 ++++++++++++++++++++++++++
>   1 file changed, 26 insertions(+)
>
> --- a/drivers/acpi/acpica/psloop.c
> +++ b/drivers/acpi/acpica/psloop.c
> @@ -497,6 +497,18 @@ acpi_status acpi_ps_parse_loop(struct ac
>   			status =
>   			    acpi_ps_create_op(walk_state, aml_op_start, &op);
>   			if (ACPI_FAILURE(status)) {
> +				/*
> +				 * ACPI_PARSE_MODULE_LEVEL means that we are loading a table by
> +				 * executing it as a control method. However, if we encounter
> +				 * an error while loading the table, we need to keep trying to
> +				 * load the table rather than aborting the table load. Set the
> +				 * status to AE_OK to proceed with the table load.
> +				 */
> +				if ((walk_state->
> +				     parse_flags & ACPI_PARSE_MODULE_LEVEL)
> +				    && status == AE_ALREADY_EXISTS) {
> +					status = AE_OK;
> +				}
>   				if (status == AE_CTRL_PARSE_CONTINUE) {
>   					continue;
>   				}
> @@ -694,6 +706,20 @@ acpi_status acpi_ps_parse_loop(struct ac
>   			    acpi_ps_next_parse_state(walk_state, op, status);
>   			if (status == AE_CTRL_PENDING) {
>   				status = AE_OK;
> +			} else
> +			    if ((walk_state->
> +				 parse_flags & ACPI_PARSE_MODULE_LEVEL)
> +				&& ACPI_FAILURE(status)) {
> +				/*
> +				 * ACPI_PARSE_MODULE_LEVEL means that we are loading a table by
> +				 * executing it as a control method. However, if we encounter
> +				 * an error while loading the table, we need to keep trying to
> +				 * load the table rather than aborting the table load. Set the
> +				 * status to AE_OK to proceed with the table load. If we get a
> +				 * failure at this point, it means that the dispatcher got an
> +				 * error while processing Op (most likely an AML operand error.
> +				 */
> +				status = AE_OK;
>   			}
>   		}
>   
>
>