From: Minchan Kim <minchan@kernel.org> To: "Huang, Ying" <ying.huang@intel.com> Cc: Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mel Gorman <mgorman@techsingularity.net>, Jan Kara <jack@suse.cz>, Johannes Weiner <hannes@cmpxchg.org>, Michal Hocko <mhocko@suse.com>, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] mm: Fix races between address_space dereference and free in page_evicatable Date: Sun, 18 Feb 2018 18:22:45 +0900 [thread overview] Message-ID: <20180218092245.GA52741@rodete-laptop-imager.corp.google.com> (raw) In-Reply-To: <20180212081227.1940-1-ying.huang@intel.com> Hi Huang, On Mon, Feb 12, 2018 at 04:12:27PM +0800, Huang, Ying wrote: > From: Huang Ying <ying.huang@intel.com> > > When page_mapping() is called and the mapping is dereferenced in > page_evicatable() through shrink_active_list(), it is possible for the > inode to be truncated and the embedded address space to be freed at > the same time. This may lead to the following race. > > CPU1 CPU2 > > truncate(inode) shrink_active_list() > ... page_evictable(page) > truncate_inode_page(mapping, page); > delete_from_page_cache(page) > spin_lock_irqsave(&mapping->tree_lock, flags); > __delete_from_page_cache(page, NULL) > page_cache_tree_delete(..) > ... mapping = page_mapping(page); > page->mapping = NULL; > ... > spin_unlock_irqrestore(&mapping->tree_lock, flags); > page_cache_free_page(mapping, page) > put_page(page) > if (put_page_testzero(page)) -> false > - inode now has no pages and can be freed including embedded address_space > > mapping_unevictable(mapping) > test_bit(AS_UNEVICTABLE, &mapping->flags); > - we've dereferenced mapping which is potentially already free. > > Similar race exists between swap cache freeing and page_evicatable() too. > > The address_space in inode and swap cache will be freed after a RCU > grace period. So the races are fixed via enclosing the page_mapping() > and address_space usage in rcu_read_lock/unlock(). Some comments are > added in code to make it clear what is protected by the RCU read lock. Is it always true for every FSes, even upcoming FSes? IOW, do we have any strict rule FS folks must use RCU(i.e., call_rcu) to destroy inode? Let's cc linux-fs. > > Signed-off-by: "Huang, Ying" <ying.huang@intel.com> > Cc: Mel Gorman <mgorman@techsingularity.net> > Cc: Minchan Kim <minchan@kernel.org> > Cc: "Huang, Ying" <ying.huang@intel.com> > Cc: Jan Kara <jack@suse.cz> > Cc: Johannes Weiner <hannes@cmpxchg.org> > Cc: Michal Hocko <mhocko@suse.com> > --- > mm/vmscan.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index d1c1e00b08bb..10a0f32a3f90 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -3886,7 +3886,13 @@ int node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask, unsigned int order) > */ > int page_evictable(struct page *page) > { > - return !mapping_unevictable(page_mapping(page)) && !PageMlocked(page); > + int ret; > + > + /* Prevent address_space of inode and swap cache from being freed */ > + rcu_read_lock(); > + ret = !mapping_unevictable(page_mapping(page)) && !PageMlocked(page); > + rcu_read_unlock(); > + return ret; > } > > #ifdef CONFIG_SHMEM > -- > 2.15.1 >
WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org> To: "Huang, Ying" <ying.huang@intel.com> Cc: Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mel Gorman <mgorman@techsingularity.net>, Jan Kara <jack@suse.cz>, Johannes Weiner <hannes@cmpxchg.org>, Michal Hocko <mhocko@suse.com>, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] mm: Fix races between address_space dereference and free in page_evicatable Date: Sun, 18 Feb 2018 18:22:45 +0900 [thread overview] Message-ID: <20180218092245.GA52741@rodete-laptop-imager.corp.google.com> (raw) In-Reply-To: <20180212081227.1940-1-ying.huang@intel.com> Hi Huang, On Mon, Feb 12, 2018 at 04:12:27PM +0800, Huang, Ying wrote: > From: Huang Ying <ying.huang@intel.com> > > When page_mapping() is called and the mapping is dereferenced in > page_evicatable() through shrink_active_list(), it is possible for the > inode to be truncated and the embedded address space to be freed at > the same time. This may lead to the following race. > > CPU1 CPU2 > > truncate(inode) shrink_active_list() > ... page_evictable(page) > truncate_inode_page(mapping, page); > delete_from_page_cache(page) > spin_lock_irqsave(&mapping->tree_lock, flags); > __delete_from_page_cache(page, NULL) > page_cache_tree_delete(..) > ... mapping = page_mapping(page); > page->mapping = NULL; > ... > spin_unlock_irqrestore(&mapping->tree_lock, flags); > page_cache_free_page(mapping, page) > put_page(page) > if (put_page_testzero(page)) -> false > - inode now has no pages and can be freed including embedded address_space > > mapping_unevictable(mapping) > test_bit(AS_UNEVICTABLE, &mapping->flags); > - we've dereferenced mapping which is potentially already free. > > Similar race exists between swap cache freeing and page_evicatable() too. > > The address_space in inode and swap cache will be freed after a RCU > grace period. So the races are fixed via enclosing the page_mapping() > and address_space usage in rcu_read_lock/unlock(). Some comments are > added in code to make it clear what is protected by the RCU read lock. Is it always true for every FSes, even upcoming FSes? IOW, do we have any strict rule FS folks must use RCU(i.e., call_rcu) to destroy inode? Let's cc linux-fs. > > Signed-off-by: "Huang, Ying" <ying.huang@intel.com> > Cc: Mel Gorman <mgorman@techsingularity.net> > Cc: Minchan Kim <minchan@kernel.org> > Cc: "Huang, Ying" <ying.huang@intel.com> > Cc: Jan Kara <jack@suse.cz> > Cc: Johannes Weiner <hannes@cmpxchg.org> > Cc: Michal Hocko <mhocko@suse.com> > --- > mm/vmscan.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index d1c1e00b08bb..10a0f32a3f90 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -3886,7 +3886,13 @@ int node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask, unsigned int order) > */ > int page_evictable(struct page *page) > { > - return !mapping_unevictable(page_mapping(page)) && !PageMlocked(page); > + int ret; > + > + /* Prevent address_space of inode and swap cache from being freed */ > + rcu_read_lock(); > + ret = !mapping_unevictable(page_mapping(page)) && !PageMlocked(page); > + rcu_read_unlock(); > + return ret; > } > > #ifdef CONFIG_SHMEM > -- > 2.15.1 > -- 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:[~2018-02-18 9:22 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-02-12 8:12 [PATCH] mm: Fix races between address_space dereference and free in page_evicatable Huang, Ying 2018-02-12 8:12 ` Huang, Ying 2018-02-15 9:18 ` Jan Kara 2018-02-15 9:18 ` Jan Kara 2018-02-18 9:22 ` Minchan Kim [this message] 2018-02-18 9:22 ` Minchan Kim 2018-02-19 10:57 ` Jan Kara 2018-02-19 10:57 ` Jan Kara 2018-02-26 5:20 ` Minchan Kim 2018-02-26 5:20 ` Minchan Kim 2018-02-26 6:38 ` Huang, Ying 2018-02-26 6:38 ` Huang, Ying 2018-02-26 6:38 ` Huang, Ying 2018-02-26 7:36 ` Minchan Kim 2018-02-26 7:36 ` Minchan Kim
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=20180218092245.GA52741@rodete-laptop-imager.corp.google.com \ --to=minchan@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=hannes@cmpxchg.org \ --cc=jack@suse.cz \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@techsingularity.net \ --cc=mhocko@suse.com \ --cc=ying.huang@intel.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.