From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> To: Minchan Kim <minchan.kim@gmail.com> Cc: Mel Gorman <mel@csn.ul.ie>, Andrew Morton <akpm@linux-foundation.org>, Andrea Arcangeli <aarcange@redhat.com>, Christoph Lameter <cl@linux-foundation.org>, Adam Litke <agl@us.ibm.com>, Avi Kivity <avi@redhat.com>, David Rientjes <rientjes@google.com>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, Rik van Riel <riel@redhat.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 02/11] mm,migration: Do not try to migrate unmapped anonymous pages Date: Wed, 17 Mar 2010 12:15:51 +0900 [thread overview] Message-ID: <20100317121551.b619f55b.kamezawa.hiroyu@jp.fujitsu.com> (raw) In-Reply-To: <28c262361003162000w34cc13ecnbd32840a0df80f95@mail.gmail.com> On Wed, 17 Mar 2010 12:00:15 +0900 Minchan Kim <minchan.kim@gmail.com> wrote: > On Wed, Mar 17, 2010 at 11:12 AM, KAMEZAWA Hiroyuki > > BTW, I doubt freeing anon_vma can happen even when we check mapcount. > > > > "unmap" is 2-stage operation. > > 1. unmap_vmas() => modify ptes, free pages, etc. > > 2. free_pgtables() => free pgtables, unlink vma and free it. > > > > Then, if migration is enough slow. > > > > Migration(): Exit(): > > check mapcount > > rcu_read_lock > > pte_lock > > replace pte with migration pte > > pte_unlock > > pte_lock > > copy page etc... zap pte (clear pte) > > pte_unlock > > free_pgtables > > ->free vma > > ->free anon_vma > > pte_lock > > remap pte with new pfn(fail) > > pte_unlock > > > > lock anon_vma->lock # modification after free. > > check list is empty > > check list is empty? > Do you mean anon_vma->head? > yes. > If it is, is it possible that that list isn't empty since anon_vma is > used by others due to > SLAB_DESTROY_BY_RCU? > There are 4 cases. A) anon_vma->list is not empty because anon_vma is not freed. B) anon_vma->list is empty because it's freed. C) anon_vma->list is empty but it's reused. D) anon_vma->list is not empty but it's reused. > but such case is handled by page_check_address, vma_address, I think. > yes. Then, this corrupt nothing, as I wrote. We just modify anon_vma->lock and it's safe because of SLAB_DESTROY_BY_RCU. > > unlock anon_vma->lock > > free anon_vma > > rcu_read_unlock > > > > > > Hmm. IIUC, anon_vma is allocated as SLAB_DESTROY_BY_RCU. Then, while > > rcu_read_lock() is taken, anon_vma is anon_vma even if freed. But it > > may reused as anon_vma for someone else. > > (IOW, it may be reused but never pushed back to general purpose memory > > until RCU grace period.) > > Then, touching anon_vma->lock never cause any corruption. > > > > Does use-after-free check for SLAB_DESTROY_BY_RCU correct behavior ? > > Could you elaborate your point? > Ah, my point is "how use-after-free is detected ?" If use-after-free is detected by free_pages() (DEBUG_PGALLOC), it seems strange because DESTROY_BY_RCU guarantee that never happens. So, I assume use-after-free is detected in SLAB layer. If so, in above B), C), D) case, it seems there is use-after free in slab's point of view but it works as expected, no corruption. Then, my question is "Does use-after-free check for SLAB_DESTROY_BY_RCU work correctly ?" and implies we need this patch ? (But this will prevent unnecessary page copy etc. by easy check.) Thanks, -Kame
WARNING: multiple messages have this Message-ID (diff)
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> To: Minchan Kim <minchan.kim@gmail.com> Cc: Mel Gorman <mel@csn.ul.ie>, Andrew Morton <akpm@linux-foundation.org>, Andrea Arcangeli <aarcange@redhat.com>, Christoph Lameter <cl@linux-foundation.org>, Adam Litke <agl@us.ibm.com>, Avi Kivity <avi@redhat.com>, David Rientjes <rientjes@google.com>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, Rik van Riel <riel@redhat.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 02/11] mm,migration: Do not try to migrate unmapped anonymous pages Date: Wed, 17 Mar 2010 12:15:51 +0900 [thread overview] Message-ID: <20100317121551.b619f55b.kamezawa.hiroyu@jp.fujitsu.com> (raw) In-Reply-To: <28c262361003162000w34cc13ecnbd32840a0df80f95@mail.gmail.com> On Wed, 17 Mar 2010 12:00:15 +0900 Minchan Kim <minchan.kim@gmail.com> wrote: > On Wed, Mar 17, 2010 at 11:12 AM, KAMEZAWA Hiroyuki > > BTW, I doubt freeing anon_vma can happen even when we check mapcount. > > > > "unmap" is 2-stage operation. > > A A A A 1. unmap_vmas() => modify ptes, free pages, etc. > > A A A A 2. free_pgtables() => free pgtables, unlink vma and free it. > > > > Then, if migration is enough slow. > > > > A A A A Migration(): A A A A A A A A A A A A A A Exit(): > > A A A A check mapcount > > A A A A rcu_read_lock > > A A A A pte_lock > > A A A A replace pte with migration pte > > A A A A pte_unlock > > A A A A A A A A A A A A A A A A A A A A A A A A pte_lock > > A A A A copy page etc... A A A A A A A A A A A A zap pte (clear pte) > > A A A A A A A A A A A A A A A A A A A A A A A A pte_unlock > > A A A A A A A A A A A A A A A A A A A A A A A A free_pgtables > > A A A A A A A A A A A A A A A A A A A A A A A A ->free vma > > A A A A A A A A A A A A A A A A A A A A A A A A ->free anon_vma > > A A A A pte_lock > > A A A A remap pte with new pfn(fail) > > A A A A pte_unlock > > > > A A A A lock anon_vma->lock A A A A A A # modification after free. > > A A A A check list is empty > > check list is empty? > Do you mean anon_vma->head? > yes. > If it is, is it possible that that list isn't empty since anon_vma is > used by others due to > SLAB_DESTROY_BY_RCU? > There are 4 cases. A) anon_vma->list is not empty because anon_vma is not freed. B) anon_vma->list is empty because it's freed. C) anon_vma->list is empty but it's reused. D) anon_vma->list is not empty but it's reused. > but such case is handled by page_check_address, vma_address, I think. > yes. Then, this corrupt nothing, as I wrote. We just modify anon_vma->lock and it's safe because of SLAB_DESTROY_BY_RCU. > > A A A A unlock anon_vma->lock > > A A A A free anon_vma > > A A A A rcu_read_unlock > > > > > > Hmm. IIUC, anon_vma is allocated as SLAB_DESTROY_BY_RCU. Then, while > > rcu_read_lock() is taken, anon_vma is anon_vma even if freed. But it > > may reused as anon_vma for someone else. > > (IOW, it may be reused but never pushed back to general purpose memory > > A until RCU grace period.) > > Then, touching anon_vma->lock never cause any corruption. > > > > Does use-after-free check for SLAB_DESTROY_BY_RCU correct behavior ? > > Could you elaborate your point? > Ah, my point is "how use-after-free is detected ?" If use-after-free is detected by free_pages() (DEBUG_PGALLOC), it seems strange because DESTROY_BY_RCU guarantee that never happens. So, I assume use-after-free is detected in SLAB layer. If so, in above B), C), D) case, it seems there is use-after free in slab's point of view but it works as expected, no corruption. Then, my question is "Does use-after-free check for SLAB_DESTROY_BY_RCU work correctly ?" and implies we need this patch ? (But this will prevent unnecessary page copy etc. by easy check.) Thanks, -Kame -- 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>
next prev parent reply other threads:[~2010-03-17 3:19 UTC|newest] Thread overview: 218+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-03-12 16:41 [PATCH 0/11] Memory Compaction v4 Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-12 16:41 ` [PATCH 01/11] mm,migration: Take a reference to the anon_vma before migrating Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-14 15:01 ` Minchan Kim 2010-03-14 15:01 ` Minchan Kim 2010-03-15 5:06 ` KAMEZAWA Hiroyuki 2010-03-15 5:06 ` KAMEZAWA Hiroyuki 2010-03-17 1:44 ` KOSAKI Motohiro 2010-03-17 1:44 ` KOSAKI Motohiro 2010-03-17 11:45 ` Mel Gorman 2010-03-17 11:45 ` Mel Gorman 2010-03-17 16:38 ` Christoph Lameter 2010-03-17 16:38 ` Christoph Lameter 2010-03-18 11:12 ` Mel Gorman 2010-03-18 11:12 ` Mel Gorman 2010-03-18 16:31 ` Christoph Lameter 2010-03-18 16:31 ` Christoph Lameter 2010-03-12 16:41 ` [PATCH 02/11] mm,migration: Do not try to migrate unmapped anonymous pages Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-15 0:28 ` Minchan Kim 2010-03-15 0:28 ` Minchan Kim 2010-03-15 5:34 ` KAMEZAWA Hiroyuki 2010-03-15 5:34 ` KAMEZAWA Hiroyuki 2010-03-15 6:28 ` Minchan Kim 2010-03-15 6:28 ` Minchan Kim 2010-03-15 6:44 ` KAMEZAWA Hiroyuki 2010-03-15 6:44 ` KAMEZAWA Hiroyuki 2010-03-15 7:09 ` KAMEZAWA Hiroyuki 2010-03-15 7:09 ` KAMEZAWA Hiroyuki 2010-03-15 13:48 ` Minchan Kim 2010-03-15 13:48 ` Minchan Kim 2010-03-15 7:11 ` Minchan Kim 2010-03-15 7:11 ` Minchan Kim 2010-03-15 11:28 ` Mel Gorman 2010-03-15 11:28 ` Mel Gorman 2010-03-15 12:48 ` Minchan Kim 2010-03-15 12:48 ` Minchan Kim 2010-03-15 14:21 ` Mel Gorman 2010-03-15 14:21 ` Mel Gorman 2010-03-15 14:33 ` Minchan Kim 2010-03-15 14:33 ` Minchan Kim 2010-03-15 23:49 ` KAMEZAWA Hiroyuki 2010-03-15 23:49 ` KAMEZAWA Hiroyuki 2010-03-17 2:12 ` KAMEZAWA Hiroyuki 2010-03-17 2:12 ` KAMEZAWA Hiroyuki 2010-03-17 3:00 ` Minchan Kim 2010-03-17 3:00 ` Minchan Kim 2010-03-17 3:15 ` KAMEZAWA Hiroyuki [this message] 2010-03-17 3:15 ` KAMEZAWA Hiroyuki 2010-03-17 4:15 ` Minchan Kim 2010-03-17 4:15 ` Minchan Kim 2010-03-17 4:19 ` KAMEZAWA Hiroyuki 2010-03-17 4:19 ` KAMEZAWA Hiroyuki 2010-03-17 16:41 ` Christoph Lameter 2010-03-17 16:41 ` Christoph Lameter 2010-03-18 0:30 ` KAMEZAWA Hiroyuki 2010-03-18 0:30 ` KAMEZAWA Hiroyuki 2010-03-17 12:07 ` Mel Gorman 2010-03-17 12:07 ` Mel Gorman 2010-03-17 2:03 ` KOSAKI Motohiro 2010-03-17 2:03 ` KOSAKI Motohiro 2010-03-17 11:51 ` Mel Gorman 2010-03-17 11:51 ` Mel Gorman 2010-03-18 0:48 ` KOSAKI Motohiro 2010-03-18 0:48 ` KOSAKI Motohiro 2010-03-18 11:14 ` Mel Gorman 2010-03-18 11:14 ` Mel Gorman 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-19 8:59 ` Mel Gorman 2010-03-19 8:59 ` Mel Gorman 2010-03-25 2:49 ` KOSAKI Motohiro 2010-03-25 2:49 ` KOSAKI Motohiro 2010-03-25 8:32 ` Mel Gorman 2010-03-25 8:32 ` Mel Gorman 2010-03-25 8:56 ` KOSAKI Motohiro 2010-03-25 8:56 ` KOSAKI Motohiro 2010-03-25 9:18 ` Mel Gorman 2010-03-25 9:18 ` Mel Gorman 2010-03-25 9:02 ` KAMEZAWA Hiroyuki 2010-03-25 9:02 ` KAMEZAWA Hiroyuki 2010-03-25 9:09 ` KOSAKI Motohiro 2010-03-25 9:09 ` KOSAKI Motohiro 2010-03-25 9:08 ` KAMEZAWA Hiroyuki 2010-03-25 9:08 ` KAMEZAWA Hiroyuki 2010-03-25 9:21 ` Mel Gorman 2010-03-25 9:21 ` Mel Gorman 2010-03-25 9:41 ` KAMEZAWA Hiroyuki 2010-03-25 9:41 ` KAMEZAWA Hiroyuki 2010-03-25 9:59 ` KOSAKI Motohiro 2010-03-25 9:59 ` KOSAKI Motohiro 2010-03-25 10:12 ` KAMEZAWA Hiroyuki 2010-03-25 10:12 ` KAMEZAWA Hiroyuki 2010-03-25 13:39 ` Mel Gorman 2010-03-25 13:39 ` Mel Gorman 2010-03-26 3:07 ` KOSAKI Motohiro 2010-03-26 3:07 ` KOSAKI Motohiro 2010-03-26 13:49 ` Mel Gorman 2010-03-26 13:49 ` Mel Gorman 2010-03-25 15:29 ` Minchan Kim 2010-03-25 15:29 ` Minchan Kim 2010-03-26 0:58 ` KAMEZAWA Hiroyuki 2010-03-26 0:58 ` KAMEZAWA Hiroyuki 2010-03-26 1:39 ` Minchan Kim 2010-03-26 1:39 ` Minchan Kim 2010-03-25 14:35 ` Christoph Lameter 2010-03-25 14:35 ` Christoph Lameter 2010-03-25 16:16 ` Minchan Kim 2010-03-25 16:16 ` Minchan Kim 2010-03-12 16:41 ` [PATCH 03/11] mm: Share the anon_vma ref counts between KSM and page migration Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-12 17:14 ` Rik van Riel 2010-03-12 17:14 ` Rik van Riel 2010-03-15 5:35 ` KAMEZAWA Hiroyuki 2010-03-15 5:35 ` KAMEZAWA Hiroyuki 2010-03-17 2:06 ` KOSAKI Motohiro 2010-03-17 2:06 ` KOSAKI Motohiro 2010-03-12 16:41 ` [PATCH 04/11] Allow CONFIG_MIGRATION to be set without CONFIG_NUMA or memory hot-remove Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-17 2:28 ` KOSAKI Motohiro 2010-03-17 2:28 ` KOSAKI Motohiro 2010-03-17 11:32 ` Mel Gorman 2010-03-17 11:32 ` Mel Gorman 2010-03-17 16:37 ` Christoph Lameter 2010-03-17 16:37 ` Christoph Lameter 2010-03-17 23:56 ` KOSAKI Motohiro 2010-03-17 23:56 ` KOSAKI Motohiro 2010-03-18 11:24 ` Mel Gorman 2010-03-18 11:24 ` Mel Gorman 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-19 10:16 ` Mel Gorman 2010-03-19 10:16 ` Mel Gorman 2010-03-25 3:28 ` KOSAKI Motohiro 2010-03-25 3:28 ` KOSAKI Motohiro 2010-03-12 16:41 ` [PATCH 05/11] Export unusable free space index via /proc/unusable_index Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-15 5:41 ` KAMEZAWA Hiroyuki 2010-03-15 5:41 ` KAMEZAWA Hiroyuki 2010-03-15 9:48 ` Mel Gorman 2010-03-15 9:48 ` Mel Gorman 2010-03-17 2:42 ` KOSAKI Motohiro 2010-03-17 2:42 ` KOSAKI Motohiro 2010-03-12 16:41 ` [PATCH 06/11] Export fragmentation index via /proc/extfrag_index Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-17 2:49 ` KOSAKI Motohiro 2010-03-17 2:49 ` KOSAKI Motohiro 2010-03-17 11:33 ` Mel Gorman 2010-03-17 11:33 ` Mel Gorman 2010-03-23 0:22 ` KOSAKI Motohiro 2010-03-23 0:22 ` KOSAKI Motohiro 2010-03-23 12:03 ` Mel Gorman 2010-03-23 12:03 ` Mel Gorman 2010-03-25 2:47 ` KOSAKI Motohiro 2010-03-25 2:47 ` KOSAKI Motohiro 2010-03-25 8:47 ` Mel Gorman 2010-03-25 8:47 ` Mel Gorman 2010-03-25 11:20 ` KOSAKI Motohiro 2010-03-25 11:20 ` KOSAKI Motohiro 2010-03-25 14:11 ` Mel Gorman 2010-03-25 14:11 ` Mel Gorman 2010-03-26 3:10 ` KOSAKI Motohiro 2010-03-26 3:10 ` KOSAKI Motohiro 2010-03-12 16:41 ` [PATCH 07/11] Memory compaction core Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-15 13:44 ` Minchan Kim 2010-03-15 13:44 ` Minchan Kim 2010-03-15 14:41 ` Mel Gorman 2010-03-15 14:41 ` Mel Gorman 2010-03-17 10:31 ` KOSAKI Motohiro 2010-03-17 10:31 ` KOSAKI Motohiro 2010-03-17 11:40 ` Mel Gorman 2010-03-17 11:40 ` Mel Gorman 2010-03-18 2:35 ` KOSAKI Motohiro 2010-03-18 2:35 ` KOSAKI Motohiro 2010-03-18 11:43 ` Mel Gorman 2010-03-18 11:43 ` Mel Gorman 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-18 17:08 ` Mel Gorman 2010-03-18 17:08 ` Mel Gorman 2010-03-12 16:41 ` [PATCH 08/11] Add /proc trigger for memory compaction Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-17 3:18 ` KOSAKI Motohiro 2010-03-17 3:18 ` KOSAKI Motohiro 2010-03-12 16:41 ` [PATCH 09/11] Add /sys trigger for per-node " Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-17 3:18 ` KOSAKI Motohiro 2010-03-17 3:18 ` KOSAKI Motohiro 2010-03-12 16:41 ` [PATCH 10/11] Direct compact when a high-order allocation fails Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-16 2:47 ` Minchan Kim 2010-03-16 2:47 ` Minchan Kim 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-19 6:31 ` KOSAKI Motohiro 2010-03-19 6:31 ` KOSAKI Motohiro 2010-03-19 10:10 ` Mel Gorman 2010-03-19 10:10 ` Mel Gorman 2010-03-25 11:22 ` KOSAKI Motohiro 2010-03-25 11:22 ` KOSAKI Motohiro 2010-03-19 10:09 ` Mel Gorman 2010-03-19 10:09 ` Mel Gorman 2010-03-25 11:08 ` KOSAKI Motohiro 2010-03-25 11:08 ` KOSAKI Motohiro 2010-03-25 15:11 ` Mel Gorman 2010-03-25 15:11 ` Mel Gorman 2010-03-26 6:01 ` KOSAKI Motohiro 2010-03-26 6:01 ` KOSAKI Motohiro 2010-03-12 16:41 ` [PATCH 11/11] Do not compact within a preferred zone after a compaction failure Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-23 12:25 [PATCH 0/11] Memory Compaction v5 Mel Gorman 2010-03-23 12:25 ` [PATCH 02/11] mm,migration: Do not try to migrate unmapped anonymous pages Mel Gorman 2010-03-23 12:25 ` Mel Gorman 2010-03-23 17:22 ` Christoph Lameter 2010-03-23 17:22 ` Christoph Lameter 2010-03-23 18:04 ` Mel Gorman 2010-03-23 18:04 ` Mel Gorman
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=20100317121551.b619f55b.kamezawa.hiroyu@jp.fujitsu.com \ --to=kamezawa.hiroyu@jp.fujitsu.com \ --cc=aarcange@redhat.com \ --cc=agl@us.ibm.com \ --cc=akpm@linux-foundation.org \ --cc=avi@redhat.com \ --cc=cl@linux-foundation.org \ --cc=kosaki.motohiro@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mel@csn.ul.ie \ --cc=minchan.kim@gmail.com \ --cc=riel@redhat.com \ --cc=rientjes@google.com \ /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: linkBe 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.