revamp vmem_altmap / dev_pagemap handling V3
by Christoph Hellwig
Hi all,
this series started with two patches from Logan that now are in the
middle of the series to kill the memremap-internal pgmap structure
and to redo the dev_memreamp_pages interface to be better suitable
for future PCI P2P uses. I reviewed them and noticed that there
isn't really any good reason to keep struct vmem_altmap either,
and that a lot of these alternative device page map access should
be better abstracted out instead of being sprinkled all over the
mm code. But when we got the RCU warnings in V1 I went for yet
another approach, and now struct vmem_altmap is kept for now,
but passed explicitly through the memory hotplug code instead of
having to do unprotected lookups through the radix tree. The
end result is that only the get_user_pages path ever looks up
struct dev_pagemap, and struct vmem_altmap is now always embedded
into struct dev_pagemap, and explicitly passed where needed.
Please review carefully, this has only been tested with my legacy
e820 NVDIMM system.
Chances since V2:
- properly pass altmap from dev_devm_memremap_pages through add_pages
(Dan Williams)
- small changelog updates
- a comment type fix
- dropped the patch to just rely on the radix_tree_insert return value
- initialize pgmap->type
4 years, 5 months
Re: [PATCH] nvdimm: Remove minimum size requirement
by Soccer Liu
Hi:
As part of processing in setting up the environment for running unitests, I was able to work through the instrcutions in https://github.com/pmem/ndctl/tree/0a628fdf4fe58a283b16c1bbaa49bb28b1842b... the way until I hit the followingbuild error (Segmentation fault) when buiding libnvdimm.o.
Anyone hit this before?
root@ubuntu:/home/soccerl/nvdimm# make M=tools/testing/nvdimm AR tools/testing/nvdimm/built-in.o CC [M] tools/testing/nvdimm/../../../drivers/nvdimm/core.o CC [M] tools/testing/nvdimm/../../../drivers/nvdimm/bus.o CC [M] tools/testing/nvdimm/../../../drivers/nvdimm/dimm_devs.o CC [M] tools/testing/nvdimm/../../../drivers/nvdimm/dimm.o CC [M] tools/testing/nvdimm/../../../drivers/nvdimm/region_devs.o CC [M] tools/testing/nvdimm/../../../drivers/nvdimm/region.o CC [M] tools/testing/nvdimm/../../../drivers/nvdimm/namespace_devs.o CC [M] tools/testing/nvdimm/../../../drivers/nvdimm/label.o CC [M] tools/testing/nvdimm/../../../drivers/nvdimm/claim.o CC [M] tools/testing/nvdimm/../../../drivers/nvdimm/btt_devs.o CC [M] tools/testing/nvdimm/../../../drivers/nvdimm/pfn_devs.o CC [M] tools/testing/nvdimm/../../../drivers/nvdimm/dax_devs.o CC [M] tools/testing/nvdimm/config_check.o LD [M] tools/testing/nvdimm/libnvdimm.oSegmentation faultscripts/Makefile.build:548: recipe for target 'tools/testing/nvdimm/libnvdimm.o' failedmake[1]: *** [tools/testing/nvdimm/libnvdimm.o] Error 139Makefile:1511: recipe for target '_module_tools/testing/nvdimm' failedmake: *** [_module_tools/testing/nvdimm] Error 2
My devbox has 4.13 Linux in it.I am not sure whether it has anything to do with fact that I didnt do anything with ndctl/ndctl.spec.in (because I am not sure how to apply those dependendies to my testbox)
Any idea?
ThanksCheng-mean
On Thursday, August 31, 2017 3:31 PM, Dan Williams <dan.j.williams(a)intel.com> wrote:
On Mon, Aug 7, 2017 at 11:13 AM, Dan Williams <dan.j.williams(a)intel.com> wrote:
> On Mon, Aug 7, 2017 at 11:09 AM, Cheng-mean Liu (SOCCER)
> <soccerl(a)microsoft.com> wrote:
>> Hi Dan:
>>
>> I am wondering if failing on those unittests is still an issue for this minimum size requirement change.
>
> Yes, I just haven't had a chance to circle back and get this fixed up.
>
> You can reproduce by running:
>
> make TESTS=dpa-alloc check
>
> ...in a checkout of the ndctl project: https://github.com/pmem/ndctl
>
> If you attempt that, note the required setup of the nfit_test modules
> documented in README.md in that same repository.
I have not had any time to fix up the unit test for this. Soccer, can
you take a look?
4 years, 5 months
[PATCH v6 0/2] dax, dm: stop requiring dax for device-mapper
by Dan Williams
Changes since v5 [1]:
* Make DAX_DRIVER select DAX to simplify the Kconfig dependencies
(Michael)
* Rebase on 4.15-rc1 and add new IS_ENABLED(CONFIG_DAX_DRIVER) checks in
drivers/md/dm-log-writes.c.
[1]: https://lists.01.org/pipermail/linux-nvdimm/2017-September/012569.html
---
Hi Mike,
Bart points out that the DAX core is unconditionally enabled if
device-mapper is enabled. Add some config machinery and some
stub/static-inline routines to allow dax infrastructure to be deleted
from device-mapper at compile time.
---
Dan Williams (2):
dax: introduce CONFIG_DAX_DRIVER
dm: allow device-mapper to operate without dax support
arch/powerpc/platforms/Kconfig | 2 -
drivers/dax/Kconfig | 5 ++
drivers/md/Kconfig | 1
drivers/md/dm-linear.c | 6 +++
drivers/md/dm-log-writes.c | 95 +++++++++++++++++++++-------------------
drivers/md/dm-stripe.c | 6 +++
drivers/md/dm.c | 10 +++-
drivers/nvdimm/Kconfig | 2 -
drivers/s390/block/Kconfig | 2 -
include/linux/dax.h | 30 ++++++++++---
10 files changed, 99 insertions(+), 60 deletions(-)
4 years, 5 months
[PATCH 0/2 v2] ext4: Fix ENOSPC handling for DAX faults
by Jan Kara
Hello,
these two patches fix handling of ENOSPC during DAX faults. The problem is
that currently running transaction may be holding lots of already freed
blocks which can be reallocated only once the transaction commits. Standard
retry logic in ext4_iomap_end() does not work for DAX page fault handler
since we hold current transaction open in ext4_dax_huge_fault() and thus
retry logic cannot force the running transaction and as a result application
gets SIGBUS due to premature ENOSPC error.
Changes since v1:
* Made error passed back from dax_iomap_fault() explicitely be only the error
from ->iomap_begin()
Comments are welcome.
Honza
4 years, 5 months
[PATCH v3 0/3] create sysfs representation of ACPI HMAT
by Ross Zwisler
This is the third revision of my patches adding a sysfs representation
of the ACPI Heterogeneous Memory Attribute Table (HMAT). These patches
are based on v4.15-rc3 and a working tree can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/zwisler/linux.git/log/?h=...
My goal is to get these patches merged for v4.16.
Changes from previous version (https://lkml.org/lkml/2017/7/6/749):
- Changed "HMEM" to "HMAT" and "hmem" to "hmat" throughout to make sure
that this effort doesn't get confused with Jerome's HMM work and to
make it clear that this enabling is tightly tied to the ACPI HMAT
table. (John Hubbard)
- Moved the link in the initiator (i.e. mem_init0/mem_tgt2) from
pointing to the "mem_tgt2/local_init" attribute group to instead
point at the mem_tgt2 target itself. (Brice Goglin)
- Simplified the contents of both the initiators and the targets so
that we just symlink to the NUMA node and don't duplicate
information. For initiators this means that we no longer enumerate
CPUs, and for targets this means that we don't provide physical
address start and length information. All of this is already
available in the NUMA node directory itself (i.e.
/sys/devices/system/node/node0), and it already accounts for the fact
that both multiple CPUs and multiple memory regions can be owned by a
given NUMA node. Also removed some extra attributes (is_enabled,
is_isolated) which I don't think are useful at this point in time.
I have tested this against many different configs that I implemented
using qemu.
---
==== Quick Summary ====
Platforms exist today which have multiple types of memory attached to a
single CPU. These disparate memory ranges have some characteristics in
common, such as CPU cache coherence, but they can have wide ranges of
performance both in terms of latency and bandwidth.
For example, consider a system that contains persistent memory, standard
DDR memory and High Bandwidth Memory (HBM), all attached to the same CPU.
There could potentially be an order of magnitude or more difference in
performance between the slowest and fastest memory attached to that CPU.
With the current Linux code NUMA nodes are CPU-centric, so all the memory
attached to a given CPU will be lumped into the same NUMA node. This makes
it very difficult for userspace applications to understand the performance
of different memory ranges on a given CPU.
We solve this issue by providing userspace with performance information on
individual memory ranges. This performance information is exposed via
sysfs:
# grep . mem_tgt2/* mem_tgt2/local_init/* 2>/dev/null
mem_tgt2/firmware_id:1
mem_tgt2/is_cached:0
mem_tgt2/local_init/read_bw_MBps:40960
mem_tgt2/local_init/read_lat_nsec:50
mem_tgt2/local_init/write_bw_MBps:40960
mem_tgt2/local_init/write_lat_nsec:50
This allows applications to easily find the memory that they want to use.
We expect that the existing NUMA APIs will be enhanced to use this new
information so that applications can continue to use them to select their
desired memory.
==== Lots of Details ====
This patch set provides a sysfs representation of parts of the
Heterogeneous Memory Attribute Table (HMAT), newly defined in ACPI 6.2.
One major conceptual change in ACPI 6.2 related to this work is that
proximity domains no longer need to contain a processor. We can now
have memory-only proximity domains, which means that we can now have
memory-only Linux NUMA nodes.
Here is an example configuration where we have a single processor, one
range of regular memory and one range of HBM:
+---------------+ +----------------+
| Processor | | Memory |
| prox domain 0 +---+ prox domain 1 |
| NUMA node 1 | | NUMA node 2 |
+-------+-------+ +----------------+
|
+-------+----------+
| HBM |
| prox domain 2 |
| NUMA node 0 |
+------------------+
This gives us one initiator (the processor) and two targets (the two memory
ranges). Each of these three has its own ACPI proximity domain and
associated Linux NUMA node. Note also that while there is a 1:1 mapping
from each proximity domain to each NUMA node, the numbers don't necessarily
match up. Additionally we can have extra NUMA nodes that don't map back to
ACPI proximity domains.
The above configuration could also have the processor and one of the two
memory ranges sharing a proximity domain and NUMA node, but for the
purposes of the HMAT the two memory ranges will need to be separated.
The overall goal of this series and of the HMAT is to allow users to
identify memory using its performance characteristics. This is
complicated by the amount of HMAT data that could be present in very
large systems, so in this series we only surface performance information
for local (initiator,target) pairings. The changelog for patch 5
discusses this in detail.
Ross Zwisler (3):
acpi: HMAT support in acpi_parse_entries_array()
hmat: add heterogeneous memory sysfs support
hmat: add performance attributes
MAINTAINERS | 6 +
drivers/acpi/Kconfig | 1 +
drivers/acpi/Makefile | 1 +
drivers/acpi/hmat/Kconfig | 7 +
drivers/acpi/hmat/Makefile | 2 +
drivers/acpi/hmat/core.c | 797 ++++++++++++++++++++++++++++++++++++
drivers/acpi/hmat/hmat.h | 64 +++
drivers/acpi/hmat/initiator.c | 43 ++
drivers/acpi/hmat/perf_attributes.c | 56 +++
drivers/acpi/hmat/target.c | 55 +++
drivers/acpi/tables.c | 52 ++-
11 files changed, 1073 insertions(+), 11 deletions(-)
create mode 100644 drivers/acpi/hmat/Kconfig
create mode 100644 drivers/acpi/hmat/Makefile
create mode 100644 drivers/acpi/hmat/core.c
create mode 100644 drivers/acpi/hmat/hmat.h
create mode 100644 drivers/acpi/hmat/initiator.c
create mode 100644 drivers/acpi/hmat/perf_attributes.c
create mode 100644 drivers/acpi/hmat/target.c
--
2.14.3
4 years, 6 months
[GIT PULL] libnvdimm fixes for 4.15-rc5
by Williams, Dan J
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes
...to receive:
* NVDIMM namespaces, configured to enforce 1GB alignment, fail to
initialize on platforms that mis-align the start or end of the physical
address range.
* The Linux implementation of the BTT (Block Translation Table) is
incompatible with the UEFI 2.7 definition of the BTT format. The BTT
layers a software atomic sector semantic on top of an NVDIMM namespace.
Linux needs to be compatible with the UEFI definition to enable boot
support or any pre-OS access of data on a BTT enabled namespace.
* A fix for ACPI SMART notification events, this allows a userspace
monitor to register for health events rather than poll. This has been
broken since it was initially merged as the unit test inadvertently
worked around the problem. The urgency for fixing this during the -rc
series is driven by how expensive it is to poll for this data (System
Management Mode entry).
These fixes are all tagged for -stable and have received a build
success notification from the kbuild robot. Full changelogs below:
---
The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215:
Linux 4.15-rc2 (2017-12-03 11:01:47 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes
for you to fetch changes up to 24e3a7fb60a9187e5df90e5fa655ffc94b9c4f77:
libnvdimm, btt: Fix an incompatibility in the log layout (2017-12-21 14:59:27 -0800)
----------------------------------------------------------------
Dan Williams (3):
acpi, nfit: fix health event notification
libnvdimm, pfn: fix start_pad handling for aligned namespaces
libnvdimm, dax: fix 1GB-aligned namespaces vs physical misalignment
Vishal Verma (2):
libnvdimm, btt: add a couple of missing kernel-doc lines
libnvdimm, btt: Fix an incompatibility in the log layout
drivers/acpi/nfit/core.c | 9 ++-
drivers/nvdimm/btt.c | 201 ++++++++++++++++++++++++++++++++++++++--------
drivers/nvdimm/btt.h | 47 ++++++++++-
drivers/nvdimm/pfn_devs.c | 20 +++--
4 files changed, 236 insertions(+), 41 deletions(-)
commit adf6895754e2503d994a765535fd1813f8834674
Author: Dan Williams <dan.j.williams(a)intel.com>
Date: Thu Nov 30 19:42:52 2017 -0800
acpi, nfit: fix health event notification
Integration testing with a BIOS that generates injected health event
notifications fails to communicate those events to userspace. The nfit
driver neglects to link the ACPI DIMM device with the necessary driver
data so acpi_nvdimm_notify() fails this lookup:
nfit_mem = dev_get_drvdata(dev);
if (nfit_mem && nfit_mem->flags_attr)
sysfs_notify_dirent(nfit_mem->flags_attr);
Add the necessary linkage when installing the notification handler and
clean it up when the nfit driver instance is torn down.
Cc: <stable(a)vger.kernel.org>
Cc: Toshi Kani <toshi.kani(a)hpe.com>
Cc: Vishal Verma <vishal.l.verma(a)intel.com>
Fixes: ba9c8dd3c222 ("acpi, nfit: add dimm device notification support")
Reported-by: Daniel Osawa <daniel.k.osawa(a)intel.com>
Tested-by: Daniel Osawa <daniel.k.osawa(a)intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
commit 19deaa217bc04e83b59b5e8c8229eb0e53ad9efc
Author: Dan Williams <dan.j.williams(a)intel.com>
Date: Tue Dec 19 15:07:10 2017 -0800
libnvdimm, pfn: fix start_pad handling for aligned namespaces
The alignment checks at pfn driver startup fail to properly account for
the 'start_pad' in the case where the namespace is misaligned relative
to its internal alignment. This is typically triggered in 1G aligned
namespace, but could theoretically trigger with small namespace
alignments. When this triggers the kernel reports messages of the form:
dax2.1: bad offset: 0x3c000000 dax disabled align: 0x40000000
Cc: <stable(a)vger.kernel.org>
Fixes: 1ee6667cd8d1 ("libnvdimm, pfn, dax: fix initialization vs autodetect...")
Reported-by: Jane Chu <jane.chu(a)oracle.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
commit 41fce90f26333c4fa82e8e43b9ace86c4e8a0120
Author: Dan Williams <dan.j.williams(a)intel.com>
Date: Mon Dec 4 14:07:43 2017 -0800
libnvdimm, dax: fix 1GB-aligned namespaces vs physical misalignment
The following namespace configuration attempt:
# ndctl create-namespace -e namespace0.0 -m devdax -a 1G -f
libndctl: ndctl_dax_enable: dax0.1: failed to enable
Error: namespace0.0: failed to enable
failed to reconfigure namespace: No such device or address
...fails when the backing memory range is not physically aligned to 1G:
# cat /proc/iomem | grep Persistent
210000000-30fffffff : Persistent Memory (legacy)
In the above example the 4G persistent memory range starts and ends on a
256MB boundary.
We handle this case correctly when needing to handle cases that violate
section alignment (128MB) collisions against "System RAM", and we simply
need to extend that padding/truncation for the 1GB alignment use case.
Cc: <stable(a)vger.kernel.org>
Fixes: 315c562536c4 ("libnvdimm, pfn: add 'align' attribute...")
Reported-and-tested-by: Jane Chu <jane.chu(a)oracle.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
commit 13b7954c0b8dd2d6382b4ddb5053f09e389d5c6e
Author: Vishal Verma <vishal.l.verma(a)intel.com>
Date: Thu Dec 14 17:26:13 2017 -0700
libnvdimm, btt: add a couple of missing kernel-doc lines
Recent updates to btt.h neglected to add corresponding kernel-doc lines
for new structure members. Add them.
Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
commit 24e3a7fb60a9187e5df90e5fa655ffc94b9c4f77
Author: Vishal Verma <vishal.l.verma(a)intel.com>
Date: Mon Dec 18 09:28:39 2017 -0700
libnvdimm, btt: Fix an incompatibility in the log layout
Due to a spec misinterpretation, the Linux implementation of the BTT log
area had different padding scheme from other implementations, such as
UEFI and NVML.
This fixes the padding scheme, and defaults to it for new BTT layouts.
We attempt to detect the padding scheme in use when probing for an
existing BTT. If we detect the older/incompatible scheme, we continue
using it.
Reported-by: Juston Li <juston.li(a)intel.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Fixes: 5212e11fde4d ("nd_btt: atomic sector updates")
Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
4 years, 6 months
Re: linux-nvdimm@lists.01.org Business offer / Бизнес предложение
by Business Group (hduooirl)
We offer e-mail databases at affordable prices. [dukems]
For marketing, advertising, newsletters. [iagskces]
This is the most effective way to attract customers for your business. [xllowpis]
Country: Number of e-mail addresses. [zphmosin]
RU : 7,5 million[dnjcqon]
AU : 3,2 million[ivkgaf]
CA : 3,0 million[bizlz]
DE : 7,7 million[uzvlow]
FR : 2,6 million[wxzboyfw]
NZ : 0,7 million[bycjloae]
UK : 6,0 million[mlplut]
US : 1,6 million[cezazci]
COM 40,9 million[ahlwhcgw]
In addition, we can provide a base for any country in the world. [cyjtb]
Details by e-mail: ivan100050(a)rambler.ru or by ICQ: 666784430 [unjvfwcw]
24.12.2017 0:14:06
Предлагаем e-mail базы по доступным ценам. [gspylbxk]
Для маркетинговых, рекламных, рассылок. [udgati]
Это самый эффективный способ привлечения клиентов для Вашего бизнеса. [vsyllsy]
Страна : Кол-во е-майл адресов. [fxxfsfw]
RU : 7,5 млн.[touhw]
AU : 3,2 млн.[pfwig]
CA : 3,0 млн.[bsrionyh]
DE : 7,7 млн.[neziyvvz]
FR : 2,6 млн.[zxxsp]
NZ : 0,7 млн.[eyjbk]
UK : 6,0 млн.[kaaeqglg]
US : 1,6 млн.[eqsiav]
COM 40,9 млн.[chfddd]
Кроме того мы можем предоставить базу по любой стране МИРА. [ezcivj]
Детали по е-mail: ivan100050(a)rambler.ru или по ICQ: 666784430 [zaqlwef]
24.12.2017 0:14:06
4 years, 6 months
revamp vmem_altmap / dev_pagemap handling V2
by Christoph Hellwig
Hi all,
this series started with two patches from Logan that now are in the
middle of the series to kill the memremap-internal pgmap structure
and to redo the dev_memreamp_pages interface to be better suitable
for future PCI P2P uses. I reviewed them and noticed that there
isn't really any good reason to keep struct vmem_altmap either,
and that a lot of these alternative device page map access should
be better abstracted out instead of being sprinkled all over the
mm code. But when we got the RCU warnings in V1 I went for yet
another approach, and now struct vmem_altmap is kept for now,
but passed explicitly through the memory hotplug code instead of
having to do unprotected lookups through the radix tree. The
end result is that only the get_user_pages path ever looks up
struct dev_pagemap, and struct vmem_altmap is now always embedded
into struct dev_pagemap, and explicitly passed where needed.
Please review carefully, this has only been tested with my legacy
e820 NVDIMM system.
4 years, 6 months
[PATCH 00/15] dax: prep work for fixing dax-dma vs truncate collisions
by Dan Williams
This is hopefully the uncontroversial lead-in set of changes that lay
the groundwork for solving the dax-dma vs truncate problem. The overview
of the changes is:
1/ Disable DAX when we do not have struct page entries backing dax
mappings, or otherwise allow limited DAX support for axonram and
dcssblk. Is anyone actually using the DAX capability of axonram
dcssblk?
2/ Disable code paths that establish potentially long lived DMA
access to a filesystem-dax memory mapping, i.e. RDMA and V4L2. In the
4.16 timeframe the plan is to introduce a "register memory for DMA
with a lease" mechanism for userspace to establish mappings but also
be responsible for tearing down the mapping when the kernel needs to
invalidate the mapping due to truncate or hole-punch.
3/ Add a wakeup mechanism for awaiting for DAX pages to be released
from DMA access.
This overall effort started when Christoph noted during the review of
the MAP_DIRECT proposal:
get_user_pages on DAX doesn't give the same guarantees as on
pagecache or anonymous memory, and that is the problem we need to
fix. In fact I'm pretty sure if we try hard enough (and we might
have to try very hard) we can see the same problem with plain direct
I/O and without any RDMA involved, e.g. do a larger direct I/O write
to memory that is mmap()ed from a DAX file, then truncate the DAX
file and reallocate the blocks, and we might corrupt that new file.
We'll probably need a special setup where there is little other
chance but to reallocate those used blocks.
So what we need to do first is to fix get_user_pages vs unmapping
DAX mmap()ed blocks, be that from a hole punch, truncate, COW
operation, etc.
Included in the changes is a nfit_test mechanism to trivially trigger
this collision by delaying the put_page() that the block layer performs
after performing direct-I/O to a filesystem-DAX page.
Given the ongoing coordination of this set across multiple sub-systems
and the dax core my proposal is to manage this as a branch in the nvdimm
tree with acks from mm, rdma, v4l2, ext4, and xfs.
---
Dan Williams (15):
dax: quiet bdev_dax_supported()
mm, dax: introduce pfn_t_special()
dax: require 'struct page' by default for filesystem dax
brd: remove dax support
dax: stop using VM_MIXEDMAP for dax
dax: stop using VM_HUGEPAGE for dax
dax: stop requiring a live device for dax_flush()
dax: store pfns in the radix
tools/testing/nvdimm: add 'bio_delay' mechanism
IB/core: disable memory registration of fileystem-dax vmas
[media] v4l2: disable filesystem-dax mapping support
mm, dax: enable filesystems to trigger page-idle callbacks
mm, devmap: introduce CONFIG_DEVMAP_MANAGED_PAGES
dax: associate mappings with inodes, and warn if dma collides with truncate
wait_bit: introduce {wait_on,wake_up}_devmap_idle
arch/powerpc/platforms/Kconfig | 1
arch/powerpc/sysdev/axonram.c | 3 -
drivers/block/Kconfig | 12 ---
drivers/block/brd.c | 65 --------------
drivers/dax/device.c | 1
drivers/dax/super.c | 113 +++++++++++++++++++++----
drivers/infiniband/core/umem.c | 49 ++++++++---
drivers/media/v4l2-core/videobuf-dma-sg.c | 39 ++++++++-
drivers/nvdimm/pmem.c | 13 +++
drivers/s390/block/Kconfig | 1
drivers/s390/block/dcssblk.c | 4 +
fs/Kconfig | 8 ++
fs/dax.c | 131 +++++++++++++++++++----------
fs/ext2/file.c | 1
fs/ext2/super.c | 6 +
fs/ext4/file.c | 1
fs/ext4/super.c | 6 +
fs/xfs/xfs_file.c | 2
fs/xfs/xfs_super.c | 20 ++--
include/linux/dax.h | 17 ++--
include/linux/memremap.h | 24 +++++
include/linux/mm.h | 47 ++++++----
include/linux/mm_types.h | 20 +++-
include/linux/pfn_t.h | 13 +++
include/linux/vma.h | 33 +++++++
include/linux/wait_bit.h | 10 ++
kernel/memremap.c | 36 ++++++--
kernel/sched/wait_bit.c | 64 ++++++++++++--
mm/Kconfig | 5 +
mm/hmm.c | 13 ---
mm/huge_memory.c | 8 +-
mm/ksm.c | 3 +
mm/madvise.c | 2
mm/memory.c | 22 ++++-
mm/migrate.c | 3 -
mm/mlock.c | 5 +
mm/mmap.c | 8 +-
mm/swap.c | 3 -
tools/testing/nvdimm/Kbuild | 1
tools/testing/nvdimm/test/iomap.c | 62 ++++++++++++++
tools/testing/nvdimm/test/nfit.c | 34 ++++++++
tools/testing/nvdimm/test/nfit_test.h | 1
42 files changed, 650 insertions(+), 260 deletions(-)
create mode 100644 include/linux/vma.h
4 years, 6 months
[PATCH 1/2] libnvdimm, btt: add a couple of missing kernel-doc lines
by Vishal Verma
Recent updates to btt.h neglected to add corresponding kernel-doc lines
for new structure members. Add them.
Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com>
---
drivers/nvdimm/btt.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/nvdimm/btt.h b/drivers/nvdimm/btt.h
index 578c2057524d..884fbbbdd18a 100644
--- a/drivers/nvdimm/btt.h
+++ b/drivers/nvdimm/btt.h
@@ -125,6 +125,7 @@ struct aligned_lock {
* @list: List head for list of arenas
* @debugfs_dir: Debugfs dentry
* @flags: Arena flags - may signify error states.
+ * @err_lock: Mutex for synchronizing error clearing.
*
* arena_info is a per-arena handle. Once an arena is narrowed down for an
* IO, this struct is passed around for the duration of the IO.
@@ -176,6 +177,7 @@ struct arena_info {
* @init_lock: Mutex used for the BTT initialization
* @init_state: Flag describing the initialization state for the BTT
* @num_arenas: Number of arenas in the BTT instance
+ * @phys_bb: Pointer to the namespace's badblocks structure
*/
struct btt {
struct gendisk *btt_disk;
--
2.14.3
4 years, 6 months
