linux-kernel - Re: [PATCH] x86: copy srat table and unmap in acpi_parse

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]

Date:	Thu, 17 Jan 2008 21:43:43 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Yinghai Lu <Yinghai.Lu@....COM>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: copy srat table and unmap in acpi_parse_table


* Yinghai Lu <Yinghai.Lu@....COM> wrote:

> [PATCH] x86: copy srat table and unmap in acpi_parse_table
> 
> 
> the old acpi_numa_slit_init was saving old address in early stage 
> acpi_slit and acpi_parse_table can not unmap address that. the patch 
> copy the slit in the callback, so we could unmap table in 
> acpi_parse_table instead of outside track it.
> 
> need to revert
> "
> commit d8d28f25f33c6a035cdfb1d421c79293d16e5c58
> Author: Ingo Molnar <mingo@...e.hu>
> Date:   Thu Jan 17 15:26:42 2008 +0100
> 
>     x86: ACPI: fix mapping leaks
> 
>     ioremap_early() is stateful, hence we cannot tolerate mapping leaks.
> "
> 
> before appling this patch

do you mean your patch should be applied first, then the 
d8d28f25f33c6a03 patch should applied as second?

Or if d8d28f25f33c6a03 really needs to be reverted to get your system to 
boot properly, which particular bit of it was causing trouble for you? 
(or the whole thing?)

	Ingo
--
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/