All of lore.kernel.org
 help / color / mirror / Atom feed
* what's in nvdimm.git for v4.4?
@ 2015-10-20 23:31 ` Williams, Dan J
  0 siblings, 0 replies; 24+ messages in thread
From: Williams, Dan J @ 2015-10-20 23:31 UTC (permalink / raw)
  To: axboe, akpm, Wysocki, Rafael J
  Cc: linux-kernel, hch, martin.petersen, linux-nvdimm, linux-fsdevel,
	linux-acpi, david, jack

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:
===

        Core DAX and XFS fixes for DAX locking.  They are carried in
        nvdimm.git as a dependency of the for-4.4/dax-gup branch.
                
        Dan Williams (1):
              pmem, dax: clean up clear_pmem()
        
        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
        
        Ross Zwisler (2):
              dax: dax_pfn_mkwrite() truncate race check
              ext2: Add locking for DAX faults

===
for-4.4/numa:
===

        Minor api cleanups that have been acked and published in -next
        for a few weeks.

        Dan Williams (7):
              x86, mm: quiet arch_add_memory()
              pmem: kill memremap_pmem()
              devm_memunmap: use devres_release()
              devm_memremap: convert to return ERR_PTR
              devm: make allocations numa aware by default
              devm_memremap_pages: use numa_mem_id
              pmem, memremap: convert to numa aware allocations
        
===
for-4.4/dax-gup: get_user_pages() support for dax mappings
https://lists.01.org/pipermail/linux-nvdimm/2015-October/002387.html
===

        Needs acks from core -mm folks particularly for:
                x86, mm: introduce vmem_altmap to augment
                vmemmap_populate()
                mm, x86: get_user_pages() for dax mappings
        
        Dan Williams (22):
              block: generic request_queue reference counting
              dax: increase granularity of dax_clear_blocks() operations
              block, dax: fix lifetime of in-kernel dax mappings with dax_map_atomic()
              mm: introduce __get_dev_pagemap()
              x86, mm: introduce vmem_altmap to augment vmemmap_populate()
              libnvdimm, pfn, pmem: allocate memmap array in persistent memory
              avr32: convert to asm-generic/memory_model.h
              hugetlb: fix compile error on tile
              frv: fix compiler warning from definition of __pmd()
              um: kill pfn_t
              kvm: rename pfn_t to kvm_pfn_t
              mips: fix PAGE_MASK definition
              mm, dax, pmem: introduce pfn_t
              mm, dax, gpu: convert vm_insert_mixed to pfn_t, introduce _PAGE_DEVMAP
              mm, dax: convert vmf_insert_pfn_pmd() to pfn_t
              list: introduce list_del_poison()
              mm, dax, pmem: introduce {get|put}_dev_pagemap() for dax-gup
              block: notify queue death confirmation
              mm, pmem: devm_memunmap_pages(), truncate and unmap ZONE_DEVICE pages
              mm, x86: get_user_pages() for dax mappings
              block: introduce file_bd_inode()
              block: enable dax for raw block devices

===
for-4.4/dax-coredump
===

        Recently acked by Jeff will appear in -next shortly.
        
        Ross Zwisler (2):
              coredump: add DAX filtering for ELF coredumps
              coredump: add DAX filtering for FDPIC ELF coredumps

===
for-4.4/memremap
https://lwn.net/Articles/653585/
===

        Some patches out of this series have started to leak into
        maintainer trees, but the uptake is fairly slow.  I may just
        send a branch to Linus with the stragglers towards the end of
        the merge window.

        Dan Williams (21):
              x86: introduce arch_memremap()
              arm: introduce arch_memremap()
              ia64: introduce arch_memremap()
              sh: introduce arch_memremap()
              m68k: introduce arch_memremap()
              arm: switch from ioremap_cache to memremap
              x86: switch from ioremap_cache to memremap
              gma500: switch from acpi_os_ioremap to memremap
              i915: switch from acpi_os_ioremap to memremap
              drm/vmwgfx: switch from ioremap_cache to memremap
              acpi: switch from ioremap_cache to memremap
              sound, skylake: switch from ioremap_cache to memremap
              memconsole: fix __iomem mishandling, switch to memremap
              intel-iommu: switch from ioremap_cache to memremap
              pxa2xx-flash: switch from ioremap_cache to memremap
              sfi: switch from ioremap_cache to memremap
              fbdev: switch from ioremap_wt to memremap
              arch: kill ioremap_cached()
              arch: kill ioremap_fullcache()
              arch: remove ioremap_cache, replace with arch_memremap
              arch: remove ioremap_wt, optionally replace with
        arch_memremap

===
for-4.4/blk-integrity:
===
        
        Jens?  I've folded my fixes with Martin's latest and
        block.git/for-4.4/drivers.
        
        Dan Williams (7):
              md, dm, scsi, nvme, libnvdimm: drop blk_integrity_unregister() at shutdown
              md: suspend i/o during runtime blk_integrity_unregister
              nvme: suspend i/o during runtime blk_integrity_unregister
              block: generic request_queue reference counting
              block: move blk_integrity to request_queue
              block: blk_flush_integrity() for bio-based drivers
              block, libnvdimm, nvme: provide a built-in blk_integrity nop profile
        
        Martin K. Petersen (5):
              block: Move integrity kobject to struct gendisk
              block: Consolidate static integrity profile properties
              block: Reduce the size of struct blk_integrity
              block: Export integrity data interval size in sysfs
              block: Inline blk_integrity in struct gendisk
        
===
for-4.4/hotplug
===

        Changes requested for v3, but once those are addressed just need
        an ack from Rafael.

        Vishal Verma (2):
              nfit: in acpi_nfit_init, break on a 0-length table
              acpi: nfit: Add support for hot-add

===
for-4.4/documentation:
===

        In -next...
        
        Konrad Rzeszutek Wilk (1):
              libnvdimm: documentation clarifications
        


^ permalink raw reply	[flat|nested] 24+ messages in thread

* what's in nvdimm.git for v4.4?
@ 2015-10-20 23:31 ` Williams, Dan J
  0 siblings, 0 replies; 24+ messages in thread
From: Williams, Dan J @ 2015-10-20 23:31 UTC (permalink / raw)
  To: axboe, akpm, Wysocki, Rafael J
  Cc: linux-kernel, hch, martin.petersen, linux-nvdimm@lists.01.org,
	linux-fsdevel, linux-acpi, david, jack

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 6611 bytes --]

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:
===

        Core DAX and XFS fixes for DAX locking.  They are carried in
        nvdimm.git as a dependency of the for-4.4/dax-gup branch.
                
        Dan Williams (1):
              pmem, dax: clean up clear_pmem()
        
        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
        
        Ross Zwisler (2):
              dax: dax_pfn_mkwrite() truncate race check
              ext2: Add locking for DAX faults

===
for-4.4/numa:
===

        Minor api cleanups that have been acked and published in -next
        for a few weeks.

        Dan Williams (7):
              x86, mm: quiet arch_add_memory()
              pmem: kill memremap_pmem()
              devm_memunmap: use devres_release()
              devm_memremap: convert to return ERR_PTR
              devm: make allocations numa aware by default
              devm_memremap_pages: use numa_mem_id
              pmem, memremap: convert to numa aware allocations
        
===
for-4.4/dax-gup: get_user_pages() support for dax mappings
https://lists.01.org/pipermail/linux-nvdimm/2015-October/002387.html
===

        Needs acks from core -mm folks particularly for:
                x86, mm: introduce vmem_altmap to augment
                vmemmap_populate()
                mm, x86: get_user_pages() for dax mappings
        
        Dan Williams (22):
              block: generic request_queue reference counting
              dax: increase granularity of dax_clear_blocks() operations
              block, dax: fix lifetime of in-kernel dax mappings with dax_map_atomic()
              mm: introduce __get_dev_pagemap()
              x86, mm: introduce vmem_altmap to augment vmemmap_populate()
              libnvdimm, pfn, pmem: allocate memmap array in persistent memory
              avr32: convert to asm-generic/memory_model.h
              hugetlb: fix compile error on tile
              frv: fix compiler warning from definition of __pmd()
              um: kill pfn_t
              kvm: rename pfn_t to kvm_pfn_t
              mips: fix PAGE_MASK definition
              mm, dax, pmem: introduce pfn_t
              mm, dax, gpu: convert vm_insert_mixed to pfn_t, introduce _PAGE_DEVMAP
              mm, dax: convert vmf_insert_pfn_pmd() to pfn_t
              list: introduce list_del_poison()
              mm, dax, pmem: introduce {get|put}_dev_pagemap() for dax-gup
              block: notify queue death confirmation
              mm, pmem: devm_memunmap_pages(), truncate and unmap ZONE_DEVICE pages
              mm, x86: get_user_pages() for dax mappings
              block: introduce file_bd_inode()
              block: enable dax for raw block devices

===
for-4.4/dax-coredump
===

        Recently acked by Jeff will appear in -next shortly.
        
        Ross Zwisler (2):
              coredump: add DAX filtering for ELF coredumps
              coredump: add DAX filtering for FDPIC ELF coredumps

===
for-4.4/memremap
https://lwn.net/Articles/653585/
===

        Some patches out of this series have started to leak into
        maintainer trees, but the uptake is fairly slow.  I may just
        send a branch to Linus with the stragglers towards the end of
        the merge window.

        Dan Williams (21):
              x86: introduce arch_memremap()
              arm: introduce arch_memremap()
              ia64: introduce arch_memremap()
              sh: introduce arch_memremap()
              m68k: introduce arch_memremap()
              arm: switch from ioremap_cache to memremap
              x86: switch from ioremap_cache to memremap
              gma500: switch from acpi_os_ioremap to memremap
              i915: switch from acpi_os_ioremap to memremap
              drm/vmwgfx: switch from ioremap_cache to memremap
              acpi: switch from ioremap_cache to memremap
              sound, skylake: switch from ioremap_cache to memremap
              memconsole: fix __iomem mishandling, switch to memremap
              intel-iommu: switch from ioremap_cache to memremap
              pxa2xx-flash: switch from ioremap_cache to memremap
              sfi: switch from ioremap_cache to memremap
              fbdev: switch from ioremap_wt to memremap
              arch: kill ioremap_cached()
              arch: kill ioremap_fullcache()
              arch: remove ioremap_cache, replace with arch_memremap
              arch: remove ioremap_wt, optionally replace with
        arch_memremap

===
for-4.4/blk-integrity:
===
        
        Jens?  I've folded my fixes with Martin's latest and
        block.git/for-4.4/drivers.
        
        Dan Williams (7):
              md, dm, scsi, nvme, libnvdimm: drop blk_integrity_unregister() at shutdown
              md: suspend i/o during runtime blk_integrity_unregister
              nvme: suspend i/o during runtime blk_integrity_unregister
              block: generic request_queue reference counting
              block: move blk_integrity to request_queue
              block: blk_flush_integrity() for bio-based drivers
              block, libnvdimm, nvme: provide a built-in blk_integrity nop profile
        
        Martin K. Petersen (5):
              block: Move integrity kobject to struct gendisk
              block: Consolidate static integrity profile properties
              block: Reduce the size of struct blk_integrity
              block: Export integrity data interval size in sysfs
              block: Inline blk_integrity in struct gendisk
        
===
for-4.4/hotplug
===

        Changes requested for v3, but once those are addressed just need
        an ack from Rafael.

        Vishal Verma (2):
              nfit: in acpi_nfit_init, break on a 0-length table
              acpi: nfit: Add support for hot-add

===
for-4.4/documentation:
===

        In -next...
        
        Konrad Rzeszutek Wilk (1):
              libnvdimm: documentation clarifications
        

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
  2015-10-20 23:31 ` Williams, Dan J
@ 2015-10-21  0:01   ` Dave Chinner
  -1 siblings, 0 replies; 24+ messages in thread
From: Dave Chinner @ 2015-10-21  0:01 UTC (permalink / raw)
  To: Williams, Dan J
  Cc: axboe, akpm, Wysocki, Rafael J, linux-kernel, hch,
	martin.petersen, linux-nvdimm, linux-fsdevel, linux-acpi, jack

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.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
@ 2015-10-21  0:01   ` Dave Chinner
  0 siblings, 0 replies; 24+ messages in thread
From: Dave Chinner @ 2015-10-21  0:01 UTC (permalink / raw)
  To: Williams, Dan J
  Cc: axboe, akpm, Wysocki, Rafael J, linux-kernel, hch,
	martin.petersen, linux-nvdimm@lists.01.org, linux-fsdevel,
	linux-acpi, jack

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.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
  2015-10-21  0:01   ` Dave Chinner
@ 2015-10-21  0:31     ` Dan Williams
  -1 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2015-10-21  0:31 UTC (permalink / raw)
  To: Dave Chinner
  Cc: axboe, akpm, Wysocki, Rafael J, linux-kernel, hch,
	martin.petersen, linux-nvdimm, linux-fsdevel, linux-acpi, jack

On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com> 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 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.
This would be via the new facility I posted yesterday:
https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
While not very functional for applications it makes testing base DAX
mechanisms straightforward.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
@ 2015-10-21  0:31     ` Dan Williams
  0 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2015-10-21  0:31 UTC (permalink / raw)
  To: Dave Chinner
  Cc: axboe, akpm, Wysocki, Rafael J, linux-kernel, hch,
	martin.petersen, linux-nvdimm@lists.01.org, linux-fsdevel,
	linux-acpi, jack

On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com> 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 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.
This would be via the new facility I posted yesterday:
https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
While not very functional for applications it makes testing base DAX
mechanisms straightforward.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
  2015-10-21  0:31     ` Dan Williams
@ 2015-10-21  2:38       ` Dave Chinner
  -1 siblings, 0 replies; 24+ messages in thread
From: Dave Chinner @ 2015-10-21  2:38 UTC (permalink / raw)
  To: Dan Williams
  Cc: axboe, akpm, Wysocki, Rafael J, linux-kernel, hch,
	martin.petersen, linux-nvdimm, linux-fsdevel, linux-acpi, jack

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@fromorbit.com> 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@oss.sgi.com, so it's not on my radar...

> 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?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
@ 2015-10-21  2:38       ` Dave Chinner
  0 siblings, 0 replies; 24+ messages in thread
From: Dave Chinner @ 2015-10-21  2:38 UTC (permalink / raw)
  To: Dan Williams
  Cc: axboe, akpm, Wysocki, Rafael J, linux-kernel, hch,
	martin.petersen, linux-nvdimm@lists.01.org, linux-fsdevel,
	linux-acpi, jack

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@fromorbit.com> 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@oss.sgi.com, so it's not on my radar...

> 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?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
  2015-10-21  2:38       ` Dave Chinner
@ 2015-10-21  3:17         ` Dan Williams
  -1 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2015-10-21  3:17 UTC (permalink / raw)
  To: Dave Chinner
  Cc: axboe, akpm, Wysocki, Rafael J, linux-kernel, hch,
	martin.petersen, linux-nvdimm, linux-fsdevel, linux-acpi, jack

On Tue, Oct 20, 2015 at 7:38 PM, Dave Chinner <david@fromorbit.com> 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@fromorbit.com> 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@oss.sgi.com, so it's not on my radar...
>

I can cc xfs@oss.sgi.com 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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
@ 2015-10-21  3:17         ` Dan Williams
  0 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2015-10-21  3:17 UTC (permalink / raw)
  To: Dave Chinner
  Cc: axboe, akpm, Wysocki, Rafael J, linux-kernel, hch,
	martin.petersen, linux-nvdimm@lists.01.org, linux-fsdevel,
	linux-acpi, jack

On Tue, Oct 20, 2015 at 7:38 PM, Dave Chinner <david@fromorbit.com> 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@fromorbit.com> 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@oss.sgi.com, so it's not on my radar...
>

I can cc xfs@oss.sgi.com 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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
  2015-10-21  0:31     ` Dan Williams
@ 2015-10-21  9:08       ` Jan Kara
  -1 siblings, 0 replies; 24+ messages in thread
From: Jan Kara @ 2015-10-21  9:08 UTC (permalink / raw)
  To: Dan Williams
  Cc: Dave Chinner, axboe, akpm, Wysocki, Rafael J, linux-kernel, hch,
	martin.petersen, linux-nvdimm, linux-fsdevel, linux-acpi, jack

Sorry for replying to this email and not to patch posting directly but I
didn't find the original mail in any of my mailboxes...

On Tue 20-10-15 17:31:18, Dan Williams wrote:
> On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com> 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 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.
> This would be via the new facility I posted yesterday:
> https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
> While not very functional for applications it makes testing base DAX
> mechanisms straightforward.

I had a look at the patch and I miss one thing: Why do we need bd_mutex
to protect faults? I see a comment there:

/* check that the faulting page hasn't raced with bdev resize */

Is it really possible that bdev gets shrunk under us? Hum, looking into
fs/block_dev.c, probably it is. But there are other places - like DIO path
- assuming that block device mapping cannot just disappear from under us. I
wonder how that would cope with bdev size change...

Also we only call invalidate_bdev() to invalidate page cache pages of the
bdev after resize which specifically skips any mmaped pages so bdev resizing
in presence of mmap is unreliable to say the least.

Anyway, bd_mutex seems like a big hammer in the fast path to protect against
rare size changes. Also nesting of bd_mutex under mmap_sem makes me
somewhat uneasy (I'd definitely wonder whether lockdep would not complain
about that)...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
@ 2015-10-21  9:08       ` Jan Kara
  0 siblings, 0 replies; 24+ messages in thread
From: Jan Kara @ 2015-10-21  9:08 UTC (permalink / raw)
  To: Dan Williams
  Cc: Dave Chinner, axboe, akpm, Wysocki, Rafael J, linux-kernel, hch,
	martin.petersen, linux-nvdimm@lists.01.org, linux-fsdevel,
	linux-acpi, jack

Sorry for replying to this email and not to patch posting directly but I
didn't find the original mail in any of my mailboxes...

On Tue 20-10-15 17:31:18, Dan Williams wrote:
> On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com> 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 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.
> This would be via the new facility I posted yesterday:
> https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
> While not very functional for applications it makes testing base DAX
> mechanisms straightforward.

I had a look at the patch and I miss one thing: Why do we need bd_mutex
to protect faults? I see a comment there:

/* check that the faulting page hasn't raced with bdev resize */

Is it really possible that bdev gets shrunk under us? Hum, looking into
fs/block_dev.c, probably it is. But there are other places - like DIO path
- assuming that block device mapping cannot just disappear from under us. I
wonder how that would cope with bdev size change...

Also we only call invalidate_bdev() to invalidate page cache pages of the
bdev after resize which specifically skips any mmaped pages so bdev resizing
in presence of mmap is unreliable to say the least.

Anyway, bd_mutex seems like a big hammer in the fast path to protect against
rare size changes. Also nesting of bd_mutex under mmap_sem makes me
somewhat uneasy (I'd definitely wonder whether lockdep would not complain
about that)...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
  2015-10-21  9:08       ` Jan Kara
@ 2015-10-21 16:54         ` Dan Williams
  -1 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2015-10-21 16:54 UTC (permalink / raw)
  To: Jan Kara
  Cc: Dave Chinner, axboe, akpm, Wysocki, Rafael J, linux-kernel, hch,
	martin.petersen, linux-nvdimm, linux-fsdevel, linux-acpi

On Wed, Oct 21, 2015 at 2:08 AM, Jan Kara <jack@suse.cz> wrote:
> Sorry for replying to this email and not to patch posting directly but I
> didn't find the original mail in any of my mailboxes...

Forgive me for not including you on the initial posting.  I'll add you
to that series going forward.

> On Tue 20-10-15 17:31:18, Dan Williams wrote:
>> On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com> 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 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.
>> This would be via the new facility I posted yesterday:
>> https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
>> While not very functional for applications it makes testing base DAX
>> mechanisms straightforward.
>
> I had a look at the patch and I miss one thing: Why do we need bd_mutex
> to protect faults?

This is my main question for the RFC, I landed on bd_mutex as a big
hammer primarily because I don't expect more than a handful of
applications to be in a position to map a block device directly.
Aside from needing admin privileges the application must also be
satisfied with only having partitions to sub-divide the capacity.

As far as I can see, a hypervisor is the only application that is
compatible with the above constraints.  It establishes a few mappings
that exist for the lifetime of the guest and ends up with little to no
contention on an mmap lock.

> I see a comment there:
>
> /* check that the faulting page hasn't raced with bdev resize */
>
> Is it really possible that bdev gets shrunk under us? Hum, looking into
> fs/block_dev.c, probably it is. But there are other places - like DIO path
> - assuming that block device mapping cannot just disappear from under us. I
> wonder how that would cope with bdev size change...
>
> Also we only call invalidate_bdev() to invalidate page cache pages of the
> bdev after resize which specifically skips any mmaped pages so bdev resizing
> in presence of mmap is unreliable to say the least.

True, new locking against resize just for mmap is hard to justify when
there's no protection in other paths.  Perhaps it is a case of
userspace getting to keep the pieces if it decides to race resize vs
i/o?

At least with the pmem driver there's no risk that i/o will clobber
random memory addresses past the end of the whole-disk-device since
only partitions can be resized at run time.  The base pmem device can
only be resized while offline.

> Anyway, bd_mutex seems like a big hammer in the fast path to protect against
> rare size changes. Also nesting of bd_mutex under mmap_sem makes me
> somewhat uneasy (I'd definitely wonder whether lockdep would not complain
> about that)...

Lockdep hasn't triggered to date, but I've only tried mapping the base
block device with no filesystem present.  I'll try a test that sets up
both a base device mapping and one through an fs file on the same
device.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
@ 2015-10-21 16:54         ` Dan Williams
  0 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2015-10-21 16:54 UTC (permalink / raw)
  To: Jan Kara
  Cc: Dave Chinner, axboe, akpm, Wysocki, Rafael J, linux-kernel, hch,
	martin.petersen, linux-nvdimm@lists.01.org, linux-fsdevel,
	linux-acpi

On Wed, Oct 21, 2015 at 2:08 AM, Jan Kara <jack@suse.cz> wrote:
> Sorry for replying to this email and not to patch posting directly but I
> didn't find the original mail in any of my mailboxes...

Forgive me for not including you on the initial posting.  I'll add you
to that series going forward.

> On Tue 20-10-15 17:31:18, Dan Williams wrote:
>> On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com> 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 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.
>> This would be via the new facility I posted yesterday:
>> https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
>> While not very functional for applications it makes testing base DAX
>> mechanisms straightforward.
>
> I had a look at the patch and I miss one thing: Why do we need bd_mutex
> to protect faults?

This is my main question for the RFC, I landed on bd_mutex as a big
hammer primarily because I don't expect more than a handful of
applications to be in a position to map a block device directly.
Aside from needing admin privileges the application must also be
satisfied with only having partitions to sub-divide the capacity.

As far as I can see, a hypervisor is the only application that is
compatible with the above constraints.  It establishes a few mappings
that exist for the lifetime of the guest and ends up with little to no
contention on an mmap lock.

> I see a comment there:
>
> /* check that the faulting page hasn't raced with bdev resize */
>
> Is it really possible that bdev gets shrunk under us? Hum, looking into
> fs/block_dev.c, probably it is. But there are other places - like DIO path
> - assuming that block device mapping cannot just disappear from under us. I
> wonder how that would cope with bdev size change...
>
> Also we only call invalidate_bdev() to invalidate page cache pages of the
> bdev after resize which specifically skips any mmaped pages so bdev resizing
> in presence of mmap is unreliable to say the least.

True, new locking against resize just for mmap is hard to justify when
there's no protection in other paths.  Perhaps it is a case of
userspace getting to keep the pieces if it decides to race resize vs
i/o?

At least with the pmem driver there's no risk that i/o will clobber
random memory addresses past the end of the whole-disk-device since
only partitions can be resized at run time.  The base pmem device can
only be resized while offline.

> Anyway, bd_mutex seems like a big hammer in the fast path to protect against
> rare size changes. Also nesting of bd_mutex under mmap_sem makes me
> somewhat uneasy (I'd definitely wonder whether lockdep would not complain
> about that)...

Lockdep hasn't triggered to date, but I've only tried mapping the base
block device with no filesystem present.  I'll try a test that sets up
both a base device mapping and one through an fs file on the same
device.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
  2015-10-20 23:31 ` Williams, Dan J
@ 2015-10-21 17:47   ` Jens Axboe
  -1 siblings, 0 replies; 24+ messages in thread
From: Jens Axboe @ 2015-10-21 17:47 UTC (permalink / raw)
  To: Williams, Dan J, akpm, Wysocki, Rafael J
  Cc: linux-kernel, hch, martin.petersen, linux-nvdimm, linux-fsdevel,
	linux-acpi, david, jack

On 10/20/2015 05:31 PM, Williams, Dan J wrote:
> ===
> for-4.4/dax-gup: get_user_pages() support for dax mappings
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_pipermail_linux-2Dnvdimm_2015-2DOctober_002387.html&d=CwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=cK1a7KivzZRh1fKQMjSm2A&m=GDROuamLFa0boM8dkPE6fXkQ-bqUhy3M3gH-W-7UaUU&s=S8I_OUhMMB7AAcJn6TzV01M9jB6e2wB3aMIT4lTGHf8&e=
> ===
>
>          Needs acks from core -mm folks particularly for:
>                  x86, mm: introduce vmem_altmap to augment
>                  vmemmap_populate()
>                  mm, x86: get_user_pages() for dax mappings
>
>          Dan Williams (22):
>                block: generic request_queue reference counting
>                dax: increase granularity of dax_clear_blocks() operations
>                block, dax: fix lifetime of in-kernel dax mappings with dax_map_atomic()
>                mm: introduce __get_dev_pagemap()
>                x86, mm: introduce vmem_altmap to augment vmemmap_populate()
>                libnvdimm, pfn, pmem: allocate memmap array in persistent memory
>                avr32: convert to asm-generic/memory_model.h
>                hugetlb: fix compile error on tile
>                frv: fix compiler warning from definition of __pmd()
>                um: kill pfn_t
>                kvm: rename pfn_t to kvm_pfn_t
>                mips: fix PAGE_MASK definition
>                mm, dax, pmem: introduce pfn_t
>                mm, dax, gpu: convert vm_insert_mixed to pfn_t, introduce _PAGE_DEVMAP
>                mm, dax: convert vmf_insert_pfn_pmd() to pfn_t
>                list: introduce list_del_poison()
>                mm, dax, pmem: introduce {get|put}_dev_pagemap() for dax-gup
>                block: notify queue death confirmation
>                mm, pmem: devm_memunmap_pages(), truncate and unmap ZONE_DEVICE pages
>                mm, x86: get_user_pages() for dax mappings
>                block: introduce file_bd_inode()
>                block: enable dax for raw block devices

We really should pull these core block changes in separately.

> ===
> for-4.4/blk-integrity:
> ===
>
>          Jens?  I've folded my fixes with Martin's latest and
>          block.git/for-4.4/drivers.
>
>          Dan Williams (7):
>                md, dm, scsi, nvme, libnvdimm: drop blk_integrity_unregister() at shutdown
>                md: suspend i/o during runtime blk_integrity_unregister
>                nvme: suspend i/o during runtime blk_integrity_unregister
>                block: generic request_queue reference counting
>                block: move blk_integrity to request_queue
>                block: blk_flush_integrity() for bio-based drivers
>                block, libnvdimm, nvme: provide a built-in blk_integrity nop profile
>
>          Martin K. Petersen (5):
>                block: Move integrity kobject to struct gendisk
>                block: Consolidate static integrity profile properties
>                block: Reduce the size of struct blk_integrity
>                block: Export integrity data interval size in sysfs
>                block: Inline blk_integrity in struct gendisk

I'll pull these in.


-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
@ 2015-10-21 17:47   ` Jens Axboe
  0 siblings, 0 replies; 24+ messages in thread
From: Jens Axboe @ 2015-10-21 17:47 UTC (permalink / raw)
  To: Williams, Dan J, akpm, Wysocki, Rafael J
  Cc: linux-kernel, hch, martin.petersen, linux-nvdimm@lists.01.org,
	linux-fsdevel, linux-acpi, david, jack

On 10/20/2015 05:31 PM, Williams, Dan J wrote:
> ===
> for-4.4/dax-gup: get_user_pages() support for dax mappings
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_pipermail_linux-2Dnvdimm_2015-2DOctober_002387.html&d=CwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=cK1a7KivzZRh1fKQMjSm2A&m=GDROuamLFa0boM8dkPE6fXkQ-bqUhy3M3gH-W-7UaUU&s=S8I_OUhMMB7AAcJn6TzV01M9jB6e2wB3aMIT4lTGHf8&e=
> ===
>
>          Needs acks from core -mm folks particularly for:
>                  x86, mm: introduce vmem_altmap to augment
>                  vmemmap_populate()
>                  mm, x86: get_user_pages() for dax mappings
>
>          Dan Williams (22):
>                block: generic request_queue reference counting
>                dax: increase granularity of dax_clear_blocks() operations
>                block, dax: fix lifetime of in-kernel dax mappings with dax_map_atomic()
>                mm: introduce __get_dev_pagemap()
>                x86, mm: introduce vmem_altmap to augment vmemmap_populate()
>                libnvdimm, pfn, pmem: allocate memmap array in persistent memory
>                avr32: convert to asm-generic/memory_model.h
>                hugetlb: fix compile error on tile
>                frv: fix compiler warning from definition of __pmd()
>                um: kill pfn_t
>                kvm: rename pfn_t to kvm_pfn_t
>                mips: fix PAGE_MASK definition
>                mm, dax, pmem: introduce pfn_t
>                mm, dax, gpu: convert vm_insert_mixed to pfn_t, introduce _PAGE_DEVMAP
>                mm, dax: convert vmf_insert_pfn_pmd() to pfn_t
>                list: introduce list_del_poison()
>                mm, dax, pmem: introduce {get|put}_dev_pagemap() for dax-gup
>                block: notify queue death confirmation
>                mm, pmem: devm_memunmap_pages(), truncate and unmap ZONE_DEVICE pages
>                mm, x86: get_user_pages() for dax mappings
>                block: introduce file_bd_inode()
>                block: enable dax for raw block devices

We really should pull these core block changes in separately.

> ===
> for-4.4/blk-integrity:
> ===
>
>          Jens?  I've folded my fixes with Martin's latest and
>          block.git/for-4.4/drivers.
>
>          Dan Williams (7):
>                md, dm, scsi, nvme, libnvdimm: drop blk_integrity_unregister() at shutdown
>                md: suspend i/o during runtime blk_integrity_unregister
>                nvme: suspend i/o during runtime blk_integrity_unregister
>                block: generic request_queue reference counting
>                block: move blk_integrity to request_queue
>                block: blk_flush_integrity() for bio-based drivers
>                block, libnvdimm, nvme: provide a built-in blk_integrity nop profile
>
>          Martin K. Petersen (5):
>                block: Move integrity kobject to struct gendisk
>                block: Consolidate static integrity profile properties
>                block: Reduce the size of struct blk_integrity
>                block: Export integrity data interval size in sysfs
>                block: Inline blk_integrity in struct gendisk

I'll pull these in.


-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
  2015-10-20 23:31 ` Williams, Dan J
@ 2015-10-21 21:58   ` Ross Zwisler
  -1 siblings, 0 replies; 24+ messages in thread
From: Ross Zwisler @ 2015-10-21 21:58 UTC (permalink / raw)
  To: Williams, Dan J
  Cc: axboe, akpm, Wysocki, Rafael J, linux-kernel, hch,
	martin.petersen, linux-nvdimm, linux-fsdevel, linux-acpi, david,
	jack

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:
> ===
<snip>
>         Ross Zwisler (2):
>               dax: dax_pfn_mkwrite() truncate race check

We can drop this patch for dax_pfn_mkwrite() as that whole function is going
away after we merge the locking fixes from XFS, ext2 and ext4.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
@ 2015-10-21 21:58   ` Ross Zwisler
  0 siblings, 0 replies; 24+ messages in thread
From: Ross Zwisler @ 2015-10-21 21:58 UTC (permalink / raw)
  To: Williams, Dan J
  Cc: axboe, akpm, Wysocki, Rafael J, linux-kernel, hch,
	martin.petersen, linux-nvdimm@lists.01.org, linux-fsdevel,
	linux-acpi, david, jack

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:
> ===
<snip>
>         Ross Zwisler (2):
>               dax: dax_pfn_mkwrite() truncate race check

We can drop this patch for dax_pfn_mkwrite() as that whole function is going
away after we merge the locking fixes from XFS, ext2 and ext4.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
  2015-10-21 17:47   ` Jens Axboe
@ 2015-10-21 22:18     ` Dan Williams
  -1 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2015-10-21 22:18 UTC (permalink / raw)
  To: Jens Axboe
  Cc: akpm, Wysocki, Rafael J, linux-kernel, hch, martin.petersen,
	linux-nvdimm, linux-fsdevel, linux-acpi, david, jack

On Wed, Oct 21, 2015 at 10:47 AM, Jens Axboe <axboe@fb.com> wrote:
> On 10/20/2015 05:31 PM, Williams, Dan J wrote:
>>
>> ===
>> for-4.4/dax-gup: get_user_pages() support for dax mappings
[..]
>> ===
[..]
> We really should pull these core block changes in separately.

Sounds good to me.  I'll refactor the block bits into a standalone series.

>> ===
>> for-4.4/blk-integrity:
>> ===
[..]
>
>
> I'll pull these in.
>

Much appreciated!

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
@ 2015-10-21 22:18     ` Dan Williams
  0 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2015-10-21 22:18 UTC (permalink / raw)
  To: Jens Axboe
  Cc: akpm, Wysocki, Rafael J, linux-kernel, hch, martin.petersen,
	linux-nvdimm@lists.01.org, linux-fsdevel, linux-acpi, david,
	jack

On Wed, Oct 21, 2015 at 10:47 AM, Jens Axboe <axboe@fb.com> wrote:
> On 10/20/2015 05:31 PM, Williams, Dan J wrote:
>>
>> ===
>> for-4.4/dax-gup: get_user_pages() support for dax mappings
[..]
>> ===
[..]
> We really should pull these core block changes in separately.

Sounds good to me.  I'll refactor the block bits into a standalone series.

>> ===
>> for-4.4/blk-integrity:
>> ===
[..]
>
>
> I'll pull these in.
>

Much appreciated!

^ permalink raw reply	[flat|nested] 24+ messages in thread

* RE: what's in nvdimm.git for v4.4?
  2015-10-21  9:08       ` Jan Kara
@ 2015-10-21 22:36         ` Elliott, Robert (Persistent Memory)
  -1 siblings, 0 replies; 24+ messages in thread
From: Elliott, Robert (Persistent Memory) @ 2015-10-21 22:36 UTC (permalink / raw)
  To: Jan Kara, Dan Williams
  Cc: martin.petersen, linux-nvdimm, Wysocki, Rafael J, Dave Chinner,
	linux-kernel, axboe, linux-acpi, linux-fsdevel, akpm, hch



> -----Original Message-----
> From: Linux-nvdimm [mailto:linux-nvdimm-bounces@lists.01.org] On Behalf Of
> Jan Kara
> Sent: Wednesday, October 21, 2015 4:08 AM
...
> On Tue 20-10-15 17:31:18, Dan Williams wrote:
> > On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com>
...
> > 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.
> > This would be via the new facility I posted yesterday:
> > https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
> > While not very functional for applications it makes testing base DAX
> > mechanisms straightforward.
> 
> I had a look at the patch and I miss one thing: Why do we need bd_mutex
> to protect faults? I see a comment there:
> 
> /* check that the faulting page hasn't raced with bdev resize */
> 
> Is it really possible that bdev gets shrunk under us? Hum, looking into
> fs/block_dev.c, probably it is. But there are other places - like DIO path
> - assuming that block device mapping cannot just disappear from under us.
> I wonder how that would cope with bdev size change...

DIO_IGNORE_TRUNCATE was added to eliminate an awful lot of CPU
time incrementing and decrementing i_dio_count for direct IO
to block devices, especially at pmem type speeds.  I hope 
that kind of accounting doesn't need to be brought back.

https://lkml.org/lkml/2015/4/3/557
https://lkml.org/lkml/2015/4/15/590

---
Robert Elliott, HPE Persistent Memory


^ permalink raw reply	[flat|nested] 24+ messages in thread

* RE: what's in nvdimm.git for v4.4?
@ 2015-10-21 22:36         ` Elliott, Robert (Persistent Memory)
  0 siblings, 0 replies; 24+ messages in thread
From: Elliott, Robert (Persistent Memory) @ 2015-10-21 22:36 UTC (permalink / raw)
  To: Jan Kara, Dan Williams
  Cc: martin.petersen, linux-nvdimm@lists.01.org, Wysocki, Rafael J,
	Dave Chinner, linux-kernel, axboe, linux-acpi, linux-fsdevel,
	akpm, hch



> -----Original Message-----
> From: Linux-nvdimm [mailto:linux-nvdimm-bounces@lists.01.org] On Behalf Of
> Jan Kara
> Sent: Wednesday, October 21, 2015 4:08 AM
...
> On Tue 20-10-15 17:31:18, Dan Williams wrote:
> > On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com>
...
> > 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.
> > This would be via the new facility I posted yesterday:
> > https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
> > While not very functional for applications it makes testing base DAX
> > mechanisms straightforward.
> 
> I had a look at the patch and I miss one thing: Why do we need bd_mutex
> to protect faults? I see a comment there:
> 
> /* check that the faulting page hasn't raced with bdev resize */
> 
> Is it really possible that bdev gets shrunk under us? Hum, looking into
> fs/block_dev.c, probably it is. But there are other places - like DIO path
> - assuming that block device mapping cannot just disappear from under us.
> I wonder how that would cope with bdev size change...

DIO_IGNORE_TRUNCATE was added to eliminate an awful lot of CPU
time incrementing and decrementing i_dio_count for direct IO
to block devices, especially at pmem type speeds.  I hope 
that kind of accounting doesn't need to be brought back.

https://lkml.org/lkml/2015/4/3/557
https://lkml.org/lkml/2015/4/15/590

---
Robert Elliott, HPE Persistent Memory


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
  2015-10-21 22:36         ` Elliott, Robert (Persistent Memory)
@ 2015-10-21 22:50           ` Dan Williams
  -1 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2015-10-21 22:50 UTC (permalink / raw)
  To: Elliott, Robert (Persistent Memory)
  Cc: Jan Kara, martin.petersen, linux-nvdimm, Wysocki, Rafael J,
	Dave Chinner, linux-kernel, axboe, linux-acpi, linux-fsdevel,
	akpm, hch

On Wed, Oct 21, 2015 at 3:36 PM, Elliott, Robert (Persistent Memory)
<elliott@hpe.com> wrote:
>
>
>> -----Original Message-----
>> From: Linux-nvdimm [mailto:linux-nvdimm-bounces@lists.01.org] On Behalf Of
>> Jan Kara
>> Sent: Wednesday, October 21, 2015 4:08 AM
> ...
>> On Tue 20-10-15 17:31:18, Dan Williams wrote:
>> > On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com>
> ...
>> > 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.
>> > This would be via the new facility I posted yesterday:
>> > https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
>> > While not very functional for applications it makes testing base DAX
>> > mechanisms straightforward.
>>
>> I had a look at the patch and I miss one thing: Why do we need bd_mutex
>> to protect faults? I see a comment there:
>>
>> /* check that the faulting page hasn't raced with bdev resize */
>>
>> Is it really possible that bdev gets shrunk under us? Hum, looking into
>> fs/block_dev.c, probably it is. But there are other places - like DIO path
>> - assuming that block device mapping cannot just disappear from under us.
>> I wonder how that would cope with bdev size change...
>
> DIO_IGNORE_TRUNCATE was added to eliminate an awful lot of CPU
> time incrementing and decrementing i_dio_count for direct IO
> to block devices, especially at pmem type speeds.  I hope
> that kind of accounting doesn't need to be brought back.
>
> https://lkml.org/lkml/2015/4/3/557
> https://lkml.org/lkml/2015/4/15/590

Thanks for that reminder Robert.  I think this backs up my suspicion
that the base mmap_sem protections should be enough for raw block mmap
+ DAX.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: what's in nvdimm.git for v4.4?
@ 2015-10-21 22:50           ` Dan Williams
  0 siblings, 0 replies; 24+ messages in thread
From: Dan Williams @ 2015-10-21 22:50 UTC (permalink / raw)
  To: Elliott, Robert (Persistent Memory)
  Cc: Jan Kara, martin.petersen, linux-nvdimm@lists.01.org, Wysocki,
	Rafael J, Dave Chinner, linux-kernel, axboe, linux-acpi,
	linux-fsdevel, akpm, hch

On Wed, Oct 21, 2015 at 3:36 PM, Elliott, Robert (Persistent Memory)
<elliott@hpe.com> wrote:
>
>
>> -----Original Message-----
>> From: Linux-nvdimm [mailto:linux-nvdimm-bounces@lists.01.org] On Behalf Of
>> Jan Kara
>> Sent: Wednesday, October 21, 2015 4:08 AM
> ...
>> On Tue 20-10-15 17:31:18, Dan Williams wrote:
>> > On Tue, Oct 20, 2015 at 5:01 PM, Dave Chinner <david@fromorbit.com>
> ...
>> > 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.
>> > This would be via the new facility I posted yesterday:
>> > https://lists.01.org/pipermail/linux-nvdimm/2015-October/002512.html.
>> > While not very functional for applications it makes testing base DAX
>> > mechanisms straightforward.
>>
>> I had a look at the patch and I miss one thing: Why do we need bd_mutex
>> to protect faults? I see a comment there:
>>
>> /* check that the faulting page hasn't raced with bdev resize */
>>
>> Is it really possible that bdev gets shrunk under us? Hum, looking into
>> fs/block_dev.c, probably it is. But there are other places - like DIO path
>> - assuming that block device mapping cannot just disappear from under us.
>> I wonder how that would cope with bdev size change...
>
> DIO_IGNORE_TRUNCATE was added to eliminate an awful lot of CPU
> time incrementing and decrementing i_dio_count for direct IO
> to block devices, especially at pmem type speeds.  I hope
> that kind of accounting doesn't need to be brought back.
>
> https://lkml.org/lkml/2015/4/3/557
> https://lkml.org/lkml/2015/4/15/590

Thanks for that reminder Robert.  I think this backs up my suspicion
that the base mmap_sem protections should be enough for raw block mmap
+ DAX.

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2015-10-21 22:50 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-20 23:31 what's in nvdimm.git for v4.4? Williams, Dan J
2015-10-20 23:31 ` Williams, Dan J
2015-10-21  0:01 ` Dave Chinner
2015-10-21  0:01   ` Dave Chinner
2015-10-21  0:31   ` Dan Williams
2015-10-21  0:31     ` Dan Williams
2015-10-21  2:38     ` Dave Chinner
2015-10-21  2:38       ` Dave Chinner
2015-10-21  3:17       ` Dan Williams
2015-10-21  3:17         ` Dan Williams
2015-10-21  9:08     ` Jan Kara
2015-10-21  9:08       ` Jan Kara
2015-10-21 16:54       ` Dan Williams
2015-10-21 16:54         ` Dan Williams
2015-10-21 22:36       ` Elliott, Robert (Persistent Memory)
2015-10-21 22:36         ` Elliott, Robert (Persistent Memory)
2015-10-21 22:50         ` Dan Williams
2015-10-21 22:50           ` Dan Williams
2015-10-21 17:47 ` Jens Axboe
2015-10-21 17:47   ` Jens Axboe
2015-10-21 22:18   ` Dan Williams
2015-10-21 22:18     ` Dan Williams
2015-10-21 21:58 ` Ross Zwisler
2015-10-21 21:58   ` Ross Zwisler

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.