From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Ian Kent <raven@themaw.net>
Cc: Christoph Hellwig <hch@lst.de>, linux-xfs@vger.kernel.org
Subject: Re: About xfstests generic/361
Date: Mon, 28 Oct 2019 16:34:48 -0700 [thread overview]
Message-ID: <20191028233448.GB15221@magnolia> (raw)
In-Reply-To: <1d94634d5c990dc0d21673ff2596bd276b728ab1.camel@themaw.net>
On Mon, Oct 28, 2019 at 05:17:05PM +0800, Ian Kent wrote:
> Hi Darrick,
>
> Unfortunately I'm having a bit of trouble with my USB keyboard
> and random key repeats, I lost several important messages this
> morning due to it.
>
> Your report of the xfstests generic/361 problem was one of them
> (as was Christoph's mail about the mount code location, I'll post
> on that a bit later). So I'm going to have to refer to the posts
> and hope that I can supply enough context to avoid confusion.
>
> Sorry about this.
>
> Anyway, you posted:
>
> "Dunno what's up with this particular patch, but I see regressions on
> generic/361 (and similar asserts on a few others). The patches leading
> up to this patch do not generate this error."
>
> I've reverted back to a point more or less before moving the mount
> and super block handling code around and tried to reproduce the problem
> on my test VM and I din't see the problem.
>
> Is there anything I need to do when running the test, other have
> SCRATCH_MNT and SCRATCH_DEV defined in the local config, and the
> mount point, and the device existing?
Um... here's the kernel branch that I used:
https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=mount-api-crash
Along with:
MKFS_OPTIONS -- -m crc=0
MOUNT_OPTIONS -- -o usrquota,grpquota
and both TEST_DEV and SCRATCH_DEV pointed at boring scsi disks.
> This could have been a problem with the series I posted because
> I did have some difficulty resolving some conflicts along the
> way and may have made mistakes, hence reverting to earlier patches
> (but also keeping the recent small pre-patch changes).
Yeah, I had the same problem too; you might spot check the commits in
there just in case /I/ screwed them up.
(I would say 'or rebase on for-next' but (a) I don't know how
Christoph's mount cleanups intermix with that and (b) let's see if
this afternoon's for-next is less broken on s390 than this morning's was
<frown>)
--D
> Ian
>
next prev parent reply other threads:[~2019-10-28 23:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-28 9:17 About xfstests generic/361 Ian Kent
2019-10-28 23:34 ` Darrick J. Wong [this message]
2019-10-29 0:29 ` Ian Kent
2019-10-29 0:52 ` Darrick J. Wong
2019-10-29 1:11 ` Ian Kent
2019-10-29 2:02 ` Ian Kent
2019-10-30 1:23 ` Ian Kent
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=20191028233448.GB15221@magnolia \
--to=darrick.wong@oracle.com \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
--cc=raven@themaw.net \
/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