Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Liu Bo <bo.li.liu@oracle.com>
To: Chris Mason <clm@fb.com>, Dave Jones <davej@codemonkey.org.uk>,
	jbacik@fb.com, dsterba@suse.com, linux-btrfs@vger.kernel.org,
	Filipe Manana <fdmanana@kernel.org>
Subject: Re: !PageLocked BUG_ON hit in clear_page_dirty_for_io
Date: Mon, 14 Dec 2015 17:33:45 -0800	[thread overview]
Message-ID: <20151215013345.GI10403@localhost.localdomain> (raw)
In-Reply-To: <20151215000324.GD3570@ret.masoncoding.com>

On Mon, Dec 14, 2015 at 07:03:24PM -0500, Chris Mason wrote:
> On Tue, Dec 08, 2015 at 11:25:28PM -0500, Dave Jones wrote:
> > Not sure if I've already reported this one, but I've been seeing this
> > a lot this last couple days.
> > 
> > kernel BUG at mm/page-writeback.c:2654!
> > invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
> 
> We ended up discussing this in more detail on lkml, but I'll summarize
> here.
> 
> There were two problems.  First lock_page() might not actually lock the
> page in v4.4-rc4, it can bail out if a signal is pending.  This got
> fixed just before v4.4-rc5, so if you were on rc4, upgrade asap.
> 
> Second, prepare_pages had a bug for single page writes:
> 
> From f0be89af049857bcc537a53fe2a2fae080e7a5bd Mon Sep 17 00:00:00 2001
> From: Chris Mason <clm@fb.com>
> Date: Mon, 14 Dec 2015 15:40:44 -0800
> Subject: [PATCH] Btrfs: check prepare_uptodate_page() error code earlier
> 
> prepare_pages() may end up calling prepare_uptodate_page() twice if our
> write only spans a single page.  But if the first call returns an error,
> our page will be unlocked and its not safe to call it again.
> 
> This bug goes all the way back to 2011, and it's not something commonly
> hit.
> 
> While we're here, add a more explicit check for the page being truncated
> away.  The bare lock_page() alone is protected only by good thoughts and
> i_mutex, which we're sure to regret eventually.

Reviewed-by: Liu Bo <bo.li.liu@oracle.com>

Thanks,

-liubo
> 
> Reported-by: Dave Jones <dsj@fb.com>
> Signed-off-by: Chris Mason <clm@fb.com>
> ---
>  fs/btrfs/file.c | 18 ++++++++++++++----
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
> index 72e7346..0f09526 100644
> --- a/fs/btrfs/file.c
> +++ b/fs/btrfs/file.c
> @@ -1291,7 +1291,8 @@ out:
>   * on error we return an unlocked page and the error value
>   * on success we return a locked page and 0
>   */
> -static int prepare_uptodate_page(struct page *page, u64 pos,
> +static int prepare_uptodate_page(struct inode *inode,
> +				 struct page *page, u64 pos,
>  				 bool force_uptodate)
>  {
>  	int ret = 0;
> @@ -1306,6 +1307,10 @@ static int prepare_uptodate_page(struct page *page, u64 pos,
>  			unlock_page(page);
>  			return -EIO;
>  		}
> +		if (page->mapping != inode->i_mapping) {
> +			unlock_page(page);
> +			return -EAGAIN;
> +		}
>  	}
>  	return 0;
>  }
> @@ -1324,6 +1329,7 @@ static noinline int prepare_pages(struct inode *inode, struct page **pages,
>  	int faili;
>  
>  	for (i = 0; i < num_pages; i++) {
> +again:
>  		pages[i] = find_or_create_page(inode->i_mapping, index + i,
>  					       mask | __GFP_WRITE);
>  		if (!pages[i]) {
> @@ -1333,13 +1339,17 @@ static noinline int prepare_pages(struct inode *inode, struct page **pages,
>  		}
>  
>  		if (i == 0)
> -			err = prepare_uptodate_page(pages[i], pos,
> +			err = prepare_uptodate_page(inode, pages[i], pos,
>  						    force_uptodate);
> -		if (i == num_pages - 1)
> -			err = prepare_uptodate_page(pages[i],
> +		if (!err && i == num_pages - 1)
> +			err = prepare_uptodate_page(inode, pages[i],
>  						    pos + write_bytes, false);
>  		if (err) {
>  			page_cache_release(pages[i]);
> +			if (err == -EAGAIN) {
> +				err = 0;
> +				goto again;
> +			}
>  			faili = i - 1;
>  			goto fail;
>  		}
> -- 
> 2.4.6
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2015-12-15  1:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-09  4:25 !PageLocked BUG_ON hit in clear_page_dirty_for_io Dave Jones
2015-12-10 15:09 ` Markus Trippelsdorf
2015-12-10 19:02 ` Chris Mason
2015-12-10 19:35   ` Dave Jones
2015-12-10 21:30     ` Chris Mason
2015-12-10 21:35       ` Liu Bo
2015-12-10 21:51         ` Filipe Manana
2015-12-10 22:57       ` Dave Jones
2015-12-11  3:59         ` Dave Jones
2015-12-10 23:58       ` Dave Jones
2015-12-10 20:42   ` Georg Lukas
2015-12-15  0:03 ` Chris Mason
2015-12-15  1:33   ` Liu Bo [this message]
2015-12-15 19:36   ` Filipe Manana

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=20151215013345.GI10403@localhost.localdomain \
    --to=bo.li.liu@oracle.com \
    --cc=clm@fb.com \
    --cc=davej@codemonkey.org.uk \
    --cc=dsterba@suse.com \
    --cc=fdmanana@kernel.org \
    --cc=jbacik@fb.com \
    --cc=linux-btrfs@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox