Re: what's in nvdimm.git for v4.4?

[Dan Williams]

On Tue, Oct 20, 2015 at 7:38 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> On Tue, Oct 20, 2015 at 05:31:18PM -0700, Dan Williams wrote:
>> On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>> > On Tue, Oct 20, 2015 at 11:31:45PM +0000, Williams, Dan J wrote:
>> >> Here is a status summary of the topic-branches nvdimm.git is tracking
>> >> for v4.4.  Unless indicated these branches are not present in -next.
>> >> Please ACK, NAK, or ask for a re-post of any of the below to disposition
>> >> it for the merge window.
>> >>
>> >> ===
>> >> for-4.4/dax-fixes:
>> >> ===
>> > ...
>> >>         Dave Chinner (5):
>> >>               xfs: fix inode size update overflow in xfs_map_direct()
>> >>               xfs: introduce BMAPI_ZERO for allocating zeroed extents
>> >>               xfs: Don't use unwritten extents for DAX
>> >>               xfs: DAX does not use IO completion callbacks
>> >>               xfs: add ->pfn_mkwrite support for DAX
>> >
>> > Please drop these. They have not been reviewed yet, and because
>> > the changes affect more than just DAX (core XFS allocator
>> > functionality was changed) these need to go through the XFS tree.
>> >
>>
>> Ok, thanks for the heads up.  For the get_user_pages() patches that
>> build on these fixes I'm assuming your review bandwidth is in short
>> supply to also give an XFS sign-off on those changes for 4.4?
>
> I'm not aware of any other patches that touch XFS. AFAIA, you
> haven't cc'd anything to xfs@xxxxxxxxxxx, so it's not on my radar...
>

I can cc xfs@xxxxxxxxxxx on fs/dax.c changes going forward, but for
these I figure it was off topic since nothing touched fs/xfs/.

>> I'm wondering if we can take a conservative step forward with those
>> patches for 4.4.  if XFS and EXT4 interactions need more time to get
>> worked out, which I believe they do, I can conceive just turning on
>> get_user_pages() support for DAX-mappings of the raw block device.
>
> Regardless of the ext4/XFS status, isn't it a bit late to be
> proposing brand new stuff that nobody has had time to think about
> for the next merge window?
>

The "dax-for-raw-block support" is indeed new, but it's a fairly
straightforward extension of these patches that have been out for
review since 4.3-rc2, or 4.1-rc6 in the case of the pfn_t enabling.
Cutting out the filesystem interactions makes it that much simpler to
comprehend.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/