From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 2/4] xfs: byte range granularity for XFS_IOC_ZERO_RANGE
Date: Thu, 29 Nov 2012 15:18:44 +1100 [thread overview]
Message-ID: <20121129041844.GZ6434@dastard> (raw)
In-Reply-To: <20121129015406.GX6434@dastard>
On Thu, Nov 29, 2012 at 12:54:06PM +1100, Dave Chinner wrote:
> On Wed, Nov 28, 2012 at 07:06:55PM -0500, Christoph Hellwig wrote:
> > Actually this seems to trip up an assert in xfstests 290 for me:
> >
> > 290 0s ...[ 45.997814] XFS: Assertion failed: offset + len <= start_boundary || offset == start_boundary, file: fs/xfs/xfs_vnodeops.c, line: 2153
>
> Yes, i got that in one of my overnight QA runs. Haven't had a chance
> to debug it yet.
Ok, I've decided that the ASSERT is simply bogus. It was there
because I initially thought that this breanch woul dbe taken for
sub-page zeroing. In fact, it's not just sub-page zeroing - the
region can span two sub-pages. i.e.:
0 4096 8192
+------o------+-------------+
|----len------|
In this case, offset is 4095, len = 4096, resulting in start/end =
4096. Hence we trigger the pure zeroing branch , and off+len is
clearly greater then start or end....
This is why I put the ASSERT in there, anyway - to validate that my
assumptions that lead to having that branch were correct. Turns out
the assumption was wrong but the code is correct for both cases, so
I'm just going to remove the ASSERT now.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-11-29 4:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-28 2:00 [PATCH 0/4] xfs: patch queue for 3.8 Dave Chinner
2012-11-28 2:01 ` [PATCH 1/4] xfs: fix direct IO nested transaction deadlock Dave Chinner
2012-11-28 13:27 ` Christoph Hellwig
2012-11-28 2:01 ` [PATCH 2/4] xfs: byte range granularity for XFS_IOC_ZERO_RANGE Dave Chinner
2012-11-28 13:33 ` Christoph Hellwig
2012-11-29 0:06 ` Christoph Hellwig
2012-11-29 1:54 ` Dave Chinner
2012-11-29 4:18 ` Dave Chinner [this message]
2012-11-29 4:26 ` [PATCH 2/4 V2] " Dave Chinner
2012-11-29 18:19 ` Andrew Dahl
2012-11-30 16:07 ` Christoph Hellwig
2012-11-28 2:01 ` [PATCH 3/4] xfs: fix stray dquot unlock when reclaiming dquots Dave Chinner
2012-11-28 13:28 ` Christoph Hellwig
2012-11-28 2:01 ` [PATCH 4/4] xfs: fix sparse reported log CRC endian issue Dave Chinner
2012-11-28 13:30 ` Christoph Hellwig
2012-11-28 21:31 ` Dave Chinner
2012-11-29 20:32 ` Ben Myers
2012-11-30 16:03 ` Christoph Hellwig
2012-11-30 16:04 ` Ben Myers
2012-12-03 18:18 ` Ben Myers
2012-11-29 22:29 ` Mark Tinguely
2012-11-29 21:22 ` [PATCH 0/4] xfs: patch queue for 3.8 Ben Myers
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=20121129041844.GZ6434@dastard \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--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