From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: byte range buffer dirty region tracking
Date: Fri, 2 Feb 2018 10:55:48 +1100 [thread overview]
Message-ID: <20180201235548.7hmuu6ws5cxouzee@destitution> (raw)
In-Reply-To: <20180201232258.GW4849@magnolia>
On Thu, Feb 01, 2018 at 03:22:58PM -0800, Darrick J. Wong wrote:
> On Fri, Feb 02, 2018 at 10:16:47AM +1100, Dave Chinner wrote:
> > On Thu, Feb 01, 2018 at 12:35:26PM -0800, Darrick J. Wong wrote:
> > > FWIW I also ran straight into this when I applied it for giggles and ran
> > > xfstests -g quick (generic/001 blew up):
> >
> > I must have screwed up the forward port worse than usual - the
> > conflicts with the xfs_buf_log_item typedef removal were pretty
> > extensive.
>
> Ah, sorry about that. I'd thought it was just the xfs_buf rename. :/
Not your fault at all, Darrick!
I only complained about the xfs_buf typedef because it would cause
merge problems for ~80% of the patches in my current dev tree. This
was the only patch that the xfs_buf_log_item typedef removal
affected - more were affected by the trivial b_fspriv to b_log_item
changeover - and I figured that pain was worth it to get rid of
another typedef....
> > > [ 31.909228] ================================================================================
> > > [ 31.911258] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
> > > [ 31.912375] IP: xfs_buf_item_init+0x33/0x350 [xfs]
> >
> > Hmmmm - I'm seeing that on my subvol smoke test script but not
> > elsewhere. I've been looking through the subvol code to try to find
> > this, maybe it's not the subvol code. What mkfs parameters where
> > you using?
>
> mkfs.xfs -m rmapbt=1,reflink=1 -i sparse=1 /dev/pmem0
OK, nothing unusual, though I haven't been using sparse=1 recently.
I'll get onto it....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-02-01 23:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-01 1:05 [PATCH] xfs: byte range buffer dirty region tracking Dave Chinner
2018-02-01 5:11 ` Darrick J. Wong
2018-02-01 8:14 ` Dave Chinner
2018-02-01 20:35 ` Darrick J. Wong
2018-02-01 23:16 ` Dave Chinner
2018-02-01 23:22 ` Darrick J. Wong
2018-02-01 23:55 ` Dave Chinner [this message]
2018-02-02 10:56 ` Brian Foster
2018-02-05 0:34 ` [PATCH v2] " Dave Chinner
2018-02-06 16:21 ` Brian Foster
2018-02-12 2:41 ` Dave Chinner
2018-02-12 14:26 ` Brian Foster
2018-02-12 21:18 ` Dave Chinner
2018-02-13 13:15 ` Brian Foster
2018-02-13 22:02 ` Dave Chinner
2018-02-14 13:09 ` Brian Foster
2018-02-14 16:49 ` Darrick J. Wong
2018-02-14 18:08 ` Brian Foster
2018-02-14 22:05 ` Dave Chinner
2018-02-14 22:30 ` Dave Chinner
2018-02-15 13:42 ` Brian Foster
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=20180201235548.7hmuu6ws5cxouzee@destitution \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).