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
Re: [PATCH 06/12] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()
by Logan Gunthorpe
On 08/01/18 11:09 AM, Jason Gunthorpe wrote:
> It could, if we had a DMA op for p2p then the drivers that provide
> their own ops can implement it appropriately or not at all.
I was thinking of doing something like this. I'll probably rough out a
patch and send it along today or tomorrow.
>> If at all it should be in the dma_map* wrappers, but for that we'd need
>> a good identifier. And it still would not solve the whole fake dma
>> ops issue.
>
> Very long term the IOMMUs under the ops will need to care about this,
> so the wrapper is not an optimal place to put it - but I wouldn't
> object if it gets it out of RDMA :)
Well, creating the extra op doesn't really change anything to the RDMA
patch in this series. The point is, for the time being, we need to track
whether we are doing a P2P or normal mapping using a side channel as we
don't have a good way of tracking it in the SGL at this time.
Adding an extra DMA op is just one way to allow the existing DMA
providers to opt-in/out.
Logan
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
Re: [PATCH 06/12] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()
by Christoph Hellwig
On Thu, Jan 04, 2018 at 09:50:31PM -0700, Jason Gunthorpe wrote:
> Well that argument applies equally to the RDMA RW API wrappers around
> the DMA API. I think it is fine if sgl are defined to only have P2P or
> not, and that debugging support seemed reasonable to me..
>
> > It's also very difficult to add similar functionality to dma_map_page seeing
> > dma_unmap_page won't have any way to know what it's dealing with. It just
> > seems confusing to support P2P in the SG version and not the page version.
>
> Well, this proposal is to support P2P in only some RDMA APIs and not
> others, so it seems about as confusing to me..
As usual we implement what actually has a consumer. On top of that the
R/W API is the only core RDMA API that actually does DMA mapping for the
ULP at the moment. For SENDs and everything else dma maps are done by
the ULP (I'd like to eventually change that, though - e.g. sends through
that are inline to the workqueue don't need a dma map to start with).
> Well, it is more than very nice. We have to keep RDMA working after
> all, and if you make it even more special things become harder for us.
>
> It is already the case that DMA in RDMA is very strange. We have
> drivers that provide their own DMA ops, for instance.
That's because the initial design was to let the ULPs do the DMA
mappings, which fundamentally is wrong. I've fixed it for the R/W
API when adding it, but no one has started work on SENDs and atomics.
> And on that topic, does this scheme work with HFI?
No, and I guess we need an opt-out. HFI generally seems to be
extremely weird.
> This is why P2P must fit in to the common DMA framework somehow, we
> rely on these abstractions to work properly and fully in RDMA.
Moving P2P up to common RDMA code isn't going to fix this. For that
we need to stop preting that something that isn't DMA can abuse the
dma mapping framework, and until then opt them out of behavior that
assumes actual DMA like P2P.
> I think you should consider pushing this directly into the dma_ops
> implementations. Add a p2p_supported flag to struct dma_map_ops, and
> only if it is true can a caller pass a homogeneous SGL to ops->map_sg.
> Only map_sg would be supported for P2P. Upgraded implementations can
> call the helper function.
If at all it should be in the dma_map* wrappers, but for that we'd need
a good identifier. And it still would not solve the whole fake dma
ops issue.
So for now I'd much prefer to let the drivers handle it, and once usage
grows and we know usage patterns better (and I make progress refactoring
both the dma-mapping subsystem itself and the RDMA dma map code to not
be a complete mess) we can move it to the core.
4 years, 5 months
[PATCH 0/2 v3] 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.
Ted, can you please merge these patches through your tree? Ext4 is the part
that is touched by these patches the most.
Changes since v2:
* Added Reviewed-by tags
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 00/11] Copy Offload in NVMe Fabrics with P2P PCI Memory
by Logan Gunthorpe
Hello,
This is a continuation of our work to enable using Peer-to-Peer PCI
memory in NVMe fabrics targets. Many thanks go to Christoph Hellwig who
provided valuable feedback to get these patches to where they are today.
The concept here is to use memory that's exposed on a PCI BAR as
data buffers in the NVME target code such that data can be transferred
from an RDMA NIC to the special memory and then directly to an NVMe
device avoiding system memory entirely. The upside of this is better
QoS for applications running on the CPU utilizing memory and lower
PCI bandwidth required to the CPU (such that systems could be designed
with fewer lanes connected to the CPU). However, presently, the
trade-off is currently a reduction in overall throughput. (Largely due
to hardware issues that would certainly improve in the future).
Due to these trade-offs we've designed the system to only enable using
the PCI memory in cases where the NIC, NVMe devices and memory are all
behind the same PCI switch. This will mean many setups that could likely
work well will not be supported so that we can be more confident it
will work and not place any responsibility on the user to understand
their topology. (We chose to go this route based on feedback we
received at the last LSF). Future work may enable these transfers behind
a fabric of PCI switches or perhaps using a white list of known good
root complexes.
In order to enable this functionality, we introduce a few new PCI
functions such that a driver can register P2P memory with the system.
Struct pages are created for this memory using devm_memremap_pages()
and the PCI bus offset is stored in the corresponding pagemap structure.
Another set of functions allow a client driver to create a list of
client devices that will be used in a given P2P transactions and then
use that list to find any P2P memory that is supported by all the
client devices. This list is then also used to selectively disable the
ACS bits for the downstream ports behind these devices.
In the block layer, we also introduce a P2P request flag to indicate a
given request targets P2P memory as well as a flag for a request queue
to indicate a given queue supports targeting P2P memory. P2P requests
will only be accepted by queues that support it. Also, P2P requests
are marked to not be merged seeing a non-homogenous request would
complicate the DMA mapping requirements.
In the PCI NVMe driver, we modify the existing CMB support to utilize
the new PCI P2P memory infrastructure and also add support for P2P
memory in its request queue. When a P2P request is received it uses the
pci_p2pmem_map_sg() function which applies the necessary transformation
to get the corrent pci_bus_addr_t for the DMA transactions.
In the RDMA core, we also adjust rdma_rw_ctx_init() and
rdma_rw_ctx_destroy() to take a flags argument which indicates whether
to use the PCI P2P mapping functions or not.
Finally, in the NVMe fabrics target port we introduce a new
configuration boolean: 'allow_p2pmem'. When set, the port will attempt
to find P2P memory supported by the RDMA NIC and all namespaces. If
supported memory is found, it will be used in all IO transfers. And if
a port is using P2P memory, adding new namespaces that are not supported
by that memory will fail.
This series is based off of Christoph's v3 series to revamp
dev_pagemap. A git repo of the patches is available here[2].
Logan
Christoph Hellwig (2):
nvme-pci: clean up CMB initialization
nvme-pci: clean up SMBSZ bit definitions
Logan Gunthorpe (10):
pci-p2p: Support peer to peer memory
pci-p2p: Add sysfs group to display p2pmem stats
pci-p2p: Add PCI p2pmem dma mappings to adjust the bus offset
pci-p2p: Clear ACS P2P flags for all client devices
block: Introduce PCI P2P flags for request and request queue
IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()
nvme-pci: Use PCI p2pmem subsystem to manage the CMB
nvme-pci: Add support for P2P memory in requests
nvme-pci: Add a quirk for a pseudo CMB
nvmet: Optionally use PCI P2P memory
Documentation/ABI/testing/sysfs-bus-pci | 25 +
block/blk-core.c | 3 +
drivers/infiniband/core/rw.c | 22 +-
drivers/infiniband/ulp/isert/ib_isert.c | 5 +-
drivers/infiniband/ulp/srpt/ib_srpt.c | 7 +-
drivers/nvme/host/core.c | 4 +
drivers/nvme/host/nvme.h | 8 +
drivers/nvme/host/pci.c | 164 ++++---
drivers/nvme/target/configfs.c | 29 ++
drivers/nvme/target/core.c | 95 +++-
drivers/nvme/target/io-cmd.c | 3 +
drivers/nvme/target/nvmet.h | 10 +
drivers/nvme/target/rdma.c | 41 +-
drivers/pci/Kconfig | 14 +
drivers/pci/Makefile | 1 +
drivers/pci/p2p.c | 781 ++++++++++++++++++++++++++++++++
include/linux/blk_types.h | 18 +-
include/linux/blkdev.h | 2 +
include/linux/memremap.h | 19 +
include/linux/nvme.h | 22 +-
include/linux/pci-p2p.h | 94 ++++
include/linux/pci.h | 6 +
include/rdma/rw.h | 7 +-
net/sunrpc/xprtrdma/svc_rdma_rw.c | 6 +-
24 files changed, 1291 insertions(+), 95 deletions(-)
create mode 100644 drivers/pci/p2p.c
create mode 100644 include/linux/pci-p2p.h
--
2.11.0
4 years, 5 months
Re: [PATCH 06/12] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()
by Logan Gunthorpe
On 04/01/18 03:13 PM, Jason Gunthorpe wrote:
> On Thu, Jan 04, 2018 at 12:52:24PM -0700, Logan Gunthorpe wrote:
>> We tried things like this in an earlier iteration[1] which assumed the SG
>> was homogenous (all P2P or all regular memory). This required serious
>> ugliness to try and ensure SGs were in fact homogenous[2].
>
> I'm confused, these patches already assume the sg is homogenous,
> right? Sure looks that way. So [2] is just debugging??
Yes, but it's a bit different to expect that someone calling
pci_p2pmem_map_sg() will know what they're doing and provide a
homogenous SG. It is relatively clear by convention that the entire SG
must be homogenous given they're calling a pci_p2pmem function. Where
as, allowing P2P SGs into the core DMA code means all we can do is hope
that future developers don't screw it up and allow P2P pages to mix in
with regular pages.
It's also very difficult to add similar functionality to dma_map_page
seeing dma_unmap_page won't have any way to know what it's dealing with.
It just seems confusing to support P2P in the SG version and not the
page version.
> What I meant is to rely on the fact it is already homogenous and
> create a function like this:
>
> static inline bool sg_is_table_p2p(struct scatterlist *sg)
> {
> return is_pci_p2p_page(sg_page(sg));
> }
>
> And then insert
>
> if (sg_is_table_p2p(sg))
> return pci_p2pmem_map_sg(...);
Yes, this is almost identical to the earlier patch I referenced...
> Then we don't need to patch RDMA because RDMA is not special when it
> comes to P2P. P2P should work with everything.
Yes, I agree this would be very nice. But it's challenging at this time
to do it safely. And something like this can still be done in future
work after this patch set gets merged. The changes in this set to the
RDMA and block layers are fairly small and the majority of the block
layer changes would still be required anyway to ensure a given
queue/driver supports P2P requests.
>>> The signature of pci_p2pmem_map_sg also doesn't look very good, it
>>> should mirror the usual dma_map_sg, otherwise it needs more revision
>>> to extend this to do P2P through a root complex.
>>
>> Generally, the feedback that I get is to not make changes that try to
>> anticipate the future. It would be easy enough to add those arguments when
>> the code for going through the RC is made (which I expect will be very
>> involved anyway).
>
> Yes, but DMA mapping fundamentally requires the arguments to
> dma_map_sg, so it is hard to accept an API called dma_map without
> them.. Maybe just a naming issue.
I don't agree that this is a fundamental requirement. But if no one else
objects to adding unused arguments I'd be fine with adding them.
Logan
4 years, 5 months
Re: [PATCH 06/12] IB/core: Add optional PCI P2P flag to rdma_rw_ctx_[init|destroy]()
by Logan Gunthorpe
On 04/01/18 12:22 PM, Jason Gunthorpe wrote:
> This seems really clunky since we are going to want to do this same
> logic all over the place.
>
> I'd be much happier if dma_map_sg can tell the memory is P2P or not
> from the scatterlist or dir arguments and not require the callers to
> have this.
We tried things like this in an earlier iteration[1] which assumed the
SG was homogenous (all P2P or all regular memory). This required serious
ugliness to try and ensure SGs were in fact homogenous[2]. If you don't
assume homogenousness you need change every DMA mapping provider or have
a way to efficiently know if the SGL contains any P2P pages.
Unfortunately, it's hard to do any of this without significant
improvements to the SGL code (like [3]) but I understand there's
significant push back against such changes at this time.
> For instance adding DMA_TO_P2P_DEVICE and DMA_FROM_P2P_DEVICE, or
> adding another bit to the page flags in scatterlist.
Creating new direction flags doesn't really solve the problem you point
out. It'd only really work in the rdma_rw_ctx_init() case because that
function already takes the direction argument. It doesn't work in the
similar block device case because the DMA direction isn't passed through
the request.
Though, if there's agreement to do something like that I'm not against it.
> The signature of pci_p2pmem_map_sg also doesn't look very good, it
> should mirror the usual dma_map_sg, otherwise it needs more revision
> to extend this to do P2P through a root complex.
Generally, the feedback that I get is to not make changes that try to
anticipate the future. It would be easy enough to add those arguments
when the code for going through the RC is made (which I expect will be
very involved anyway).
Logan
[1]
https://github.com/sbates130272/linux-p2pmem/commit/af3d3742669511c343c2c...
[2]
https://github.com/sbates130272/linux-p2pmem/commit/61ec04fa63c79dab14570...
[3]
https://github.com/sbates130272/linux-p2pmem/commit/d8635a4de3c674b577b95...
4 years, 5 months
Business Possibility
by Peter Deng
Hello there, My name is Peter Deng a South African citizen and a friend to Mrs Mugabe sister . I got your contact through Korean business online directory. I represent the interest of Mrs Mugabe who wishes to move a total amount of $19 million into a safe account owns by a trusted business man who is capable of accommodating such volume of funds with absolute trust & confidentiality.
We are willing to give 5-10 percent of the total money for this efforts . A non disclosure non circumvent agreement will be signed before the eventual transfer of funds. It is important for to know that the fund owner is going through a period of political turmoil and she is in a precarious position, so this transaction has to be highly secretive & very confidential.
Kindly respond back to me if this is what you can handle .
Regards,
Peter.
4 years, 5 months
[PATCH 1/2] ext4: test for DAX + journaling corruption
by Ross Zwisler
Add a regression test for the following kernel commit:
ext4: prevent data corruption with journaling + DAX
The test passes if either we successfully compare the data between the mmap
with journaling turned on and the one with journaling turned off, or if we
fail the chattr command to turn on or off journaling. The latter is how we
prevent this issue in the kernel.
Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com>
---
Changes since v1:
- Reordered .gitignore entry. (Eryu)
- Added comments about how "chattr +j" turns off DAX and about why we need
the 'nodelalloc' mount option. (Eryu)
- Added a _require_command for chattr. (Eryu)
- Added $here for src/t_ext4_dax_journal_corruption command. (Eryu)
The previous version of this series is here:
https://lists.01.org/pipermail/linux-nvdimm/2017-September/012463.html
The related kernel patches were merged in v4.15-rc1.
---
.gitignore | 1 +
src/Makefile | 3 +-
src/t_ext4_dax_journal_corruption.c | 102 ++++++++++++++++++++++++++++++++++++
tests/ext4/030 | 74 ++++++++++++++++++++++++++
tests/ext4/030.out | 2 +
tests/ext4/group | 1 +
6 files changed, 182 insertions(+), 1 deletion(-)
create mode 100644 src/t_ext4_dax_journal_corruption.c
create mode 100755 tests/ext4/030
create mode 100644 tests/ext4/030.out
diff --git a/.gitignore b/.gitignore
index f27c30af..840e4fe4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -115,6 +115,7 @@
/src/t_dir_offset2
/src/t_dir_type
/src/t_encrypted_d_revalidate
+/src/t_ext4_dax_journal_corruption
/src/t_futimens
/src/t_getcwd
/src/t_holes
diff --git a/src/Makefile b/src/Makefile
index b1012172..86c5440c 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -13,7 +13,8 @@ TARGETS = dirstress fill fill2 getpagesize holes lstat64 \
multi_open_unlink dmiperf unwritten_sync genhashnames t_holes \
t_mmap_writev t_truncate_cmtime dirhash_collide t_rename_overwrite \
holetest t_truncate_self t_mmap_dio af_unix t_mmap_stale_pmd \
- t_mmap_cow_race t_mmap_fallocate fsync-err t_mmap_write_ro
+ t_mmap_cow_race t_mmap_fallocate fsync-err t_mmap_write_ro \
+ t_ext4_dax_journal_corruption
LINUX_TARGETS = xfsctl bstat t_mtab getdevicesize preallo_rw_pattern_reader \
preallo_rw_pattern_writer ftrunc trunc fs_perms testx looptest \
diff --git a/src/t_ext4_dax_journal_corruption.c b/src/t_ext4_dax_journal_corruption.c
new file mode 100644
index 00000000..18a2acdc
--- /dev/null
+++ b/src/t_ext4_dax_journal_corruption.c
@@ -0,0 +1,102 @@
+#include <errno.h>
+#include <fcntl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/mman.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <time.h>
+#include <unistd.h>
+
+#define PAGE(a) ((a)*0x1000)
+#define STRLEN 256
+
+void err_exit(char *op)
+{
+ fprintf(stderr, "%s: %s\n", op, strerror(errno));
+ exit(1);
+}
+
+void chattr_cmd(char *chattr, char *cmd, char *file)
+{
+ int ret;
+ char command[STRLEN];
+
+ ret = snprintf(command, STRLEN, "%s %s %s 2>/dev/null", chattr, cmd, file);
+ if (ret < 0)
+ err_exit("snprintf");
+
+ ret = system(command);
+ if (ret) /* Success - the kernel fix is to have this chattr fail */
+ exit(77);
+}
+
+int main(int argc, char *argv[])
+{
+ int fd, err, len = PAGE(1);
+ char *data, *dax_data, *chattr, *file;
+ char string[STRLEN];
+
+ if (argc < 3) {
+ printf("Usage: %s <chattr program> <file>\n", basename(argv[0]));
+ exit(0);
+ }
+
+ chattr = argv[1];
+ file = argv[2];
+
+ srand(time(NULL));
+ snprintf(string, STRLEN, "random number %d\n", rand());
+
+ fd = open(file, O_RDWR|O_CREAT, S_IRUSR|S_IWUSR);
+ if (fd < 0)
+ err_exit("fd");
+
+ /* begin with journaling off and DAX on */
+ chattr_cmd(chattr, "-j", file);
+
+ ftruncate(fd, 0);
+ fallocate(fd, 0, 0, len);
+
+ dax_data = mmap(NULL, len, PROT_READ, MAP_SHARED, fd, 0);
+ if (!dax_data)
+ err_exit("mmap dax_data");
+
+ /*
+ * This turns on journaling. It also has the side-effect that it
+ * turns off DAX for the given inode since journaling and DAX aren't
+ * allowed to be on at the same time. This happens in
+ * ext4_change_inode_journal_flag() in kernel v4.14 and before.
+ *
+ * Note that this turns off the runtime DAX flag (S_DAX) in the
+ * in-memory inode, and has nothing to do with per-inode on-media DAX
+ * inode flags.
+ */
+ chattr_cmd(chattr, "+j", file);
+
+ data = mmap(NULL, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
+ if (!data)
+ err_exit("mmap data");
+
+ /*
+ * Write the data using the non-DAX mapping, and try and read it back
+ * using the DAX mapping.
+ */
+ strcpy(data, string);
+ if (strcmp(dax_data, string) != 0)
+ printf("Data miscompare\n");
+
+ err = munmap(data, len);
+ if (err < 0)
+ err_exit("munmap data");
+
+ err = munmap(dax_data, len);
+ if (err < 0)
+ err_exit("munmap dax_data");
+
+ err = close(fd);
+ if (err < 0)
+ err_exit("close");
+ return 0;
+}
diff --git a/tests/ext4/030 b/tests/ext4/030
new file mode 100755
index 00000000..85da7557
--- /dev/null
+++ b/tests/ext4/030
@@ -0,0 +1,74 @@
+#! /bin/bash
+# FS QA Test ext4/030
+#
+# This is a regression test for kernel patch:
+# ext4: prevent data corruption with journaling + DAX
+# created by Ross Zwisler <ross.zwisler(a)linux.intel.com>
+#
+#-----------------------------------------------------------------------
+# Copyright (c) 2017-2018 Intel Corporation. All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#-----------------------------------------------------------------------
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1 # failure is the default!
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+_cleanup()
+{
+ cd /
+ rm -f $tmp.*
+}
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+
+# remove previous $seqres.full before test
+rm -f $seqres.full
+
+# Modify as appropriate.
+_supported_os Linux
+_supported_fs ext4
+_require_scratch_dax
+_require_test_program "t_ext4_dax_journal_corruption"
+_require_command "$CHATTR_PROG" chattr
+
+# real QA test starts here
+_scratch_mkfs > $seqres.full 2>&1
+
+# In order to get our failure condition consistently we need to turn off
+# delayed allocation. With delayed allocation on this simple test will pass,
+# but we would almost certainly see data corruption down the road as the
+# contents of the journal would conflict with the DAX data.
+_scratch_mount "-o dax,nodelalloc" >> $seqres.full 2>&1
+
+$here/src/t_ext4_dax_journal_corruption $CHATTR_PROG $SCRATCH_MNT/testfile
+
+if [[ $? != 0 && $? != 77 ]]; then
+ echo "Test failed, status $?"
+ exit 1
+fi
+
+# success, all done
+echo "Silence is golden"
+status=0
+exit
diff --git a/tests/ext4/030.out b/tests/ext4/030.out
new file mode 100644
index 00000000..06a1c8fe
--- /dev/null
+++ b/tests/ext4/030.out
@@ -0,0 +1,2 @@
+QA output created by 030
+Silence is golden
diff --git a/tests/ext4/group b/tests/ext4/group
index 257bb646..ef768dff 100644
--- a/tests/ext4/group
+++ b/tests/ext4/group
@@ -32,6 +32,7 @@
027 auto quick fsmap
028 auto quick fsmap
029 auto quick fsmap
+030 auto quick
271 auto rw quick
301 aio auto ioctl rw stress defrag
302 aio auto ioctl rw stress defrag
--
2.14.3
4 years, 5 months
