[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <A5ED84D3BB3A384992CBB9C77DEDA4D414A520D4@USINDEM103.corp.hds.com>
Date: Wed, 23 Jan 2013 00:44:19 +0000
From: Seiji Aguchi <seiji.aguchi@....com>
To: Huang Ying <ying.huang@...el.com>
CC: "rjw@...k.pl" <rjw@...k.pl>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"H. Peter Anvin (hpa@...or.com)" <hpa@...or.com>,
"robert.moore@...el.com" <robert.moore@...el.com>,
"trenn@...e.de" <trenn@...e.de>,
"myron.stowe@...hat.com" <myron.stowe@...hat.com>
Subject: RE: ERST: how to avoid a dynamic memory allocation in panic case
> > <snip>
> > @@ -918,10 +918,7 @@ acpi_os_read_memory(acpi_physical_address phys_addr, u64 *value, u32 width)
> > virt_addr = acpi_map_vaddr_lookup(phys_addr, size);
> > if (!virt_addr) {
> > rcu_read_unlock();
> > - virt_addr = acpi_os_ioremap(phys_addr, size);
> > - if (!virt_addr)
> > - return AE_BAD_ADDRESS;
> > - unmap = true;
> > + return AE_BAD_ADDRESS;
>
> No. We can not do that. Because some users rely on acpi_os_read_memory to do ioremap for them.
Thank you for giving me the information.
> The correct fixing should be pre-map the io-memory that may be accessed in erst code patch with acpi_map().
I will take a look at the code.
Seiji
Powered by blists - more mailing lists