| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 30 Jun 2020 13:44:52 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Al Stone <ahs3@...hat.com>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Dan Williams <dan.j.williams@...el.com>,
Erik Kaneda <erik.kaneda@...el.com>,
Rafael Wysocki <rafael.j.wysocki@...el.com>,
Len Brown <lenb@...nel.org>, Borislav Petkov <bp@...en8.de>,
Ira Weiny <ira.weiny@...el.com>,
James Morse <james.morse@....com>,
Myron Stowe <myron.stowe@...hat.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
Bob Moore <robert.moore@...el.com>
Subject: Re: [PATCH v4 2/2] ACPICA: Preserve memory opregion mappings
On Mon, Jun 29, 2020 at 10:57 PM Al Stone <ahs3@...hat.com> wrote:
>
> On 29 Jun 2020 18:33, Rafael J. Wysocki wrote:
> > From: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
> >
> > The ACPICA's strategy with respect to the handling of memory mappings
> > associated with memory operation regions is to avoid mapping the
> > entire region at once which may be problematic at least in principle
> > (for example, it may lead to conflicts with overlapping mappings
> > having different attributes created by drivers). It may also be
> > wasteful, because memory opregions on some systems take up vast
> > chunks of address space while the fields in those regions actually
> > accessed by AML are sparsely distributed.
> >
> > For this reason, a one-page "window" is mapped for a given opregion
> > on the first memory access through it and if that "window" does not
> > cover an address range accessed through that opregion subsequently,
> > it is unmapped and a new "window" is mapped to replace it. Next,
> > if the new "window" is not sufficient to acess memory through the
> > opregion in question in the future, it will be replaced with yet
> > another "window" and so on. That may lead to a suboptimal sequence
> > of memory mapping and unmapping operations, for example if two fields
> > in one opregion separated from each other by a sufficiently wide
> > chunk of unused address space are accessed in an alternating pattern.
> >
> > The situation may still be suboptimal if the deferred unmapping
> > introduced previously is supported by the OS layer. For instance,
> > the alternating memory access pattern mentioned above may produce
> > a relatively long list of mappings to release with substantial
> > duplication among the entries in it, which could be avoided if
> > acpi_ex_system_memory_space_handler() did not release the mapping
> > used by it previously as soon as the current access was not covered
> > by it.
> >
> > In order to improve that, modify acpi_ex_system_memory_space_handler()
> > to preserve all of the memory mappings created by it until the memory
> > regions associated with them go away.
> >
> > Accordingly, update acpi_ev_system_memory_region_setup() to unmap all
> > memory associated with memory opregions that go away.
> >
> > Reported-by: Dan Williams <dan.j.williams@...el.com>
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > ---
> > drivers/acpi/acpica/evrgnini.c | 14 ++++----
> > drivers/acpi/acpica/exregion.c | 65 ++++++++++++++++++++++++----------
> > include/acpi/actypes.h | 12 +++++--
> > 3 files changed, 64 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/acpi/acpica/evrgnini.c b/drivers/acpi/acpica/evrgnini.c
> > index aefc0145e583..89be3ccdad53 100644
> > --- a/drivers/acpi/acpica/evrgnini.c
> > +++ b/drivers/acpi/acpica/evrgnini.c
> > @@ -38,6 +38,7 @@ acpi_ev_system_memory_region_setup(acpi_handle handle,
> > union acpi_operand_object *region_desc =
> > (union acpi_operand_object *)handle;
> > struct acpi_mem_space_context *local_region_context;
> > + struct acpi_mem_mapping *mm;
> >
> > ACPI_FUNCTION_TRACE(ev_system_memory_region_setup);
> >
> > @@ -46,13 +47,14 @@ acpi_ev_system_memory_region_setup(acpi_handle handle,
> > local_region_context =
> > (struct acpi_mem_space_context *)*region_context;
> >
> > - /* Delete a cached mapping if present */
> > + /* Delete memory mappings if present */
> >
> > - if (local_region_context->mapped_length) {
> > - acpi_os_unmap_memory(local_region_context->
> > - mapped_logical_address,
> > - local_region_context->
> > - mapped_length);
> > + while (local_region_context->first_mm) {
> > + mm = local_region_context->first_mm;
> > + local_region_context->first_mm = mm->next_mm;
> > + acpi_os_unmap_memory(mm->logical_address,
> > + mm->length);
> > + ACPI_FREE(mm);
> > }
> > ACPI_FREE(local_region_context);
> > *region_context = NULL;
> > diff --git a/drivers/acpi/acpica/exregion.c b/drivers/acpi/acpica/exregion.c
> > index d15a66de26c0..fd68f2134804 100644
> > --- a/drivers/acpi/acpica/exregion.c
> > +++ b/drivers/acpi/acpica/exregion.c
> > @@ -41,6 +41,7 @@ acpi_ex_system_memory_space_handler(u32 function,
> > acpi_status status = AE_OK;
> > void *logical_addr_ptr = NULL;
> > struct acpi_mem_space_context *mem_info = region_context;
> > + struct acpi_mem_mapping *mm = mem_info->cur_mm;
> > u32 length;
> > acpi_size map_length;
>
> I think this needs to be:
>
> acpi_size map_length = mem_info->length;
>
> since it now gets used in the ACPI_ERROR() call below.
No, it's better to print the length value in the message.
> I'm getting a "maybe used unitialized" error on compilation.
Thanks for reporting!
I've updated the commit in the acpica-osl branch with the fix.
Powered by blists - more mailing lists