From: Tang Chen <tangchen@cn.fujitsu.com>
To: Andrew Morton <akpm@linux-foundation.org>
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 02/15] memory-hotplug: check whether all memory blocks are offlined or not when removing memory
Date: Thu, 10 Jan 2013 13:56:07 +0800 [thread overview]
Message-ID: <50EE57F7.1000304@cn.fujitsu.com> (raw)
In-Reply-To: <20130109151140.76982b9e.akpm@linux-foundation.org>
Hi Andrew,
On 01/10/2013 07:11 AM, Andrew Morton wrote:
> On Wed, 9 Jan 2013 17:32:26 +0800
> Tang Chen<tangchen@cn.fujitsu.com> wrote:
>
>> We remove the memory like this:
>> 1. lock memory hotplug
>> 2. offline a memory block
>> 3. unlock memory hotplug
>> 4. repeat 1-3 to offline all memory blocks
>> 5. lock memory hotplug
>> 6. remove memory(TODO)
>> 7. unlock memory hotplug
>>
>> All memory blocks must be offlined before removing memory. But we don't hold
>> the lock in the whole operation. So we should check whether all memory blocks
>> are offlined before step6. Otherwise, kernel maybe panicked.
>
> Well, the obvious question is: why don't we hold lock_memory_hotplug()
> for all of steps 1-4? Please send the reasons for this in a form which
> I can paste into the changelog.
In the changelog form:
Offlining a memory block and removing a memory device can be two
different operations. Users can just offline some memory blocks
without removing the memory device. For this purpose, the kernel has
held lock_memory_hotplug() in __offline_pages(). To reuse the code
for memory hot-remove, we repeat step 1-3 to offline all the memory
blocks, repeatedly lock and unlock memory hotplug, but not hold the
memory hotplug lock in the whole operation.
>
>
> Actually, I wonder if doing this would fix a race in the current
> remove_memory() repeat: loop. That code does a
> find_memory_block_hinted() followed by offline_memory_block(), but
> afaict find_memory_block_hinted() only does a get_device(). Is the
> get_device() sufficiently strong to prevent problems if another thread
> concurrently offlines or otherwise alters this memory_block's state?
I think we already have memory_block->state_mutex to protect the
concurrently changing of memory_block's state.
The find_memory_block_hinted() here is to find the memory_block
corresponding to the memory section we are dealing with.
Thanks. :)
>
--
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: Tang Chen <tangchen@cn.fujitsu.com>
To: Andrew Morton <akpm@linux-foundation.org>
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 02/15] memory-hotplug: check whether all memory blocks are offlined or not when removi
Date: Thu, 10 Jan 2013 05:56:07 +0000 [thread overview]
Message-ID: <50EE57F7.1000304@cn.fujitsu.com> (raw)
In-Reply-To: <20130109151140.76982b9e.akpm@linux-foundation.org>
Hi Andrew,
On 01/10/2013 07:11 AM, Andrew Morton wrote:
> On Wed, 9 Jan 2013 17:32:26 +0800
> Tang Chen<tangchen@cn.fujitsu.com> wrote:
>
>> We remove the memory like this:
>> 1. lock memory hotplug
>> 2. offline a memory block
>> 3. unlock memory hotplug
>> 4. repeat 1-3 to offline all memory blocks
>> 5. lock memory hotplug
>> 6. remove memory(TODO)
>> 7. unlock memory hotplug
>>
>> All memory blocks must be offlined before removing memory. But we don't hold
>> the lock in the whole operation. So we should check whether all memory blocks
>> are offlined before step6. Otherwise, kernel maybe panicked.
>
> Well, the obvious question is: why don't we hold lock_memory_hotplug()
> for all of steps 1-4? Please send the reasons for this in a form which
> I can paste into the changelog.
In the changelog form:
Offlining a memory block and removing a memory device can be two
different operations. Users can just offline some memory blocks
without removing the memory device. For this purpose, the kernel has
held lock_memory_hotplug() in __offline_pages(). To reuse the code
for memory hot-remove, we repeat step 1-3 to offline all the memory
blocks, repeatedly lock and unlock memory hotplug, but not hold the
memory hotplug lock in the whole operation.
>
>
> Actually, I wonder if doing this would fix a race in the current
> remove_memory() repeat: loop. That code does a
> find_memory_block_hinted() followed by offline_memory_block(), but
> afaict find_memory_block_hinted() only does a get_device(). Is the
> get_device() sufficiently strong to prevent problems if another thread
> concurrently offlines or otherwise alters this memory_block's state?
I think we already have memory_block->state_mutex to protect the
concurrently changing of memory_block's state.
The find_memory_block_hinted() here is to find the memory_block
corresponding to the memory section we are dealing with.
Thanks. :)
>
WARNING: multiple messages have this Message-ID (diff)
From: Tang Chen <tangchen@cn.fujitsu.com>
To: Andrew Morton <akpm@linux-foundation.org>
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 02/15] memory-hotplug: check whether all memory blocks are offlined or not when removing memory
Date: Thu, 10 Jan 2013 13:56:07 +0800 [thread overview]
Message-ID: <50EE57F7.1000304@cn.fujitsu.com> (raw)
In-Reply-To: <20130109151140.76982b9e.akpm@linux-foundation.org>
Hi Andrew,
On 01/10/2013 07:11 AM, Andrew Morton wrote:
> On Wed, 9 Jan 2013 17:32:26 +0800
> Tang Chen<tangchen@cn.fujitsu.com> wrote:
>
>> We remove the memory like this:
>> 1. lock memory hotplug
>> 2. offline a memory block
>> 3. unlock memory hotplug
>> 4. repeat 1-3 to offline all memory blocks
>> 5. lock memory hotplug
>> 6. remove memory(TODO)
>> 7. unlock memory hotplug
>>
>> All memory blocks must be offlined before removing memory. But we don't hold
>> the lock in the whole operation. So we should check whether all memory blocks
>> are offlined before step6. Otherwise, kernel maybe panicked.
>
> Well, the obvious question is: why don't we hold lock_memory_hotplug()
> for all of steps 1-4? Please send the reasons for this in a form which
> I can paste into the changelog.
In the changelog form:
Offlining a memory block and removing a memory device can be two
different operations. Users can just offline some memory blocks
without removing the memory device. For this purpose, the kernel has
held lock_memory_hotplug() in __offline_pages(). To reuse the code
for memory hot-remove, we repeat step 1-3 to offline all the memory
blocks, repeatedly lock and unlock memory hotplug, but not hold the
memory hotplug lock in the whole operation.
>
>
> Actually, I wonder if doing this would fix a race in the current
> remove_memory() repeat: loop. That code does a
> find_memory_block_hinted() followed by offline_memory_block(), but
> afaict find_memory_block_hinted() only does a get_device(). Is the
> get_device() sufficiently strong to prevent problems if another thread
> concurrently offlines or otherwise alters this memory_block's state?
I think we already have memory_block->state_mutex to protect the
concurrently changing of memory_block's state.
The find_memory_block_hinted() here is to find the memory_block
corresponding to the memory section we are dealing with.
Thanks. :)
>
WARNING: multiple messages have this Message-ID (diff)
From: Tang Chen <tangchen@cn.fujitsu.com>
To: Andrew Morton <akpm@linux-foundation.org>
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 02/15] memory-hotplug: check whether all memory blocks are offlined or not when removing memory
Date: Thu, 10 Jan 2013 13:56:07 +0800 [thread overview]
Message-ID: <50EE57F7.1000304@cn.fujitsu.com> (raw)
In-Reply-To: <20130109151140.76982b9e.akpm@linux-foundation.org>
Hi Andrew,
On 01/10/2013 07:11 AM, Andrew Morton wrote:
> On Wed, 9 Jan 2013 17:32:26 +0800
> Tang Chen<tangchen@cn.fujitsu.com> wrote:
>
>> We remove the memory like this:
>> 1. lock memory hotplug
>> 2. offline a memory block
>> 3. unlock memory hotplug
>> 4. repeat 1-3 to offline all memory blocks
>> 5. lock memory hotplug
>> 6. remove memory(TODO)
>> 7. unlock memory hotplug
>>
>> All memory blocks must be offlined before removing memory. But we don't hold
>> the lock in the whole operation. So we should check whether all memory blocks
>> are offlined before step6. Otherwise, kernel maybe panicked.
>
> Well, the obvious question is: why don't we hold lock_memory_hotplug()
> for all of steps 1-4? Please send the reasons for this in a form which
> I can paste into the changelog.
In the changelog form:
Offlining a memory block and removing a memory device can be two
different operations. Users can just offline some memory blocks
without removing the memory device. For this purpose, the kernel has
held lock_memory_hotplug() in __offline_pages(). To reuse the code
for memory hot-remove, we repeat step 1-3 to offline all the memory
blocks, repeatedly lock and unlock memory hotplug, but not hold the
memory hotplug lock in the whole operation.
>
>
> Actually, I wonder if doing this would fix a race in the current
> remove_memory() repeat: loop. That code does a
> find_memory_block_hinted() followed by offline_memory_block(), but
> afaict find_memory_block_hinted() only does a get_device(). Is the
> get_device() sufficiently strong to prevent problems if another thread
> concurrently offlines or otherwise alters this memory_block's state?
I think we already have memory_block->state_mutex to protect the
concurrently changing of memory_block's state.
The find_memory_block_hinted() here is to find the memory_block
corresponding to the memory section we are dealing with.
Thanks. :)
>
next prev parent reply other threads:[~2013-01-10 5:56 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 ` Tang Chen [this message]
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 ` [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
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=50EE57F7.1000304@cn.fujitsu.com \
--to=tangchen@cn.fujitsu.com \
--cc=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=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.