From: Alex Shi <alex.shi@linux.alibaba.com> To: akpm@linux-foundation.org, mgorman@techsingularity.net, tj@kernel.org, hughd@google.com, khlebnikov@yandex-team.ru, daniel.m.jordan@oracle.com, willy@infradead.org, hannes@cmpxchg.org, lkp@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, shakeelb@google.com, iamjoonsoo.kim@lge.com, richard.weiyang@gmail.com, kirill@shutemov.name, alexander.duyck@gmail.com, rong.a.chen@intel.com, mhocko@suse.com, vdavydov.dev@gmail.com, shy828301@gmail.com Cc: Minchan Kim <minchan@kernel.org> Subject: Re: [PATCH v21 06/19] mm/rmap: stop store reordering issue on page->mapping Date: Fri, 6 Nov 2020 09:20:04 +0800 [thread overview] Message-ID: <e66ef2e5-c74c-6498-e8b3-56c37b9d2d15@linux.alibaba.com> (raw) In-Reply-To: <1604566549-62481-7-git-send-email-alex.shi@linux.alibaba.com> updated for comments change from Johannes From 2fd278b1ca6c3e260ad249808b62f671d8db5a7b Mon Sep 17 00:00:00 2001 From: Alex Shi <alex.shi@linux.alibaba.com> Date: Thu, 5 Nov 2020 11:38:24 +0800 Subject: [PATCH v21 06/19] mm/rmap: stop store reordering issue on page->mapping Hugh Dickins and Minchan Kim observed a long time issue which discussed here, but actully the mentioned fix missed. https://lore.kernel.org/lkml/20150504031722.GA2768@blaptop/ The store reordering may cause problem in the scenario: CPU 0 CPU1 do_anonymous_page page_add_new_anon_rmap() page->mapping = anon_vma + PAGE_MAPPING_ANON lru_cache_add_inactive_or_unevictable() spin_lock(lruvec->lock) SetPageLRU() spin_unlock(lruvec->lock) /* idletacking judged it as LRU * page so pass the page in * page_idle_clear_pte_refs */ page_idle_clear_pte_refs rmap_walk if PageAnon(page) Johannes give detailed examples how the store reordering could cause a trouble: "The concern is the SetPageLRU may get reorder before 'page->mapping' setting, That would make CPU 1 will observe at page->mapping after observing PageLRU set on the page. 1. anon_vma + PAGE_MAPPING_ANON That's the in-order scenario and is fine. 2. NULL That's possible if the page->mapping store gets reordered to occur after SetPageLRU. That's fine too because we check for it. 3. anon_vma without the PAGE_MAPPING_ANON bit That would be a problem and could lead to all kinds of undesirable behavior including crashes and data corruption. Is it possible? AFAICT the compiler is allowed to tear the store to page->mapping and I don't see anything that would prevent it. That said, I also don't see how the reader testing PageLRU under the lru_lock would prevent that in the first place. AFAICT we need that WRITE_ONCE() around the page->mapping assignment." Signed-off-by: Alex Shi <alex.shi@linux.alibaba.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Hugh Dickins <hughd@google.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Minchan Kim <minchan@kernel.org> Cc: Vladimir Davydov <vdavydov.dev@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org --- mm/rmap.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/mm/rmap.c b/mm/rmap.c index 1b84945d655c..380c6b9956c2 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -1054,8 +1054,14 @@ static void __page_set_anon_rmap(struct page *page, if (!exclusive) anon_vma = anon_vma->root; + /* + * page_idle does a lockless/optimistic rmap scan on page->mapping. + * Make sure the compiler doesn't split the stores of anon_vma and + * the PAGE_MAPPING_ANON type identifier, otherwise the rmap code + * could mistake the mapping for a struct address_space and crash. + */ anon_vma = (void *) anon_vma + PAGE_MAPPING_ANON; - page->mapping = (struct address_space *) anon_vma; + WRITE_ONCE(page->mapping, (struct address_space *) anon_vma); page->index = linear_page_index(vma, address); } -- 1.8.3.1
WARNING: multiple messages have this Message-ID (diff)
From: Alex Shi <alex.shi-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org> To: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, mgorman-3eNAlZScCAx27rWaFMvyedHuzzzSOjJt@public.gmane.org, tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, khlebnikov-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org, daniel.m.jordan-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org, lkp-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, iamjoonsoo.kim-Hm3cg6mZ9cc@public.gmane.org, richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org, alexander.duyck-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, rong.a.chen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, mhocko-IBi9RG/b67k@public.gmane.org, vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, shy828301-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Cc: Minchan Kim <minchan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Subject: Re: [PATCH v21 06/19] mm/rmap: stop store reordering issue on page->mapping Date: Fri, 6 Nov 2020 09:20:04 +0800 [thread overview] Message-ID: <e66ef2e5-c74c-6498-e8b3-56c37b9d2d15@linux.alibaba.com> (raw) In-Reply-To: <1604566549-62481-7-git-send-email-alex.shi-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org> updated for comments change from Johannes From 2fd278b1ca6c3e260ad249808b62f671d8db5a7b Mon Sep 17 00:00:00 2001 From: Alex Shi <alex.shi-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org> Date: Thu, 5 Nov 2020 11:38:24 +0800 Subject: [PATCH v21 06/19] mm/rmap: stop store reordering issue on page->mapping Hugh Dickins and Minchan Kim observed a long time issue which discussed here, but actully the mentioned fix missed. https://lore.kernel.org/lkml/20150504031722.GA2768@blaptop/ The store reordering may cause problem in the scenario: CPU 0 CPU1 do_anonymous_page page_add_new_anon_rmap() page->mapping = anon_vma + PAGE_MAPPING_ANON lru_cache_add_inactive_or_unevictable() spin_lock(lruvec->lock) SetPageLRU() spin_unlock(lruvec->lock) /* idletacking judged it as LRU * page so pass the page in * page_idle_clear_pte_refs */ page_idle_clear_pte_refs rmap_walk if PageAnon(page) Johannes give detailed examples how the store reordering could cause a trouble: "The concern is the SetPageLRU may get reorder before 'page->mapping' setting, That would make CPU 1 will observe at page->mapping after observing PageLRU set on the page. 1. anon_vma + PAGE_MAPPING_ANON That's the in-order scenario and is fine. 2. NULL That's possible if the page->mapping store gets reordered to occur after SetPageLRU. That's fine too because we check for it. 3. anon_vma without the PAGE_MAPPING_ANON bit That would be a problem and could lead to all kinds of undesirable behavior including crashes and data corruption. Is it possible? AFAICT the compiler is allowed to tear the store to page->mapping and I don't see anything that would prevent it. That said, I also don't see how the reader testing PageLRU under the lru_lock would prevent that in the first place. AFAICT we need that WRITE_ONCE() around the page->mapping assignment." Signed-off-by: Alex Shi <alex.shi-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org> Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org> Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> Cc: Hugh Dickins <hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Cc: Matthew Wilcox <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> Cc: Minchan Kim <minchan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: Vladimir Davydov <vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Cc: linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org --- mm/rmap.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/mm/rmap.c b/mm/rmap.c index 1b84945d655c..380c6b9956c2 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -1054,8 +1054,14 @@ static void __page_set_anon_rmap(struct page *page, if (!exclusive) anon_vma = anon_vma->root; + /* + * page_idle does a lockless/optimistic rmap scan on page->mapping. + * Make sure the compiler doesn't split the stores of anon_vma and + * the PAGE_MAPPING_ANON type identifier, otherwise the rmap code + * could mistake the mapping for a struct address_space and crash. + */ anon_vma = (void *) anon_vma + PAGE_MAPPING_ANON; - page->mapping = (struct address_space *) anon_vma; + WRITE_ONCE(page->mapping, (struct address_space *) anon_vma); page->index = linear_page_index(vma, address); } -- 1.8.3.1
next prev parent reply other threads:[~2020-11-06 1:20 UTC|newest] Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-05 8:55 [PATCH v21 00/19] per memcg lru lock Alex Shi 2020-11-05 8:55 ` Alex Shi 2020-11-05 8:55 ` [PATCH v21 01/19] mm/thp: move lru_add_page_tail func to huge_memory.c Alex Shi 2020-11-05 8:55 ` Alex Shi 2020-11-05 8:55 ` [PATCH v21 02/19] mm/thp: use head for head page in lru_add_page_tail Alex Shi 2020-11-05 8:55 ` [PATCH v21 03/19] mm/thp: Simplify lru_add_page_tail() Alex Shi 2020-11-05 8:55 ` Alex Shi 2020-11-05 8:55 ` [PATCH v21 04/19] mm/thp: narrow lru locking Alex Shi 2020-11-05 8:55 ` [PATCH v21 05/19] mm/vmscan: remove unnecessary lruvec adding Alex Shi 2020-11-05 8:55 ` Alex Shi 2020-11-11 12:36 ` Vlastimil Babka 2020-11-11 12:36 ` Vlastimil Babka 2020-11-05 8:55 ` [PATCH v21 06/19] mm/rmap: stop store reordering issue on page->mapping Alex Shi 2020-11-06 1:20 ` Alex Shi [this message] 2020-11-06 1:20 ` Alex Shi 2020-11-10 19:06 ` Johannes Weiner 2020-11-11 7:41 ` Hugh Dickins 2020-11-11 7:41 ` Hugh Dickins 2020-11-05 8:55 ` [PATCH v21 07/19] mm: page_idle_get_page() does not need lru_lock Alex Shi 2020-11-05 8:55 ` Alex Shi 2020-11-10 19:01 ` Johannes Weiner 2020-11-11 8:17 ` huang ying 2020-11-11 8:17 ` huang ying 2020-11-11 8:17 ` huang ying 2020-11-11 12:52 ` Vlastimil Babka 2020-11-11 12:52 ` Vlastimil Babka 2020-11-05 8:55 ` [PATCH v21 08/19] mm/memcg: add debug checking in lock_page_memcg Alex Shi 2020-11-05 8:55 ` Alex Shi 2020-11-05 8:55 ` [PATCH v21 09/19] mm/swap.c: fold vm event PGROTATED into pagevec_move_tail_fn Alex Shi 2020-11-05 8:55 ` [PATCH v21 10/19] mm/lru: move lock into lru_note_cost Alex Shi 2020-11-05 8:55 ` [PATCH v21 11/19] mm/vmscan: remove lruvec reget in move_pages_to_lru Alex Shi 2020-11-05 8:55 ` Alex Shi 2020-11-05 8:55 ` [PATCH v21 12/19] mm/mlock: remove lru_lock on TestClearPageMlocked Alex Shi 2020-11-11 13:03 ` Vlastimil Babka 2020-11-11 13:03 ` Vlastimil Babka 2020-11-05 8:55 ` [PATCH v21 13/19] mm/mlock: remove __munlock_isolate_lru_page Alex Shi 2020-11-11 13:07 ` Vlastimil Babka 2020-11-05 8:55 ` [PATCH v21 14/19] mm/lru: introduce TestClearPageLRU Alex Shi 2020-11-05 8:55 ` Alex Shi 2020-11-11 13:36 ` Vlastimil Babka 2020-11-12 2:03 ` Hugh Dickins 2020-11-12 2:03 ` Hugh Dickins 2020-11-12 11:24 ` Vlastimil Babka 2020-11-05 8:55 ` [PATCH v21 15/19] mm/compaction: do page isolation first in compaction Alex Shi 2020-11-05 8:55 ` Alex Shi 2020-11-11 17:12 ` Vlastimil Babka 2020-11-11 17:12 ` Vlastimil Babka 2020-11-12 2:28 ` Hugh Dickins 2020-11-12 2:28 ` Hugh Dickins 2020-11-12 3:35 ` Alex Shi 2020-11-12 3:35 ` Alex Shi 2020-11-12 11:25 ` Vlastimil Babka 2020-11-12 11:25 ` Vlastimil Babka 2020-11-05 8:55 ` [PATCH v21 16/19] mm/swap.c: serialize memcg changes in pagevec_lru_move_fn Alex Shi 2020-11-11 18:00 ` Vlastimil Babka 2020-11-11 18:00 ` Vlastimil Babka 2020-11-05 8:55 ` [PATCH v21 17/19] mm/lru: replace pgdat lru_lock with lruvec lock Alex Shi 2020-11-05 8:55 ` Alex Shi 2020-11-05 13:43 ` Alex Shi 2020-11-05 13:43 ` Alex Shi 2020-11-06 7:48 ` Alex Shi 2020-11-06 7:48 ` Alex Shi 2020-11-10 18:54 ` Johannes Weiner 2020-11-10 18:54 ` Johannes Weiner 2020-11-11 17:46 ` Vlastimil Babka 2020-11-11 17:46 ` Vlastimil Babka 2020-11-11 17:59 ` Vlastimil Babka 2020-11-12 12:19 ` Vlastimil Babka 2020-11-12 12:19 ` Vlastimil Babka 2020-11-12 14:19 ` Alex Shi 2020-11-12 14:19 ` Alex Shi 2020-11-05 8:55 ` [PATCH v21 18/19] mm/lru: introduce the relock_page_lruvec function Alex Shi 2020-11-05 8:55 ` Alex Shi 2020-11-06 7:50 ` Alex Shi 2020-11-06 7:50 ` Alex Shi 2020-11-10 18:59 ` Johannes Weiner 2020-11-10 18:59 ` Johannes Weiner 2020-11-12 12:31 ` Vlastimil Babka 2020-11-12 12:31 ` Vlastimil Babka 2020-11-05 8:55 ` [PATCH v21 19/19] mm/lru: revise the comments of lru_lock Alex Shi 2020-11-12 12:37 ` Vlastimil Babka 2020-11-12 12:37 ` Vlastimil Babka 2020-11-10 12:14 ` [PATCH v21 00/19] per memcg lru lock Alex Shi 2020-11-10 12:14 ` Alex Shi 2020-11-16 3:45 ` Alex Shi 2020-11-16 3:45 ` Alex Shi 2020-12-15 0:47 ` Andrew Morton 2020-12-15 0:47 ` Andrew Morton 2020-12-15 2:16 ` Hugh Dickins 2020-12-15 2:16 ` Hugh Dickins 2020-12-15 2:16 ` Hugh Dickins 2020-12-15 2:28 ` Andrew Morton 2020-12-15 2:28 ` Andrew Morton 2021-01-05 19:30 ` Qian Cai 2021-01-05 19:30 ` Qian Cai 2021-01-05 19:30 ` Qian Cai 2021-01-05 19:42 ` Shakeel Butt 2021-01-05 19:42 ` Shakeel Butt 2021-01-05 19:42 ` Shakeel Butt 2021-01-05 20:11 ` Qian Cai 2021-01-05 20:11 ` Qian Cai 2021-01-05 20:11 ` Qian Cai 2021-01-05 21:35 ` Hugh Dickins 2021-01-05 21:35 ` Hugh Dickins 2021-01-05 21:35 ` Hugh Dickins 2021-01-05 22:01 ` Qian Cai 2021-01-05 22:01 ` Qian Cai 2021-01-05 22:01 ` Qian Cai 2021-01-06 3:10 ` Hugh Dickins 2021-01-06 3:10 ` Hugh Dickins 2021-01-06 3:10 ` Hugh Dickins
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=e66ef2e5-c74c-6498-e8b3-56c37b9d2d15@linux.alibaba.com \ --to=alex.shi@linux.alibaba.com \ --cc=akpm@linux-foundation.org \ --cc=alexander.duyck@gmail.com \ --cc=cgroups@vger.kernel.org \ --cc=daniel.m.jordan@oracle.com \ --cc=hannes@cmpxchg.org \ --cc=hughd@google.com \ --cc=iamjoonsoo.kim@lge.com \ --cc=khlebnikov@yandex-team.ru \ --cc=kirill@shutemov.name \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=lkp@intel.com \ --cc=mgorman@techsingularity.net \ --cc=mhocko@suse.com \ --cc=minchan@kernel.org \ --cc=richard.weiyang@gmail.com \ --cc=rong.a.chen@intel.com \ --cc=shakeelb@google.com \ --cc=shy828301@gmail.com \ --cc=tj@kernel.org \ --cc=vdavydov.dev@gmail.com \ --cc=willy@infradead.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: 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.