From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org,
willy@linux.intel.com, dan.j.williams@intel.com,
kirill.shutemov@linux.intel.com, linux-nvdimm@lists.01.org,
jack@suse.cz, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] Revert "mm: take i_mmap_lock in unmap_mapping_range() for DAX"
Date: Thu, 1 Oct 2015 16:47:45 -0600 [thread overview]
Message-ID: <20151001224745.GB7634@linux.intel.com> (raw)
In-Reply-To: <20151001223240.GI27164@dastard>
On Fri, Oct 02, 2015 at 08:32:40AM +1000, Dave Chinner wrote:
> I couldn't work out what set of commits I needed to revert to get a
> clean revert, so I just reverted the commits and hacked out the
> revert failures to what looked ok. Feel free to send me a clean set
> of reverts, and I'll replace these patches with them... :)
Will do. I will queue the reverts in my external tree & ask Linus to pull
them into v4.3 so we don't ship with deadlocks.
> > Also, if I understood your previous mails correctly you were targeting the
> > first two revert patches for v4.3 so we get back to v4.2 level locking, and
> > the rest of the series will target v4.4, correct? How does this work? Do the
> > patches need to be split into two series and tested separately?
>
> Test it and push the reverts however you like. I don't care how the
> reverts get to 4.3 - I'll be carrying them locally in my trees from
> now and so my development and testing is now unaffected by the bugs
> that are in the 4.3 code. If you aren't going to push them for 4.3
> then I'd suggest that they go to linus along with the rest of the
> XFS changes in this series.
>
> FWIW, I'm quite happy to host all the pending DAX changes in a
> public git tree and ask for it to be included in linux-next. It's
> probably a good idea to do this because it makes it much easier to
> co-ordinate merges when we are touching multiple subsystems (ext4,
> xfs, dax, mm, etc). And it will help prevent the "patches molder on
> the list until Andrew hoovers them up" problem and so prevent this
> situation from happening in the future...
No objections from me. :) I agree that it would be nice to have a central
home for all the DAX patches.
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Dave Chinner <david@fromorbit.com>
Cc: jack@suse.cz, linux-nvdimm@lists.01.org,
linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
linux-fsdevel@vger.kernel.org, willy@linux.intel.com,
Ross Zwisler <ross.zwisler@linux.intel.com>,
dan.j.williams@intel.com, kirill.shutemov@linux.intel.com
Subject: Re: [PATCH 1/7] Revert "mm: take i_mmap_lock in unmap_mapping_range() for DAX"
Date: Thu, 1 Oct 2015 16:47:45 -0600 [thread overview]
Message-ID: <20151001224745.GB7634@linux.intel.com> (raw)
In-Reply-To: <20151001223240.GI27164@dastard>
On Fri, Oct 02, 2015 at 08:32:40AM +1000, Dave Chinner wrote:
> I couldn't work out what set of commits I needed to revert to get a
> clean revert, so I just reverted the commits and hacked out the
> revert failures to what looked ok. Feel free to send me a clean set
> of reverts, and I'll replace these patches with them... :)
Will do. I will queue the reverts in my external tree & ask Linus to pull
them into v4.3 so we don't ship with deadlocks.
> > Also, if I understood your previous mails correctly you were targeting the
> > first two revert patches for v4.3 so we get back to v4.2 level locking, and
> > the rest of the series will target v4.4, correct? How does this work? Do the
> > patches need to be split into two series and tested separately?
>
> Test it and push the reverts however you like. I don't care how the
> reverts get to 4.3 - I'll be carrying them locally in my trees from
> now and so my development and testing is now unaffected by the bugs
> that are in the 4.3 code. If you aren't going to push them for 4.3
> then I'd suggest that they go to linus along with the rest of the
> XFS changes in this series.
>
> FWIW, I'm quite happy to host all the pending DAX changes in a
> public git tree and ask for it to be included in linux-next. It's
> probably a good idea to do this because it makes it much easier to
> co-ordinate merges when we are touching multiple subsystems (ext4,
> xfs, dax, mm, etc). And it will help prevent the "patches molder on
> the list until Andrew hoovers them up" problem and so prevent this
> situation from happening in the future...
No objections from me. :) I agree that it would be nice to have a central
home for all the DAX patches.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org,
willy@linux.intel.com, dan.j.williams@intel.com,
kirill.shutemov@linux.intel.com, linux-nvdimm@ml01.01.org,
jack@suse.cz, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] Revert "mm: take i_mmap_lock in unmap_mapping_range() for DAX"
Date: Thu, 1 Oct 2015 16:47:45 -0600 [thread overview]
Message-ID: <20151001224745.GB7634@linux.intel.com> (raw)
In-Reply-To: <20151001223240.GI27164@dastard>
On Fri, Oct 02, 2015 at 08:32:40AM +1000, Dave Chinner wrote:
> I couldn't work out what set of commits I needed to revert to get a
> clean revert, so I just reverted the commits and hacked out the
> revert failures to what looked ok. Feel free to send me a clean set
> of reverts, and I'll replace these patches with them... :)
Will do. I will queue the reverts in my external tree & ask Linus to pull
them into v4.3 so we don't ship with deadlocks.
> > Also, if I understood your previous mails correctly you were targeting the
> > first two revert patches for v4.3 so we get back to v4.2 level locking, and
> > the rest of the series will target v4.4, correct? How does this work? Do the
> > patches need to be split into two series and tested separately?
>
> Test it and push the reverts however you like. I don't care how the
> reverts get to 4.3 - I'll be carrying them locally in my trees from
> now and so my development and testing is now unaffected by the bugs
> that are in the 4.3 code. If you aren't going to push them for 4.3
> then I'd suggest that they go to linus along with the rest of the
> XFS changes in this series.
>
> FWIW, I'm quite happy to host all the pending DAX changes in a
> public git tree and ask for it to be included in linux-next. It's
> probably a good idea to do this because it makes it much easier to
> co-ordinate merges when we are touching multiple subsystems (ext4,
> xfs, dax, mm, etc). And it will help prevent the "patches molder on
> the list until Andrew hoovers them up" problem and so prevent this
> situation from happening in the future...
No objections from me. :) I agree that it would be nice to have a central
home for all the DAX patches.
next prev parent reply other threads:[~2015-10-01 22:47 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-01 7:46 [PATCH 0/7] xfs, dax: fix the page fault/allocation mess Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 7:46 ` [PATCH 1/7] Revert "mm: take i_mmap_lock in unmap_mapping_range() for DAX" Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 8:35 ` kbuild test robot
2015-10-01 8:35 ` kbuild test robot
2015-10-01 8:35 ` kbuild test robot
2015-10-01 20:27 ` Ross Zwisler
2015-10-01 20:27 ` Ross Zwisler
2015-10-01 20:27 ` Ross Zwisler
2015-10-01 22:14 ` Williams, Dan J
2015-10-01 22:14 ` Williams, Dan J
2015-10-01 22:14 ` Williams, Dan J
2015-10-01 22:45 ` Ross Zwisler
2015-10-01 22:45 ` Ross Zwisler
2015-10-01 22:45 ` Ross Zwisler
2015-10-01 22:32 ` Dave Chinner
2015-10-01 22:32 ` Dave Chinner
2015-10-01 22:32 ` Dave Chinner
2015-10-01 22:47 ` Ross Zwisler [this message]
2015-10-01 22:47 ` Ross Zwisler
2015-10-01 22:47 ` Ross Zwisler
2015-10-01 7:46 ` [PATCH 2/7] Revert "dax: fix race between simultaneous faults" Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 7:46 ` [PATCH 3/7] xfs: fix inode size update overflow in xfs_map_direct() Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 7:46 ` [PATCH 4/7] xfs: introduce BMAPI_ZERO for allocating zeroed extents Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 7:46 ` [PATCH 5/7] xfs: Don't use unwritten extents for DAX Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 7:46 ` [PATCH 6/7] xfs: DAX does not use IO completion callbacks Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 7:46 ` [PATCH 7/7] xfs: add ->pfn_mkwrite support for DAX Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 7:46 ` Dave Chinner
2015-10-01 20:31 ` [PATCH 0/7] xfs, dax: fix the page fault/allocation mess Ross Zwisler
2015-10-01 20:31 ` Ross Zwisler
2015-10-01 20:31 ` Ross Zwisler
2015-10-01 22:54 ` Dave Chinner
2015-10-01 22:54 ` Dave Chinner
2015-10-01 22:54 ` Dave Chinner
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=20151001224745.GB7634@linux.intel.com \
--to=ross.zwisler@linux.intel.com \
--cc=dan.j.williams@intel.com \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=willy@linux.intel.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 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.