From: Jan Kara <jack@suse.cz>
To: Dongsu Park <dongsu.park@profitbricks.com>
Cc: Jan Kara <jack@suse.cz>, fstests@vger.kernel.org
Subject: Re: Test xfs/106 failure
Date: Wed, 18 Feb 2015 11:41:55 +0100 [thread overview]
Message-ID: <20150218104155.GC4614@quack.suse.cz> (raw)
In-Reply-To: <20150218102126.GA2631@posteo.de>
On Wed 18-02-15 11:21:26, Dongsu Park wrote:
> Hi Jan,
>
> On 17.02.2015 17:31, Jan Kara wrote:
> > Hello,
> > I'm consistently getting failure in xfs/106 test because the files
> > created by fsstress are just completely different from what they are
> > expected to be. It almost seems as if the random numbers generated for
> > fsstress are different. Anyone has seen this as well?
>
> That reminds me of a bug that has occurred every time when I run xfs/106.
> The crash happens only with CONFIG_XFS_DEBUG enabled.
> When I first discovered that, I disabled CONFIG_XFS_DEBUG as a workaround.
> As far as I remember, it started to occur since 3.19-rc?, and the first
> bad commit was 14bf61ffe6ac ("quota: Switch ->get_dqblk() and ->set_dqblk()
> to use bytes as space units"). I just tested it again with
> linux-block.git/for-3.20/drivers. The bug is still there.
Yesterday, I've sent a patch which should fix this
(http://www.spinics.net/lists/stable/msg79800.html). Above commit just
uncovered a long standing problem in XFS quota implementation...
Honza
> ====
> XFS (vdc1): Quotacheck: Done.
> XFS: Assertion failed: dst->d_spc_timer != 0, file: fs/xfs/xfs_qm_syscalls.c, line: 893
> ------------[ cut here ]------------
> kernel BUG at fs/xfs/xfs_message.c:106!
> invalid opcode: 0000 [#1] SMP
> CPU: 0 PID: 4031 Comm: xfs_quota Tainted: G W 3.19.0-rc7+ #174
> RIP: 0010:[<ffffffff813a9202>] [<ffffffff813a9202>] assfail+0x22/0x30
> Call Trace:
> [<ffffffff813d4de4>] xfs_qm_scall_getquota+0x284/0x330
> [<ffffffff813dce08>] xfs_fs_get_dqblk+0x68/0x90
> [<ffffffff81292b6f>] quota_getxquota+0x6f/0x200
> [<ffffffff812931cc>] SyS_quotactl+0x4cc/0x740
> [<ffffffff817f4cf7>] ? sysret_check+0x1b/0x56
> [<ffffffff8151aa1b>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [<ffffffff817f4cd2>] system_call_fastpath+0x12/0x17
> RIP [<ffffffff813a9202>] assfail+0x22/0x30
> RSP <ffff88007a9e7d08>
> ---[ end trace 308df0cc6a9ba1d0 ]---
> ====
>
> > Honza
> >
> > --
> > Jan Kara <jack@suse.cz>
> > SUSE Labs, CR
> > --
> > To unsubscribe from this list: send the line "unsubscribe fstests" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2015-02-18 10:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-17 16:31 Test xfs/106 failure Jan Kara
2015-02-18 1:15 ` Dave Chinner
2015-02-18 10:21 ` Dongsu Park
2015-02-18 10:41 ` Jan Kara [this message]
2015-02-18 11:04 ` Dongsu Park
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=20150218104155.GC4614@quack.suse.cz \
--to=jack@suse.cz \
--cc=dongsu.park@profitbricks.com \
--cc=fstests@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 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.