[PATCH 0/3] Hotplug support for libnvdimm
by Vishal Verma
This series adds support for hotplug of NVDIMMs. Upon hotplug, the ACPI
core calls the .notify callback we register. From this, we evaluate the
_FIT method which returns an updated NFIT. This is scanned for any new
tables, and any new regions found from it are registered and made
available for use.
The series is tested with nfit_test (tools/testing/nvdimm) only, which
means the parts of getting a notification from the acpi core, and calling
_FIT are untested.
Dan/Rafael, I have a couple of 'TODO' comments in patch 3, where I wasn't
sure of what we should do - if you have any suggestions, let me know.
Vishal Verma (3):
nfit: in acpi_nfit_init, break on a 0-length table
acpi: add a utility function for evaluating _FIT
acpi: nfit: Add support for hotplug
drivers/acpi/nfit.c | 139 +++++++++++++++++++++++++++++++++----
drivers/acpi/nfit.h | 2 +
drivers/acpi/utils.c | 23 +++++++
include/acpi/acpi_bus.h | 1 +
tools/testing/nvdimm/test/nfit.c | 144 ++++++++++++++++++++++++++++++++++++++-
5 files changed, 294 insertions(+), 15 deletions(-)
--
2.4.3
5 years, 3 months
Re: [PATCH v2 01/20] block: generic request_queue reference counting
by Dan Williams
On Sun, Oct 11, 2015 at 5:59 AM, Christoph Hellwig <hch(a)lst.de> wrote:
> Looks good,
>
> Reviewed-by: Christoph Hellwig <hch(a)lst.de>
>
> We could still clean up draing or only release the reference on
> bio_done, but let's do that separately and get this infrastructure in
> ASAP.
Thanks Christoph.
Jens, do you want to take this, or ok for me to take this through nvdimm.git?
5 years, 3 months
Re: [PATCH 2/2] ext2: Add locking for DAX faults
by Ross Zwisler
On Mon, Oct 12, 2015 at 10:14:43AM +1100, Dave Chinner wrote:
> [Nit: please send all patches of the series to the same list of
> recipients. Otherwise people with list based filters end up with the
> series spread across different mailboxes and people not subscribed
> to all lists don't get the full series and so are lacking in context
> for proper review. ]
Okay, will do.
> On Fri, Oct 09, 2015 at 04:02:08PM -0600, Ross Zwisler wrote:
<>
> > +/*
> > + * The lock ordering for ext2 DAX fault paths is:
> > + *
> > + * mmap_sem (MM)
> > + * ext2_inode_info->dax_sem
> > + * sb_start_pagefault (vfs, freeze - taken in DAX)
> > + * address_space->i_mmap_rwsem or page_lock (mutually exclusive in DAX)
> > + * ext2_inode_info->truncate_mutex
>
> This is a different lock order to XFS - it puts the i_mmaplock
> inside sb_start_pagefault(), not outside it. This ordering means the
> timestamp updates during the page fault are also under
> ext2_inode_info->dax_sem...
Yep - I was trying not not open code dax_fault() yet again, but it looks like
both XFS and ext4 both open-code dax_fault() and call __dax_fault() directly.
I assume that when we get an analogous lock to i_mmaplock in the ext4 fault
path we'll end up with the same locking order that is found in XFS.
I'll do the same for v2 of this patch and I'll kill the then-unused
dax_fault().
5 years, 3 months
[PATCH v5] Fix DAX deadlocks for v4.3
by Ross Zwisler
This was previously "Revert locking changes in DAX for v4.3".
Undo some recent changes to the locking scheme in DAX introduced by these two
commits:
commit 843172978bb9 ("dax: fix race between simultaneous faults")
commit 46c043ede471 ("mm: take i_mmap_lock in unmap_mapping_range() for DAX")
Changes from v4:
- Collapsed two revert commits into a single fix commit. No code changes were
made.
Ross Zwisler (1):
mm, dax: fix DAX deadlocks
fs/dax.c | 70 +++++++++++++++++++++++++------------------------------------
mm/memory.c | 2 ++
2 files changed, 31 insertions(+), 41 deletions(-)
--
2.1.0
5 years, 3 months
Re: [PATCH v2 11/20] kvm: rename pfn_t to kvm_pfn_t
by Dan Williams
On Mon, Oct 12, 2015 at 5:51 AM, Paolo Bonzini <pbonzini(a)redhat.com> wrote:
>
>
> On 10/10/2015 22:57, Dan Williams wrote:
>> On Sat, Oct 10, 2015 at 1:35 PM, Paolo Bonzini <pbonzini(a)redhat.com> wrote:
>>> On 10/10/2015 02:56, Dan Williams wrote:
>>>> The core has developed a need for a "pfn_t" type [1]. Move the existing
>>>> pfn_t in KVM to kvm_pfn_t [2].
>>>>
>>>> [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-September/002199.html
>>>> [2]: https://lists.01.org/pipermail/linux-nvdimm/2015-September/002218.html
>>>
>>> Can you please change also the other types in include/linux/kvm_types.h?
>>
>> Hmm, all those seem kvm specific already. I'd only prefix them with
>> kvm_ if they collided with a "core" type.
>
> But they are all related and the code becomes uglier if you only prefix
> one of them. If you don't convert all of them, I will do it anyway as
> soon as this patch get in.
Ok.
> Since it touches a lot of KVM files, we should synchronize in order to
> avoid conflicts and gnashing of teeth. What tree is this patch going
> in? You could provide me a commit SHA1 for this patch (well, its
> definitive version) based on Linus's tree (so that I can merge it in my
> tree as well), or I could commit it and provide the SHA1 to the
> maintainer of said tree.
The kvm_pfn_t conversion is only needed if the new pfn_t
infrastructure moves forward, and at this point it still needs some
review feedback.
How about this, care to send conversion patches for the rest? ...based on:
https://git.kernel.org/cgit/linux/kernel/git/djbw/nvdimm.git/log/?h=libnv...
When/if the new pfn_t bits move forward I'll carry them in the same
pull request through the nvdimm.git tree.
5 years, 3 months
[PATCH 0/2] Add updated DAX locking to ext2
by Ross Zwisler
The first patch in this series is a somewhat related bug fix. The second patch
adds new locking to ext2 to isolate DAX faults (page faults, PMD faults, page
mkwrite and pfn mkwrite) from ext2 operations that modify a given inode's data
block allocations.
In my first attempt at this fix I attempted to expand the protection offered by
ext2_inode_info->truncate_mutex so that we took truncate_mutex before our DAX
fault paths were entered. The DAX fault handlers would then call a version of
ext2_get_block() that assumed truncate_mutex was already held.
This *almost* works, but it turns out that it introduces a lock ordering
inversion between truncate_mutex and a given page's page_lock. With my series
as it is, the lock ordering looks like this:
mmap_sem (MM)
ext2_inode_info->dax_sem
sb_start_pagefault (vfs, freeze - taken in DAX)
address_space->i_mmap_rwsem or page_lock (mutually exclusive in DAX)
ext2_inode_info->truncate_mutex
With truncate_mutex being taken before the page fault handler, as in my initial
attempt, our lock ordering is instead:
mmap_sem (MM)
ext2_inode_info->truncate_mutex
sb_start_pagefault (vfs, freeze - taken in DAX)
address_space->i_mmap_rwsem or page_lock (mutually exclusive in DAX)
This is fine for DAX, but it turns out that you can't actually take
truncate_mutex before a page_lock because some operations call ext2_get_block()
while already holding page_lock from calls higher in the stack. This means
that whatever locks are taken in ext2_get_block() must be below page_lock in
the locking order, else you can deadlock. To solve this I had to introduce a
new lock that would sit above page_lock in the locking order. This is the new
"dax_sem" semaphore.
Folks with ext2 experience, have I missed any other cases that need to be
protected by dax_sem? I took a hard look at all the cases in XFS that are
protected by i_mmaplock and convinced myself that truncate was the only one of
them present in ext2.
I've tested this series using xfstests with DAX both enabled and disabled.
Lockdep was on and working, and didn't have any complaints.
Ross Zwisler (2):
dax: dax_pfn_mkwrite() truncate race check
ext2: Add locking for DAX faults
fs/dax.c | 13 +++++++++++--
fs/ext2/ext2.h | 1 +
fs/ext2/file.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++----
fs/ext2/inode.c | 9 +++++++++
fs/ext2/super.c | 1 +
5 files changed, 69 insertions(+), 6 deletions(-)
--
2.1.0
5 years, 3 months
[PATCH 00/15] get_user_pages() for dax mappings
by Dan Williams
To date, we have implemented two I/O usage models for persistent memory,
PMEM (a persistent "ram disk") and DAX (mmap persistent memory into
userspace). This series adds a third, DAX-GUP, that allows DAX mappings
to be the target of direct-i/o. It allows userspace to coordinate
DMA/RDMA from/to persitent memory.
The implementation leverages the ZONE_DEVICE mm-zone that went into
4.3-rc1 to flag pages that are owned and dynamically mapped by a device
driver. The pmem driver, after mapping a persistent memory range into
the system memmap via devm_memremap_pages(), arranges for DAX to
distinguish pfn-only versus page-backed pmem-pfns via flags in the new
__pfn_t type. The DAX code, upon seeing a PFN_DEV+PFN_MAP flagged pfn,
flags the resulting pte(s) inserted into the process page tables with a
new _PAGE_DEVMAP flag. Later, when get_user_pages() is walking ptes it
keys off _PAGE_DEVMAP to pin the device hosting the page range active.
Finally, get_page() and put_page() are modified to take references
against the device driver established page mapping.
Next step, more testing specifically DAX-get_user_pages() vs truncate.
Patches 1 - 3 are general compilation fixups from 0day-kbuild reports
while developing this series.
Patches 4 - 7 are minor cleanups and reworks of the devm_memremap_* api.
Patches 8 - 10 add a reference counter for pinning the pmem driver
active while it is in use. It turns out, prior to these changes, you
can reliably crash the kernel on shutdown if the pmem device is unbound
while hosting a mounted filesystem.
Patches 11 - 15 use __pfn_t and the _PAGE_DEVMAP flag to implement the
dax-gup path.
This series is built on 4.3-rc2 plus the __dax_pmd_fault fix from Ross:
https://patchwork.kernel.org/patch/7244961/
---
Dan Williams (15):
avr32: convert to asm-generic/memory_model.h
hugetlb: fix compile error on tile
frv: fix compiler warning from definition of __pmd()
x86, mm: quiet arch_add_memory()
pmem: kill memremap_pmem()
devm_memunmap: use devres_release()
devm_memremap: convert to return ERR_PTR
block, dax, pmem: reference counting infrastructure
block, pmem: fix null pointer de-reference on shutdown, check for queue death
block, dax: fix lifetime of in-kernel dax mappings
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
mm, dax, pmem: introduce {get|put}_dev_pagemap() for dax-gup
mm, x86: get_user_pages() for dax mappings
arch/alpha/include/asm/pgtable.h | 1
arch/avr32/include/asm/page.h | 8 +
arch/frv/include/asm/page.h | 2
arch/ia64/include/asm/pgtable.h | 1
arch/m68k/include/asm/page_no.h | 1
arch/parisc/include/asm/pgtable.h | 1
arch/powerpc/include/asm/pgtable.h | 1
arch/powerpc/sysdev/axonram.c | 10 +
arch/sparc/include/asm/pgtable_64.h | 2
arch/tile/include/asm/pgtable.h | 1
arch/um/include/asm/pgtable-3level.h | 1
arch/x86/include/asm/pgtable.h | 24 ++++
arch/x86/include/asm/pgtable_types.h | 7 +
arch/x86/mm/gup.c | 56 ++++++++
arch/x86/mm/init.c | 4 -
arch/x86/mm/init_64.c | 4 -
arch/x86/mm/pat.c | 4 -
block/blk-core.c | 86 ++++++++++++-
block/blk-mq-sysfs.c | 2
block/blk-mq.c | 48 ++-----
block/blk-sysfs.c | 9 +
block/blk.h | 3
drivers/block/brd.c | 6 -
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3
drivers/gpu/drm/gma500/framebuffer.c | 2
drivers/gpu/drm/msm/msm_gem.c | 3
drivers/gpu/drm/omapdrm/omap_gem.c | 6 +
drivers/gpu/drm/ttm/ttm_bo_vm.c | 3
drivers/nvdimm/pmem.c | 57 +++++---
drivers/s390/block/dcssblk.c | 12 +-
fs/block_dev.c | 2
fs/dax.c | 140 +++++++++++++-------
include/asm-generic/pgtable.h | 6 +
include/linux/blkdev.h | 24 +++-
include/linux/huge_mm.h | 2
include/linux/hugetlb.h | 1
include/linux/io.h | 17 --
include/linux/mm.h | 212 +++++++++++++++++++++++++++++--
include/linux/mm_types.h | 6 +
include/linux/pfn.h | 9 +
include/linux/pmem.h | 26 ----
kernel/memremap.c | 78 +++++++++++
mm/gup.c | 11 +-
mm/huge_memory.c | 10 +
mm/hugetlb.c | 18 ++-
mm/memory.c | 17 +-
mm/swap.c | 15 ++
47 files changed, 729 insertions(+), 233 deletions(-)
5 years, 3 months
Increase visibility with Profile Backlinks
by cheap.profile.backlinks＠gmail.com
Boost Your Rankings With Our One Way Link Building Services.
We create a profile for you on thousands of different forums
and add a link to your website on each of the profiles.
Profile backlinks are permanent and are never removed.
We offer different packages at different prices
Example: 10000 Backlinks = 14.99 usd
http://www.seo-wise.net/detail.php?id=102
Unsubscribe option is available on the footer of our website
5 years, 3 months
