public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: bufferhead chains are invalid after end_page_writeback
Date: Thu, 21 Jul 2016 10:16:01 -0400	[thread overview]
Message-ID: <20160721141600.GA15597@bfoster.bfoster> (raw)
In-Reply-To: <1468974083-3660-1-git-send-email-david@fromorbit.com>

On Wed, Jul 20, 2016 at 10:21:23AM +1000, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> In xfs_finish_page_writeback(), we have a loop that looks like this:
> 
>         do {
>                 if (off < bvec->bv_offset)
>                         goto next_bh;
>                 if (off > end)
>                         break;
>                 bh->b_end_io(bh, !error);
> next_bh:
>                 off += bh->b_size;
>         } while ((bh = bh->b_this_page) != head);
> 
> The b_end_io function is end_buffer_async_write(), which will call
> end_page_writeback() once all the buffers have marked as no longer
> under IO.  This issue here is that the only thing currently
> protecting both the bufferhead chain and the page from being
> reclaimed is the PageWriteback state held on the page.
> 
> While we attempt to limit the loop to just the buffers covered by
> the IO, we still read from the buffer size and follow the next
> pointer in the bufferhead chain. There is no guarantee that either
> of these are valid after the PageWriteback flag has been cleared.
> Hence, loops like this are completely unsafe, and result in
> use-after-free issues. One such problem was caught by Calvin Owens
> with KASAN:
> 
...
> 
> 
> Where the access is occuring during IO completion after the buffer
> had been freed from direct memory reclaim.
> 
> Prevent use-after-free accidents in this end_io processing loop by
> pre-calculating the loop conditionals before calling bh->b_end_io().
> The loop is already limited to just the bufferheads covered by the
> IO in progress, so the offset checks are sufficient to prevent
> accessing buffers in the chain after end_page_writeback() has been
> called by the the bh->b_end_io() callout.
> 
> Yet another example of why Bufferheads Must Die.
> 
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> Reported-and-Tested-by: Calvin Owens <calvinowens@fb.com>
> ---

Reviewed-by: Brian Foster <bfoster@redhat.com>

>  fs/xfs/xfs_aops.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
> index 80714eb..0cfb944 100644
> --- a/fs/xfs/xfs_aops.c
> +++ b/fs/xfs/xfs_aops.c
> @@ -87,6 +87,12 @@ xfs_find_bdev_for_inode(
>   * We're now finished for good with this page.  Update the page state via the
>   * associated buffer_heads, paying attention to the start and end offsets that
>   * we need to process on the page.
> + *
> + * Landmine Warning: bh->b_end_io() will call end_page_writeback() on the last
> + * buffer in the IO. Once it does this, it is unsafe to access the bufferhead or
> + * the page at all, as we may be racing with memory reclaim and it can free both
> + * the bufferhead chain and the page as it will see the page as clean and
> + * unused.
>   */
>  static void
>  xfs_finish_page_writeback(
> @@ -95,8 +101,9 @@ xfs_finish_page_writeback(
>  	int			error)
>  {
>  	unsigned int		end = bvec->bv_offset + bvec->bv_len - 1;
> -	struct buffer_head	*head, *bh;
> +	struct buffer_head	*head, *bh, *next;
>  	unsigned int		off = 0;
> +	unsigned int		bsize;
>  
>  	ASSERT(bvec->bv_offset < PAGE_SIZE);
>  	ASSERT((bvec->bv_offset & ((1 << inode->i_blkbits) - 1)) == 0);
> @@ -105,15 +112,17 @@ xfs_finish_page_writeback(
>  
>  	bh = head = page_buffers(bvec->bv_page);
>  
> +	bsize = bh->b_size;
>  	do {
> +		next = bh->b_this_page;
>  		if (off < bvec->bv_offset)
>  			goto next_bh;
>  		if (off > end)
>  			break;
>  		bh->b_end_io(bh, !error);
>  next_bh:
> -		off += bh->b_size;
> -	} while ((bh = bh->b_this_page) != head);
> +		off += bsize;
> +	} while ((bh = next) != head);
>  }
>  
>  /*
> -- 
> 2.8.0.rc3
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2016-07-21 14:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-20  0:21 [PATCH] xfs: bufferhead chains are invalid after end_page_writeback Dave Chinner
2016-07-21 14:16 ` Brian Foster [this message]
2016-07-21 14:32 ` Christoph Hellwig
2016-07-21 23:15   ` Dave Chinner

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=20160721141600.GA15597@bfoster.bfoster \
    --to=bfoster@redhat.com \
    --cc=david@fromorbit.com \
    --cc=xfs@oss.sgi.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: 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