[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1AE640813FDE7649BE1B193DEA596E886A25A596@SHSMSX101.ccr.corp.intel.com>
Date: Wed, 26 Oct 2016 06:17:08 +0000
From: "Zheng, Lv" <lv.zheng@...el.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>,
Lv Zheng <zetalog@...il.com>
CC: "Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
"Brown, Len" <len.brown@...el.com>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>
Subject: RE: [PATCH 0/6] ACPICA: Interpreter: Improve lock order fixes
Hi, Rafael
> From: linux-acpi-owner@...r.kernel.org [mailto:linux-acpi-owner@...r.kernel.org] On Behalf Of Rafael J.
> Wysocki
> Subject: Re: [PATCH 0/6] ACPICA: Interpreter: Improve lock order fixes
>
> On Tue, Oct 25, 2016 at 7:20 AM, Lv Zheng <zetalog@...il.com> wrote:
> > This patchset improves ACPICA intepreter lock order fixes. Including
> > several urgent regression fixes [PATCH 0-3].
>
> OK, thanks!
>
> So patches [4-6/6] appear to be cleanups and I'd prefer them to be
> applied in a usual way (ie. via the upstream ACPICA).
I think PATCH 4 is also an urgent fix.
On certain table loading mode (we have 3 now).
When acpi_ds_initialize_objects() is invoked, acpi_ds_initialize_region() will be invoked.
While in other modes, it will be invoked in acpi_ds_load2_end_op(), so no-op in acpi_ds_initialize_objects().
When it is not no-op in acpi_ds_initialize_objects(), the wrong returning value becomes an exception preventing the table from being correctly loaded/initialized.
[PATCH 5-6] are cleanups.
>
> I'd like to take the [1-3/6] as fixes for 4.9-rc3 though, but for that
> I need you to tell me which mainline kernel commits are fixed by them.
>
> IOW, what should I put into the Fixes: tags.
>
> [In the future, if you post a regression fix, please always add a
> FIxes: tag to it pointing to the commit being fixed.]
OK, I'll add the Fixes tag and re-send the patches.
Thanks and best regards
Lv
>
> > Patches tested with customized ACPI table where _PS0/_PS3 methods are
> > customized to invoke a serialized control method which creates named
> > objects. When pm_async=yes, AE_ALREADY_EXISTS can be seen in suspend/resume
> > process. This is an existing issue, triggered in 4.9-rc1 by ACPICA
> > interpreter lock order fixes, and can be fixed by [PATCH 1] in this series.
> >
> > Lv Zheng (6):
> > ACPICA: Dispatcher: Fix order issue of method termination
> > ACPICA: Dispatcher: Fix an unbalanced lock exit path in
> > acpi_ds_auto_serialize_method()
> > ACPICA: Dispatcher: Tune interpreter lock around
> > acpi_ev_initialize_region()
> > ACPICA: Events: Cleanup acpi_ev_initialize_region()
> > ACPICA: Tables: Cleanup acpi_tb_install_and_load_table()
> > ACPICA: Tables: Add acpi_tb_unload_table()
>
> Thanks,
> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists