All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, kernel-team@lge.com,
	Matthew Wilcox <willy@infradead.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH] mm: do not access page->mapping directly on page_endio
Date: Fri, 24 Feb 2017 08:26:09 +0900	[thread overview]
Message-ID: <20170223232609.GA5631@bbox> (raw)
In-Reply-To: <20170222145316.GL5753@dhcp22.suse.cz>

On Wed, Feb 22, 2017 at 03:53:16PM +0100, Michal Hocko wrote:
> On Wed 22-02-17 23:35:17, Minchan Kim wrote:
> > On Wed, Feb 22, 2017 at 01:11:00PM +0100, Michal Hocko wrote:
> > > On Wed 22-02-17 14:39:24, Minchan Kim wrote:
> > > > With rw_page, page_endio is used for completing IO on a page
> > > > and it propagates write error to the address space if the IO
> > > > fails. The problem is it accesses page->mapping directly which
> > > > might be okay for file-backed pages but it shouldn't for
> > > > anonymous page. Otherwise, it can corrupt one of field from
> > > > anon_vma under us and system goes panic randomly.
> > > 
> > > I was about to say that anonymous pages shouldn't hit that path because
> > > the end_swap_bio_write doesn call page_endio. But then I've noticed that
> > 
> > No. For driver to support rw_page, every swap_writepage calls rw_page.
> > 
> > swap_writepage
> >   bdev_writepage
> >     ops->rw_page
> 
> Ohh, you are right, I have missed this option. I was looking at the
> normal swapout path which uses bio.
> 
> > > zram does call this function. On a closer look, though, it doesn't seem
> > > to call it with err != 0 so it cannot hit this path. So I am wondering
> > > whether this actually fixes anything. Why it has been marked for stable?
> > 
> > Look at other drivers to support rw_page, not zram, esp, brd.
> > They can be used for swap device and then can hit the case.
> > 
> > In fact, I encountered the BUG during zram development(i.e., it doesn't
> > land to upstream) and it was really hard to figure it out because it made
> > random crash, sometime mmap_sem lockdep, sometime other places where
> > places never related to zram/zsmalloc, sometime not reproducible.
> > 
> > When I consider how that bug is subtle and people do fast-swap test as brd,
> > it's worth to add stable mark, I think.
> 
> Sure, could you add this to the changelog. Along with Fixes tag? I
> suspect it is dd6bd0d9c7db ("swap: use bdev_read_page() /
> bdev_write_page()") which has introduced this but I didn't look too
> close. The patch is trivially correct.

Sure. Thanks for the review.

Andrew, Could you change description with this?

>From 9efb87a873db67a9e6ebf44fdabf7d05fe4b4e21 Mon Sep 17 00:00:00 2001
From: Minchan Kim <minchan@kernel.org>
Date: Fri, 4 Nov 2016 09:12:39 +0900
Subject: [PATCH v2] mm: do not access page->mapping directly on page_endio

With rw_page, page_endio is used for completing IO on a page
and it propagates write error to the address space if the IO
fails. The problem is it accesses page->mapping directly which
might be okay for file-backed pages but it shouldn't for
anonymous page. Otherwise, it can corrupt one of field from
anon_vma under us and system goes panic randomly.

swap_writepage
  bdev_writepage
    ops->rw_page

I encountered the BUG during developing new zram feature and
it was really hard to figure it out because it made random
crash, somtime mmap_sem lockdep, sometime other places where
places never related to zram/zsmalloc, and not reproducible
with some configuration.

When I consider how that bug is subtle and people do fast-swap
test with brd, it's worth to add stable mark, I think.

Fixes: dd6bd0d9c7db ("swap: use bdev_read_page() / bdev_write_page()")
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
* from v1
  * add more detailed description with Fix tag - Michal

 mm/filemap.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/mm/filemap.c b/mm/filemap.c
index 2ba46f410c7c..1944c631e3e6 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1008,9 +1008,12 @@ void page_endio(struct page *page, bool is_write, int err)
 		unlock_page(page);
 	} else {
 		if (err) {
+			struct address_space *mapping;
+
 			SetPageError(page);
-			if (page->mapping)
-				mapping_set_error(page->mapping, err);
+			mapping = page_mapping(page);
+			if (mapping)
+				mapping_set_error(mapping, err);
 		}
 		end_page_writeback(page);
 	}
-- 
2.7.4

  reply	other threads:[~2017-02-23 23:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-22  5:39 [PATCH] mm: do not access page->mapping directly on page_endio Minchan Kim
2017-02-22 12:11 ` Michal Hocko
2017-02-22 14:35   ` Minchan Kim
2017-02-22 14:53     ` Michal Hocko
2017-02-23 23:26       ` Minchan Kim [this message]
2017-02-24  9:13         ` Michal Hocko

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=20170223232609.GA5631@bbox \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=kernel-team@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=stable@vger.kernel.org \
    --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: 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.