linux-kernel - Re: [PATCH 12/21] x86, acpi: Try to find if SRAT is overrided earlier.

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: <20130723202746.GQ21100@mtj.dyndns.org>
Date:	Tue, 23 Jul 2013 16:27:46 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Tang Chen <tangchen@...fujitsu.com>
Cc:	tglx@...utronix.de, mingo@...e.hu, hpa@...or.com,
	akpm@...ux-foundation.org, trenn@...e.de, yinghai@...nel.org,
	jiang.liu@...wei.com, wency@...fujitsu.com, laijs@...fujitsu.com,
	isimatu.yasuaki@...fujitsu.com, izumi.taku@...fujitsu.com,
	mgorman@...e.de, minchan@...nel.org, mina86@...a86.com,
	gong.chen@...ux.intel.com, vasilis.liaskovitis@...fitbricks.com,
	lwoodman@...hat.com, riel@...hat.com, jweiner@...hat.com,
	prarit@...hat.com, zhangyanfei@...fujitsu.com,
	yanghy@...fujitsu.com, x86@...nel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	linux-acpi@...r.kernel.org
Subject: Re: [PATCH 12/21] x86, acpi: Try to find if SRAT is overrided
 earlier.

On Fri, Jul 19, 2013 at 03:59:25PM +0800, Tang Chen wrote:
> As we mentioned in previous patches, to prevent the kernel

Prolly best to briefly describe what the overall goal is about.

> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 28d2e60..9717760 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -1078,6 +1078,15 @@ void __init setup_arch(char **cmdline_p)
>  	/* Initialize ACPI root table */
>  	acpi_root_table_init();
>  
> +#ifdef CONFIG_ACPI_NUMA
> +	/*
> +	 * Linux kernel cannot migrate kernel pages, as a result, memory used
> +	 * by the kernel cannot be hot-removed. Reserve hotpluggable memory to
> +	 * prevent memblock from allocating hotpluggable memory for the kernel.
> +	 */
> +	reserve_hotpluggable_memory();
> +#endif

Hmmm, so you're gonna reserve all hotpluggable memory areas until
everything is up and running, which probably is why allocating
node_data on hotpluggable node doesn't work, right?

> +#ifdef CONFIG_ACPI_NUMA
> +/*

/**

> + * early_acpi_override_srat - Try to get the phys addr of SRAT in initrd.
> + *
> + * The ACPI_INITRD_TABLE_OVERRIDE procedure is able to use tables in initrd
> + * file to override the ones provided by firmware. This function checks if
> + * there is a SRAT in initrd at early time. If so, return the phys addr of
> + * the SRAT.
> + *
> + * Return the phys addr of SRAT in initrd, 0 if there is no SRAT.
> + */
> +phys_addr_t __init early_acpi_override_srat(void)
> +{
> +	int i;
> +	u32 length;
> +	long offset;
> +	void *ramdisk_vaddr;
> +	struct acpi_table_header *table;
> +	unsigned long map_step = NR_FIX_BTMAPS << PAGE_SHIFT;
> +	phys_addr_t ramdisk_image = get_ramdisk_image();
> +	char cpio_path[32] = "kernel/firmware/acpi/";
> +	struct cpio_data file;

Don't we usually put variable declarations with initializers before
others?  For some reason, the above block is painful to look at.

> +	/* Try to find if SRAT is overrided */
                                  ^
                                  overridden?

...
> +#ifdef CONFIG_ACPI_NUMA
> +/*

/**

> + * reserve_hotpluggable_memory - Reserve hotpluggable memory in memblock.
> + *
> + * This function did the following:
> + * 1. Try to find if there is a SRAT in initrd file used to override the one
> + *    provided by firmware. If so, get its phys addr.
> + * 2. If there is no override SRAT, get the phys addr of the SRAT in firmware.
> + * 3. Parse SRAT, find out which memory is hotpluggable, and reserve it in
> + *    memblock.
> + */
> +void __init reserve_hotpluggable_memory(void)

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