All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Tang Chen <tangchen@cn.fujitsu.com>
Cc: rientjes@google.com, len.brown@intel.com,
	benh@kernel.crashing.org, paulus@samba.org, cl@linux.com,
	minchan.kim@gmail.com, kosaki.motohiro@jp.fujitsu.com,
	isimatu.yasuaki@jp.fujitsu.com, wujianguo@huawei.com,
	wency@cn.fujitsu.com, hpa@zytor.com, linfeng@cn.fujitsu.com,
	laijs@cn.fujitsu.com, mgorman@suse.de, yinghai@kernel.org,
	glommer@parallels.com, x86@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-acpi@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-sh@vger.kernel.org, linux-ia64@vger.kernel.org,
	cmetcalf@tilera.com, sparclinux@vger.kernel.org
Subject: Re: [PATCH v6 04/15] memory-hotplug: remove /sys/firmware/memmap/X sysfs
Date: Wed, 9 Jan 2013 15:19:20 -0800	[thread overview]
Message-ID: <20130109151920.fb9b4029.akpm@linux-foundation.org> (raw)
In-Reply-To: <1357723959-5416-5-git-send-email-tangchen@cn.fujitsu.com>

On Wed, 9 Jan 2013 17:32:28 +0800
Tang Chen <tangchen@cn.fujitsu.com> wrote:

> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> 
> When (hot)adding memory into system, /sys/firmware/memmap/X/{end, start, type}
> sysfs files are created. But there is no code to remove these files. The patch
> implements the function to remove them.
> 
> Note: The code does not free firmware_map_entry which is allocated by bootmem.
>       So the patch makes memory leak. But I think the memory leak size is
>       very samll. And it does not affect the system.
> 
> ...
>
> +static struct firmware_map_entry * __meminit
> +firmware_map_find_entry(u64 start, u64 end, const char *type)
> +{
> +	struct firmware_map_entry *entry;
> +
> +	spin_lock(&map_entries_lock);
> +	list_for_each_entry(entry, &map_entries, list)
> +		if ((entry->start == start) && (entry->end == end) &&
> +		    (!strcmp(entry->type, type))) {
> +			spin_unlock(&map_entries_lock);
> +			return entry;
> +		}
> +
> +	spin_unlock(&map_entries_lock);
> +	return NULL;
> +}
>
> ...
>
> +	entry = firmware_map_find_entry(start, end - 1, type);
> +	if (!entry)
> +		return -EINVAL;
> +
> +	firmware_map_remove_entry(entry);
>
> ...
>

The above code looks racy.  After firmware_map_find_entry() does the
spin_unlock() there is nothing to prevent a concurrent
firmware_map_remove_entry() from removing the entry, so the kernel ends
up calling firmware_map_remove_entry() twice against the same entry.

An easy fix for this is to hold the spinlock across the entire
lookup/remove operation.


This problem is inherent to firmware_map_find_entry() as you have
implemented it, so this function simply should not exist in the current
form - no caller can use it without being buggy!  A simple fix for this
is to remove the spin_lock()/spin_unlock() from
firmware_map_find_entry() and add locking documentation to
firmware_map_find_entry(), explaining that the caller must hold
map_entries_lock and must not release that lock until processing of
firmware_map_find_entry()'s return value has completed.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Tang Chen <tangchen@cn.fujitsu.com>
Cc: rientjes@google.com, len.brown@intel.com,
	benh@kernel.crashing.org, paulus@samba.org, cl@linux.com,
	minchan.kim@gmail.com, kosaki.motohiro@jp.fujitsu.com,
	isimatu.yasuaki@jp.fujitsu.com, wujianguo@huawei.com,
	wency@cn.fujitsu.com, hpa@zytor.com, linfeng@cn.fujitsu.com,
	laijs@cn.fujitsu.com, mgorman@suse.de, yinghai@kernel.org,
	glommer@parallels.com, x86@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-acpi@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-sh@vger.kernel.org, linux-ia64@vger.kernel.org,
	cmetcalf@tilera.com, sparclinux@vger.kernel.org
Subject: Re: [PATCH v6 04/15] memory-hotplug: remove /sys/firmware/memmap/X sysfs
Date: Wed, 09 Jan 2013 23:19:20 +0000	[thread overview]
Message-ID: <20130109151920.fb9b4029.akpm@linux-foundation.org> (raw)
In-Reply-To: <1357723959-5416-5-git-send-email-tangchen@cn.fujitsu.com>

On Wed, 9 Jan 2013 17:32:28 +0800
Tang Chen <tangchen@cn.fujitsu.com> wrote:

> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> 
> When (hot)adding memory into system, /sys/firmware/memmap/X/{end, start, type}
> sysfs files are created. But there is no code to remove these files. The patch
> implements the function to remove them.
> 
> Note: The code does not free firmware_map_entry which is allocated by bootmem.
>       So the patch makes memory leak. But I think the memory leak size is
>       very samll. And it does not affect the system.
> 
> ...
>
> +static struct firmware_map_entry * __meminit
> +firmware_map_find_entry(u64 start, u64 end, const char *type)
> +{
> +	struct firmware_map_entry *entry;
> +
> +	spin_lock(&map_entries_lock);
> +	list_for_each_entry(entry, &map_entries, list)
> +		if ((entry->start = start) && (entry->end = end) &&
> +		    (!strcmp(entry->type, type))) {
> +			spin_unlock(&map_entries_lock);
> +			return entry;
> +		}
> +
> +	spin_unlock(&map_entries_lock);
> +	return NULL;
> +}
>
> ...
>
> +	entry = firmware_map_find_entry(start, end - 1, type);
> +	if (!entry)
> +		return -EINVAL;
> +
> +	firmware_map_remove_entry(entry);
>
> ...
>

The above code looks racy.  After firmware_map_find_entry() does the
spin_unlock() there is nothing to prevent a concurrent
firmware_map_remove_entry() from removing the entry, so the kernel ends
up calling firmware_map_remove_entry() twice against the same entry.

An easy fix for this is to hold the spinlock across the entire
lookup/remove operation.


This problem is inherent to firmware_map_find_entry() as you have
implemented it, so this function simply should not exist in the current
form - no caller can use it without being buggy!  A simple fix for this
is to remove the spin_lock()/spin_unlock() from
firmware_map_find_entry() and add locking documentation to
firmware_map_find_entry(), explaining that the caller must hold
map_entries_lock and must not release that lock until processing of
firmware_map_find_entry()'s return value has completed.

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Tang Chen <tangchen@cn.fujitsu.com>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-mm@kvack.org, paulus@samba.org, hpa@zytor.com,
	sparclinux@vger.kernel.org, cl@linux.com,
	linux-s390@vger.kernel.org, x86@kernel.org,
	linux-acpi@vger.kernel.org, isimatu.yasuaki@jp.fujitsu.com,
	linfeng@cn.fujitsu.com, mgorman@suse.de,
	kosaki.motohiro@jp.fujitsu.com, rientjes@google.com,
	len.brown@intel.com, wency@cn.fujitsu.com, cmetcalf@tilera.com,
	glommer@parallels.com, wujianguo@huawei.com, yinghai@kernel.org,
	laijs@cn.fujitsu.com, linux-kernel@vger.kernel.org,
	minchan.kim@gmail.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v6 04/15] memory-hotplug: remove /sys/firmware/memmap/X sysfs
Date: Wed, 9 Jan 2013 15:19:20 -0800	[thread overview]
Message-ID: <20130109151920.fb9b4029.akpm@linux-foundation.org> (raw)
In-Reply-To: <1357723959-5416-5-git-send-email-tangchen@cn.fujitsu.com>

On Wed, 9 Jan 2013 17:32:28 +0800
Tang Chen <tangchen@cn.fujitsu.com> wrote:

> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> 
> When (hot)adding memory into system, /sys/firmware/memmap/X/{end, start, type}
> sysfs files are created. But there is no code to remove these files. The patch
> implements the function to remove them.
> 
> Note: The code does not free firmware_map_entry which is allocated by bootmem.
>       So the patch makes memory leak. But I think the memory leak size is
>       very samll. And it does not affect the system.
> 
> ...
>
> +static struct firmware_map_entry * __meminit
> +firmware_map_find_entry(u64 start, u64 end, const char *type)
> +{
> +	struct firmware_map_entry *entry;
> +
> +	spin_lock(&map_entries_lock);
> +	list_for_each_entry(entry, &map_entries, list)
> +		if ((entry->start == start) && (entry->end == end) &&
> +		    (!strcmp(entry->type, type))) {
> +			spin_unlock(&map_entries_lock);
> +			return entry;
> +		}
> +
> +	spin_unlock(&map_entries_lock);
> +	return NULL;
> +}
>
> ...
>
> +	entry = firmware_map_find_entry(start, end - 1, type);
> +	if (!entry)
> +		return -EINVAL;
> +
> +	firmware_map_remove_entry(entry);
>
> ...
>

The above code looks racy.  After firmware_map_find_entry() does the
spin_unlock() there is nothing to prevent a concurrent
firmware_map_remove_entry() from removing the entry, so the kernel ends
up calling firmware_map_remove_entry() twice against the same entry.

An easy fix for this is to hold the spinlock across the entire
lookup/remove operation.


This problem is inherent to firmware_map_find_entry() as you have
implemented it, so this function simply should not exist in the current
form - no caller can use it without being buggy!  A simple fix for this
is to remove the spin_lock()/spin_unlock() from
firmware_map_find_entry() and add locking documentation to
firmware_map_find_entry(), explaining that the caller must hold
map_entries_lock and must not release that lock until processing of
firmware_map_find_entry()'s return value has completed.

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Tang Chen <tangchen@cn.fujitsu.com>
Cc: rientjes@google.com, len.brown@intel.com,
	benh@kernel.crashing.org, paulus@samba.org, cl@linux.com,
	minchan.kim@gmail.com, kosaki.motohiro@jp.fujitsu.com,
	isimatu.yasuaki@jp.fujitsu.com, wujianguo@huawei.com,
	wency@cn.fujitsu.com, hpa@zytor.com, linfeng@cn.fujitsu.com,
	laijs@cn.fujitsu.com, mgorman@suse.de, yinghai@kernel.org,
	glommer@parallels.com, x86@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-acpi@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-sh@vger.kernel.org, linux-ia64@vger.kernel.org,
	cmetcalf@tilera.com, sparclinux@vger.kernel.org
Subject: Re: [PATCH v6 04/15] memory-hotplug: remove /sys/firmware/memmap/X sysfs
Date: Wed, 9 Jan 2013 15:19:20 -0800	[thread overview]
Message-ID: <20130109151920.fb9b4029.akpm@linux-foundation.org> (raw)
In-Reply-To: <1357723959-5416-5-git-send-email-tangchen@cn.fujitsu.com>

On Wed, 9 Jan 2013 17:32:28 +0800
Tang Chen <tangchen@cn.fujitsu.com> wrote:

> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> 
> When (hot)adding memory into system, /sys/firmware/memmap/X/{end, start, type}
> sysfs files are created. But there is no code to remove these files. The patch
> implements the function to remove them.
> 
> Note: The code does not free firmware_map_entry which is allocated by bootmem.
>       So the patch makes memory leak. But I think the memory leak size is
>       very samll. And it does not affect the system.
> 
> ...
>
> +static struct firmware_map_entry * __meminit
> +firmware_map_find_entry(u64 start, u64 end, const char *type)
> +{
> +	struct firmware_map_entry *entry;
> +
> +	spin_lock(&map_entries_lock);
> +	list_for_each_entry(entry, &map_entries, list)
> +		if ((entry->start == start) && (entry->end == end) &&
> +		    (!strcmp(entry->type, type))) {
> +			spin_unlock(&map_entries_lock);
> +			return entry;
> +		}
> +
> +	spin_unlock(&map_entries_lock);
> +	return NULL;
> +}
>
> ...
>
> +	entry = firmware_map_find_entry(start, end - 1, type);
> +	if (!entry)
> +		return -EINVAL;
> +
> +	firmware_map_remove_entry(entry);
>
> ...
>

The above code looks racy.  After firmware_map_find_entry() does the
spin_unlock() there is nothing to prevent a concurrent
firmware_map_remove_entry() from removing the entry, so the kernel ends
up calling firmware_map_remove_entry() twice against the same entry.

An easy fix for this is to hold the spinlock across the entire
lookup/remove operation.


This problem is inherent to firmware_map_find_entry() as you have
implemented it, so this function simply should not exist in the current
form - no caller can use it without being buggy!  A simple fix for this
is to remove the spin_lock()/spin_unlock() from
firmware_map_find_entry() and add locking documentation to
firmware_map_find_entry(), explaining that the caller must hold
map_entries_lock and must not release that lock until processing of
firmware_map_find_entry()'s return value has completed.

  parent reply	other threads:[~2013-01-09 23:19 UTC|newest]

Thread overview: 270+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-09  9:32 [PATCH v6 00/15] memory-hotplug: hot-remove physical memory Tang Chen
2013-01-09  9:32 ` Tang Chen
2013-01-09  9:32 ` Tang Chen
2013-01-09  9:32 ` Tang Chen
2013-01-09  9:32 ` [PATCH v6 01/15] memory-hotplug: try to offline the memory twice to avoid dependence Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32 ` [PATCH v6 02/15] memory-hotplug: check whether all memory blocks are offlined or not when removing memory Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` [PATCH v6 02/15] memory-hotplug: check whether all memory blocks are offlined or not when removing m Tang Chen
2013-01-09 23:11   ` [PATCH v6 02/15] memory-hotplug: check whether all memory blocks are offlined or not when removing memory Andrew Morton
2013-01-09 23:11     ` Andrew Morton
2013-01-09 23:11     ` Andrew Morton
2013-01-09 23:11     ` [PATCH v6 02/15] memory-hotplug: check whether all memory blocks are offlined or not when removi Andrew Morton
2013-01-10  5:56     ` [PATCH v6 02/15] memory-hotplug: check whether all memory blocks are offlined or not when removing memory Tang Chen
2013-01-10  5:56       ` Tang Chen
2013-01-10  5:56       ` Tang Chen
2013-01-10  5:56       ` [PATCH v6 02/15] memory-hotplug: check whether all memory blocks are offlined or not when removi Tang Chen
2013-01-09  9:32 ` [PATCH v6 03/15] memory-hotplug: remove redundant codes Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32 ` [PATCH v6 04/15] memory-hotplug: remove /sys/firmware/memmap/X sysfs Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09 22:49   ` Andrew Morton
2013-01-09 22:49     ` Andrew Morton
2013-01-09 22:49     ` Andrew Morton
2013-01-09 22:49     ` Andrew Morton
2013-01-10  6:07     ` Tang Chen
2013-01-10  6:07       ` Tang Chen
2013-01-10  6:07       ` Tang Chen
2013-01-10  6:07       ` Tang Chen
2013-01-09 23:19   ` Andrew Morton [this message]
2013-01-09 23:19     ` Andrew Morton
2013-01-09 23:19     ` Andrew Morton
2013-01-09 23:19     ` Andrew Morton
2013-01-10  6:15     ` Tang Chen
2013-01-10  6:15       ` Tang Chen
2013-01-10  6:15       ` Tang Chen
2013-01-10  6:15       ` Tang Chen
2013-01-09  9:32 ` [PATCH v6 05/15] memory-hotplug: introduce new function arch_remove_memory() for removing page table depends on architecture Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` [PATCH v6 05/15] memory-hotplug: introduce new function arch_remove_memory() for removing page table Tang Chen
2013-01-09 22:50   ` [PATCH v6 05/15] memory-hotplug: introduce new function arch_remove_memory() for removing page table depends on architecture Andrew Morton
2013-01-09 22:50     ` Andrew Morton
2013-01-09 22:50     ` Andrew Morton
2013-01-09 22:50     ` [PATCH v6 05/15] memory-hotplug: introduce new function arch_remove_memory() for removing page t Andrew Morton
2013-01-10  2:25     ` [PATCH v6 05/15] memory-hotplug: introduce new function arch_remove_memory() for removing page table depends on architecture Tang Chen
2013-01-10  2:25       ` Tang Chen
2013-01-10  2:25       ` Tang Chen
2013-01-10  2:25       ` [PATCH v6 05/15] memory-hotplug: introduce new function arch_remove_memory() for removing page t Tang Chen
2013-01-09  9:32 ` [PATCH v6 06/15] memory-hotplug: implement register_page_bootmem_info_section of sparse-vmemmap Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32 ` [PATCH v6 07/15] memory-hotplug: move pgdat_resize_lock into sparse_remove_one_section() Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32 ` [PATCH v6 08/15] memory-hotplug: Common APIs to support page tables hot-remove Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-29 13:02   ` Simon Jeons
2013-01-29 13:02     ` Simon Jeons
2013-01-29 13:02     ` Simon Jeons
2013-01-29 13:02     ` Simon Jeons
2013-01-30  1:53     ` Jianguo Wu
2013-01-30  1:53       ` Jianguo Wu
2013-01-30  1:53       ` Jianguo Wu
2013-01-30  1:53       ` Jianguo Wu
2013-01-30  2:13       ` Simon Jeons
2013-01-30  2:13         ` Simon Jeons
2013-01-30  2:13         ` Simon Jeons
2013-01-30  2:13         ` Simon Jeons
2013-01-29 13:04   ` Simon Jeons
2013-01-29 13:04     ` Simon Jeons
2013-01-29 13:04     ` Simon Jeons
2013-01-29 13:04     ` Simon Jeons
2013-01-30  2:16     ` Tang Chen
2013-01-30  2:16       ` Tang Chen
2013-01-30  2:16       ` Tang Chen
2013-01-30  2:16       ` Tang Chen
2013-01-30  3:27       ` Simon Jeons
2013-01-30  3:27         ` Simon Jeons
2013-01-30  3:27         ` Simon Jeons
2013-01-30  3:27         ` Simon Jeons
2013-01-30  5:55         ` Tang Chen
2013-01-30  5:55           ` Tang Chen
2013-01-30  5:55           ` Tang Chen
2013-01-30  5:55           ` Tang Chen
2013-01-30  7:32           ` Simon Jeons
2013-01-30  7:32             ` Simon Jeons
2013-01-30  7:32             ` Simon Jeons
2013-01-30  7:32             ` Simon Jeons
2013-02-04 23:04   ` Andrew Morton
2013-02-04 23:04     ` Andrew Morton
2013-02-04 23:04     ` Andrew Morton
2013-02-04 23:04     ` Andrew Morton
2013-01-09  9:32 ` [PATCH v6 09/15] memory-hotplug: remove page table of x86_64 architecture Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32 ` [PATCH v6 10/15] memory-hotplug: remove memmap of sparse-vmemmap Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32 ` [PATCH v6 11/15] memory-hotplug: Integrated __remove_section() of CONFIG_SPARSEMEM_VMEMMAP Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32 ` [PATCH v6 12/15] memory-hotplug: memory_hotplug: clear zone when removing the memory Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32 ` [PATCH v6 13/15] memory-hotplug: remove sysfs file of node Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32 ` [PATCH v6 14/15] memory-hotplug: free node_data when a node is offlined Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32 ` [PATCH v6 15/15] memory-hotplug: Do not allocate pdgat if it was not freed when offline Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09  9:32   ` Tang Chen
2013-01-09 22:23 ` [PATCH v6 00/15] memory-hotplug: hot-remove physical memory Andrew Morton
2013-01-09 22:23   ` Andrew Morton
2013-01-09 22:23   ` Andrew Morton
2013-01-09 22:23   ` Andrew Morton
2013-01-10  2:17   ` Tang Chen
2013-01-10  2:17     ` Tang Chen
2013-01-10  2:17     ` Tang Chen
2013-01-10  2:17     ` Tang Chen
2013-01-10  7:14     ` Glauber Costa
2013-01-10  7:14       ` Glauber Costa
2013-01-10  7:14       ` Glauber Costa
2013-01-10  7:14       ` Glauber Costa
2013-01-10  7:31       ` Kamezawa Hiroyuki
2013-01-10  7:31         ` Kamezawa Hiroyuki
2013-01-10  7:31         ` Kamezawa Hiroyuki
2013-01-10  7:31         ` Kamezawa Hiroyuki
2013-01-10  7:55         ` Glauber Costa
2013-01-10  7:55           ` Glauber Costa
2013-01-10  7:55           ` Glauber Costa
2013-01-10  7:55           ` Glauber Costa
2013-01-10  7:55           ` Glauber Costa
2013-01-10  8:23           ` Kamezawa Hiroyuki
2013-01-10  8:23             ` Kamezawa Hiroyuki
2013-01-10  8:23             ` Kamezawa Hiroyuki
2013-01-10  8:23             ` Kamezawa Hiroyuki
2013-01-10  8:36             ` Glauber Costa
2013-01-10  8:36               ` Glauber Costa
2013-01-10  8:36               ` Glauber Costa
2013-01-10  8:36               ` Glauber Costa
2013-01-10  8:36               ` Glauber Costa
2013-01-10  8:39               ` Kamezawa Hiroyuki
2013-01-10  8:39                 ` Kamezawa Hiroyuki
2013-01-10  8:39                 ` Kamezawa Hiroyuki
2013-01-10  8:39                 ` Kamezawa Hiroyuki
2013-01-09 23:33 ` Andrew Morton
2013-01-09 23:33   ` Andrew Morton
2013-01-09 23:33   ` Andrew Morton
2013-01-09 23:33   ` Andrew Morton
2013-01-10  2:18   ` Tang Chen
2013-01-10  2:18     ` Tang Chen
2013-01-10  2:18     ` Tang Chen
2013-01-10  2:18     ` Tang Chen
2013-01-29 12:52 ` Simon Jeons
2013-01-29 12:52   ` Simon Jeons
2013-01-29 12:52   ` Simon Jeons
2013-01-29 12:52   ` Simon Jeons
2013-01-30  2:32   ` Tang Chen
2013-01-30  2:32     ` Tang Chen
2013-01-30  2:32     ` Tang Chen
2013-01-30  2:32     ` Tang Chen
2013-01-30  2:48     ` Simon Jeons
2013-01-30  2:48       ` Simon Jeons
2013-01-30  2:48       ` Simon Jeons
2013-01-30  2:48       ` Simon Jeons
2013-01-30  3:00       ` Tang Chen
2013-01-30  3:00         ` Tang Chen
2013-01-30  3:00         ` Tang Chen
2013-01-30  3:00         ` Tang Chen
2013-01-30 10:15   ` Tang Chen
2013-01-30 10:15     ` Tang Chen
2013-01-30 10:15     ` Tang Chen
2013-01-30 10:15     ` Tang Chen
2013-01-30 10:18     ` Tang Chen
2013-01-30 10:18       ` Tang Chen
2013-01-30 10:18       ` Tang Chen
2013-01-30 10:18       ` Tang Chen
2013-01-31  1:22     ` Simon Jeons
2013-01-31  1:22       ` Simon Jeons
2013-01-31  1:22       ` Simon Jeons
2013-01-31  1:22       ` Simon Jeons
2013-01-31  3:31       ` Tang Chen
2013-01-31  3:31         ` Tang Chen
2013-01-31  3:31         ` Tang Chen
2013-01-31  3:31         ` Tang Chen
2013-01-31  6:19         ` Simon Jeons
2013-01-31  6:19           ` Simon Jeons
2013-01-31  6:19           ` Simon Jeons
2013-01-31  6:19           ` Simon Jeons
2013-01-31  7:10           ` Tang Chen
2013-01-31  7:10             ` Tang Chen
2013-01-31  7:10             ` Tang Chen
2013-01-31  7:10             ` Tang Chen
2013-01-31  8:17             ` Simon Jeons
2013-01-31  8:17               ` Simon Jeons
2013-01-31  8:17               ` Simon Jeons
2013-01-31  8:17               ` Simon Jeons
2013-01-31  8:48             ` Simon Jeons
2013-01-31  8:48               ` Simon Jeons
2013-01-31  8:48               ` Simon Jeons
2013-01-31  8:48               ` Simon Jeons
2013-01-31  9:44               ` Tang Chen
2013-01-31  9:44                 ` Tang Chen
2013-01-31  9:44                 ` Tang Chen
2013-01-31  9:44                 ` Tang Chen
2013-01-31 10:38                 ` Simon Jeons
2013-01-31 10:38                   ` Simon Jeons
2013-01-31 10:38                   ` Simon Jeons
2013-01-31 10:38                   ` Simon Jeons
2013-02-01  1:32                   ` Jianguo Wu
2013-02-01  1:32                     ` Jianguo Wu
2013-02-01  1:32                     ` Jianguo Wu
2013-02-01  1:32                     ` Jianguo Wu
2013-02-01  1:36                     ` Simon Jeons
2013-02-01  1:36                       ` Simon Jeons
2013-02-01  1:36                       ` Simon Jeons
2013-02-01  1:36                       ` Simon Jeons
2013-02-01  1:57                       ` Jianguo Wu
2013-02-01  1:57                         ` Jianguo Wu
2013-02-01  1:57                         ` Jianguo Wu
2013-02-01  1:57                         ` Jianguo Wu
2013-02-01  2:06                         ` Simon Jeons
2013-02-01  2:06                           ` Simon Jeons
2013-02-01  2:06                           ` Simon Jeons
2013-02-01  2:06                           ` Simon Jeons
2013-02-01  2:18                           ` Jianguo Wu
2013-02-01  2:18                             ` Jianguo Wu
2013-02-01  2:18                             ` Jianguo Wu
2013-02-01  2:18                             ` Jianguo Wu
2013-02-01  1:57                       ` Tang Chen
2013-02-01  1:57                         ` Tang Chen
2013-02-01  1:57                         ` Tang Chen
2013-02-01  1:57                         ` Tang Chen
2013-02-01  2:17                         ` Simon Jeons
2013-02-01  2:17                           ` Simon Jeons
2013-02-01  2:17                           ` Simon Jeons
2013-02-01  2:17                           ` Simon Jeons
2013-02-01  2:42                           ` Tang Chen
2013-02-01  2:42                             ` Tang Chen
2013-02-01  2:42                             ` Tang Chen
2013-02-01  2:42                             ` Tang Chen
2013-02-01  3:06                             ` Simon Jeons
2013-02-01  3:06                               ` Simon Jeons
2013-02-01  3:06                               ` Simon Jeons
2013-02-01  3:06                               ` Simon Jeons
2013-02-01  3:39                               ` Tang Chen
2013-02-01  3:39                                 ` Tang Chen
2013-02-01  3:39                                 ` Tang Chen
2013-02-01  3:39                                 ` Tang Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130109151920.fb9b4029.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=cl@linux.com \
    --cc=cmetcalf@tilera.com \
    --cc=glommer@parallels.com \
    --cc=hpa@zytor.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=len.brown@intel.com \
    --cc=linfeng@cn.fujitsu.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mgorman@suse.de \
    --cc=minchan.kim@gmail.com \
    --cc=paulus@samba.org \
    --cc=rientjes@google.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=tangchen@cn.fujitsu.com \
    --cc=wency@cn.fujitsu.com \
    --cc=wujianguo@huawei.com \
    --cc=x86@kernel.org \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.