public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Jeff Liu <jeff.liu@oracle.com>
Cc: "Michael L. Semon" <mlsemon35@gmail.com>,
	"xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: Re: [PATCH v2] xfs: fix assertion failure in xfs_vm_write_failed()
Date: Wed, 20 Mar 2013 06:23:22 +1100	[thread overview]
Message-ID: <20130319192322.GB6369@dastard> (raw)
In-Reply-To: <514800DB.5070306@oracle.com>

On Tue, Mar 19, 2013 at 02:08:27PM +0800, Jeff Liu wrote:
> On 03/19/2013 07:30 AM, Dave Chinner wrote:
> From: Jie Liu <jeff.liu@oracle.com>
> 
> In xfs_vm_write_failed(), we evaluate the block_offset of pos with PAGE_MASK
> which is 0xfffff000 as an unsigned long,

That's the 32 bit value. if it's a 64 bit value, it's
0xfffffffffffff000.

> that is fine on 64-bit platforms no
> matter the request pos is 32-bit or 64-bit.  However, on 32-bit platforms,
> the high 32-bit in it will be masked off with (pos & PAGE_MASK) for 64-bit pos
> request.  As a result, the evaluated block_offset is incorrect which will cause
> the ASSERT() failed: ASSERT(block_offset + from == pos);

So I'd just rearrange this slightly:

> In xfs_vm_write_failed(), we evaluate the block_offset of pos with PAGE_MASK
> which is an unsigned long. That is fine on 64-bit platforms
> regardless of whether the request pos is 32-bit or 64-bit.
> However, on 32-bit platforms, the value is 0xfffff000 and so
> the high 32 bits in it will be masked off with (pos & PAGE_MASK)
> for a 64-bit pos As a result, the evaluated block_offset is
> incorrect which will cause this failure ASSERT(block_offset + from
> == pos); and potentially pass the wrong block to
> xfs_vm_kill_delalloc_range().

...
> This patch fix the block_offset evaluation to clear the lower 12 bits as:
> block_offset = pos >> PAGE_CACHE_SHIFT) << PAGE_CACHE_SHIFT
> Hence, the ASSERTION should be correct because the from offset in a page is
> evaluated to have the lower 12 bits only.

Saying we are clearing the lower 12 bits is not technically correct,
as there are platforms with different page sizes. What we are
actually calculating is the offset at the start of the page....

> diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
> index 5f707e5..f26a341 100644
> --- a/fs/xfs/xfs_aops.c
> +++ b/fs/xfs/xfs_aops.c
> @@ -1494,13 +1494,25 @@ xfs_vm_write_failed(
>  	loff_t			pos,
>  	unsigned		len)
>  {
> -	loff_t			block_offset = pos & PAGE_MASK;
> +	loff_t			block_offset;
>  	loff_t			block_start;
>  	loff_t			block_end;
>  	loff_t			from = pos & (PAGE_CACHE_SIZE - 1);
>  	loff_t			to = from + len;
>  	struct buffer_head	*bh, *head;
>  
> +	/*
> +	 * The request pos offset might be 32 or 64 bit, this is all fine
> +	 * on 64-bit platform.  However, for 64-bit pos request on 32-bit
> +	 * platform, the high 32-bit will be masked off if we evaluate the
> +	 * block_offset via (pos & PAGE_MASK) because the PAGE_MASK is
> +	 * 0xfffff000 as an unsigned long, hence the result is incorrect
> +	 * which could cause the following ASSERT failed in most cases.
> +	 * In order to avoid this, we can evaluate the block_offset with
> +	 * the lower 12-bit masked out and the ASSERT should be correct.

Same here:

	* In order to avoid this, we can evaluate the block_offset
	* of the start of the page by using shifts rather than masks
	* the mismatch problem.
> +	 */
> +	block_offset = (pos >> PAGE_CACHE_SHIFT) << PAGE_CACHE_SHIFT;
> +
>  	ASSERT(block_offset + from == pos);
>  
>  	head = page_buffers(page);

As for the code, it looks fine. Hence with the comments/commit
fixups, you can add:

Reviewed-by: Dave Chinner <dchinner@redhat.com>

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

  reply	other threads:[~2013-03-19 19:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-18  4:48 [PATCH v2] xfs: fix assertion failure in xfs_vm_write_failed() Jeff Liu
2013-03-18 20:03 ` Michael L. Semon
2013-03-18 23:30 ` Dave Chinner
2013-03-19  6:08   ` Jeff Liu
2013-03-19 19:23     ` Dave Chinner [this message]
2013-03-20  2:18       ` Jeff Liu
2013-04-08 21:47         ` Mark Tinguely

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=20130319192322.GB6369@dastard \
    --to=david@fromorbit.com \
    --cc=jeff.liu@oracle.com \
    --cc=mlsemon35@gmail.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