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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAErSpo71XHyuji1HxZwShtg-YQCavgkgcdH23ic38q3COB3MgQ@mail.gmail.com>
Date:	Mon, 22 Aug 2011 10:45:03 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Huang Ying <ying.huang@...el.com>
Cc:	Pavel Ivanov <paivanof@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	Yinghai Lu <yinghai@...nel.org>
Subject: Re: APEI: Can not request iomem region for GARs

On Mon, Aug 22, 2011 at 1:12 AM, Huang Ying <ying.huang@...el.com> wrote:
> Do you have time to try the patch attached with the mail?
> acpi_nvs.patch should go first.

I'm sure these patches make the messages go away, but I think this is
the wrong way to fix the problem.

We mark things "busy" in the resource trees as a mutual exclusion
mechanism -- normally when a driver claims a resource and nothing else
should be allowed to touch it.

e820_reserve_resources() marks everything (except "reserved" regions)
as busy.  That probably makes sense for available RAM, since RAM is
allocated and managed via other mechanisms.  But I think it's wrong in
this case because e820 is not a driver that is using the ACPI NVS
region.

In this case, we have an ACPI NVS region, and the APEI code is
essentially a driver for some registers that reside there.  APEI is
the entity that manages those registers, and it needs to enforce
mutual exclusion so nobody else touches them behind its back, so I
think it makes sense for it to request the register regions and mark
them busy.

My proposal is to change e820 so it either leaves ACPI NVS out of the
iomem_resource tree or puts it in but leaves it non-busy.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ