From: Huaisheng Ye
Add intro and usage guide for reinit.
Signed-off-by: Huaisheng Ye
---
Documentation/device-mapper/writecache.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/device-mapper/writecache.txt
b/Documentation/device-mapper/writecache.txt
index 01532b3
From: Huaisheng Ye
This patch set could be used for dm-writecache when use persistent
memory as cache data device.
Patch 1 and 2 go towards removing unused parameter and codes which
actually doesn't really work.
Patch 3 and 4 are targeted at solving problem fn ctr failed to work
due to invalid
From: Huaisheng Ye
When use persistent memory as cache data device, sometimes
the super block of pmem has messy data stored in it. That would
have risk to lead fn ctr failed to work due to invalid magic or
version.
Here we expand pmem_reinit to optional parameters in order to solve
this issue
From: Huaisheng Ye
writecache_flush_region doesn't use size to calculate flush region.
That uses _set_bits to mark the region in dirty_bitmap directly.
Signed-off-by: Huaisheng Ye
---
drivers/md/dm-writecache.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
From: Huaisheng Ye
writecache_flush_region only works when SSD mode.
If wc->pmem_mode sets, writecache_flush_region doesn't need to be called in
writecache_flush_entry.
Signed-off-by: Huaisheng Ye
---
drivers/md/dm-writecache.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers
From: Huaisheng Ye
Add intro and usage guide for reinit.
Signed-off-by: Huaisheng Ye
---
Documentation/device-mapper/writecache.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/device-mapper/writecache.txt
b/Documentation/device-mapper/writecache.txt
index 01532b3
From: Huaisheng Ye
writecache_flush_region only works when SSD mode.
If wc->pmem_mode sets, writecache_flush_region doesn't need to be called in
writecache_flush_entry.
Signed-off-by: Huaisheng Ye
---
drivers/md/dm-writecache.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers
lkml/2018/11/21/281
In the beginning, I haven't considered the situation of mmap write faults.
>From Dan's reply and this email thread, now I have a more clear understanding.
The question is that, even the virtual dm block device has been informed that
the mmap may have write operations through PROT_WR
From: Huaisheng Ye
If use DAX way to mount the origin device of dm_snapshot, when
merging back snapshot to origin, system call table_load during the
construction of snapshot-merge will try to detect new dm_table's type
equals to the existed md's type or not.
The existed type equals
From: Huaisheng Ye
Sometimes dm_swap_table couldn't be used in time.
For example, during the origin construction of
dm-snapshot, the sys_ioctl table_load will try to
detect the lower device origin-real whether support
direct access or not. But origin-real md's struct
dm-table pointer has
From: Huaisheng Ye
Changes
v1->v2:
Add NULL funtions for origin_dax_direct_access and
origin_dax_copy_from/to_iter in order to avoid building
error when CONFIG_DAX_DRIVER has NOT been enabled.
[v1]: https://lkml.org/lkml/2018/11/20/759
This series patches are u
From: Huaisheng Ye
Reconstruct origin_dax_direct_access and expand functions
origin_dax_copy_to/from_iter for DAX operations of dm-snapshot.
Here is the call trace of origin_dax_copy_to_iter,
origin_dax_copy_to_iter will callin dm-linear (-real) for further
dax_operation.
[518597.924019] Call
From: Huaisheng Ye
Reconstruct origin_dax_direct_access and expand functions
origin_dax_copy_to/from_iter for DAX operations of dm-snapshot.
Here is the call trace of origin_dax_copy_to_iter,
origin_dax_copy_to_iter will callin dm-linear (-real) for further
dax_operation.
[518597.924019] Call
From: Huaisheng Ye
If use DAX way to mount the origin device of dm_snapshot, when
merging back snapshot to origin, system call table_load during the
construction of snapshot-merge will try to detect new dm_table's type
equals to the existed md's type or not.
The existed type equals
From: Huaisheng Ye
This series patches are used to realize the dax_operations for dm-snapshot
with persistent memory device.
Here are the steps about how to verify the function.
1. Configure the persistent memory to fs-dax mode and create namespace with
ndctl;
2. find them in /dev;
# ndctl
From: Huaisheng Ye
Some functions within fs/dax don't need to get local pointer kaddr
or variable pfn from direct_access. Using NULL instead of having to
pass in useless pointer or variable that caller then just throw away.
Signed-off-by: Huaisheng Ye
Reviewed-by: Ross Zwisler
---
fs/dax.c
From: Huaisheng Ye
Function persistent_memory_claim doesn't need to get local pointer
dummy_addr from direct_access. Using NULL instead of having to pass
in a useless local pointer that caller then just throw away.
Suggested-by: Ross Zwisler
Signed-off-by: Huaisheng Ye
Reviewed-by: Ross
From: Huaisheng Ye
dcssblk_direct_access() needs to check the validity of pointers kaddr
and pfn for NULL assignment. If anyone equals to NULL, it doesn't need
to calculate the value.
If either of them is equal to NULL, that is to say callers may
have no need for kaddr or pfn, so this patch
From: Huaisheng Ye
The mock / test version of pmem_direct_access() needs to check the
validity of pointers kaddr and pfn for NULL assignment. If anyone
equals to NULL, it doesn't need to calculate the value.
If pointer equals to NULL, that is to say callers may have no need for
kaddr or pfn, so
From: Huaisheng Ye
Function __bdev_dax_supported doesn't need to get local pointer kaddr
from direct_access. Using NULL instead of having to pass in a useless
local pointer that caller then just throw away.
Signed-off-by: Huaisheng Ye
Reviewed-by: Ross Zwisler
---
drivers/dax/super.c | 3
From: Huaisheng Ye
Changes since v2 [2]:
* Collect Martin and Mike's acks for dcssblk and dm-writecache;
* Rebase the series of patch to v4.18-rc7.
Changes since v1 [1]:
* Involve the previous patches for pfn can be NULL.
* Reword the patch descriptions according to Christian's comment
From: Huaisheng Ye
pmem_direct_access() needs to check the validity of pointers kaddr
and pfn for NULL assignment. If anyone equals to NULL, it doesn't need
to calculate the value.
If pointer equals to NULL, that is to say callers may have no need for
kaddr or pfn, so this patch is prepared
From: Huaisheng Ye
Some functions within fs/dax don't need to get local pointer kaddr
or variable pfn from direct_access. Using NULL instead of having to
pass in useless pointer or variable that caller then just throw away.
Signed-off-by: Huaisheng Ye
---
fs/dax.c | 13 -
1 file
From: Huaisheng Ye
Function persistent_memory_claim doesn't need to get local pointer
dummy_addr from direct_access. Using NULL instead of having to pass
in a useless local pointer that caller then just throw away.
Suggested-by: Ross Zwisler
Signed-off-by: Huaisheng Ye
---
drivers/md/dm
From: Huaisheng Ye
Function __bdev_dax_supported doesn't need to get local pointer kaddr
from direct_access. Using NULL instead of having to pass in a useless
local pointer that caller then just throw away.
Signed-off-by: Huaisheng Ye
---
drivers/dax/super.c | 3 +--
1 file changed, 1
From: Huaisheng Ye
The mock / test version of pmem_direct_access() needs to check the
validity of pointers kaddr and pfn for NULL assignment. If anyone
equals to NULL, it doesn't need to calculate the value.
If pointer equals to NULL, that is to say callers may have no need for
kaddr or pfn, so
From: Huaisheng Ye
dcssblk_direct_access() needs to check the validity of pointers kaddr
and pfn for NULL assignment. If anyone equals to NULL, it doesn't need
to calculate the value.
If either of them is equal to NULL, that is to say callers may
have no need for kaddr or pfn, so this patch
From: Huaisheng Ye
pmem_direct_access() needs to check the validity of pointers kaddr
and pfn for NULL assignment. If anyone equals to NULL, it doesn't need
to calculate the value.
If pointer equals to NULL, that is to say callers may have no need for
kaddr or pfn, so this patch is prepared
From: Huaisheng Ye
Changes since v1 [1]:
* Involve the previous patches for pfn can be NULL.
* Reword the patch descriptions according to Christian's comment.
* According to Ross's suggestion, replace local pointer dummy_addr
with NULL within md/dm-writecache for direct_access.
[1]: https
From: Huaisheng Ye
Some functions within driver/dax don't need to get pointer kaddr from
direct_access. In support of allowing memmap initialization to run in
the background elide requests for pointer kaddr when not required.
Signed-off-by: Huaisheng Ye
---
drivers/dax/super.c | 3 +--
1 file
From: Huaisheng Ye
Some functions within fs/dax don't need to get pointer kaddr from
direct_access. In support of allowing memmap initialization to run
in the background elide requests for pointer kaddr when not required.
Signed-off-by: Huaisheng Ye
---
fs/dax.c | 3 +--
1 file changed, 1
From: Huaisheng Ye
Some functions within fs/dax and dax/super don't need to get kaddr from
direct_access. Assigning NULL to kaddr to ->direct_access() is more
straightforward and simple than offering a useless local pointer.
So all direct_access() need to check the validity of second r
From: Huaisheng Ye
dcssblk_direct_access() needs to check the validity of second rank
pointer kaddr for NULL assignment. If kaddr equals to NULL, it
doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye
---
drivers/s390/block/dcssblk.c | 3 ++-
1 file changed, 2 insertions(+), 1
From: Huaisheng Ye
The mock / test version of pmem_direct_access() needs to check the
validity of second rank pointer kaddr for NULL assignment. If kaddr
equals to NULL, it doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye
---
tools/testing/nvdimm/pmem-dax.c | 6 --
1 file
From: Huaisheng Ye
pmem_direct_access() needs to check the validity of second rank
pointer kaddr for NULL assignment. If kaddr equals to NULL, it
doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye
---
drivers/nvdimm/pmem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
On Thu, 05 Jul 2018 00:48:40 +0800 Dan Williams
wrote
> On Wed, Jul 4, 2018 at 9:38 AM, Huaisheng Ye wrote:
> > From: Huaisheng Ye
> >
> > Changes since v1 [1]:
> > * Collect Jan's reviewed-by.
> > * According to Dan's suggestion, up
From: Huaisheng Ye
Some functions within fs/dax don't need to get gfn from direct_access.
Assigning NULL to gfn of dax_direct_access is more intuitive and simple
than offering a useless local variable.
Signed-off-by: Huaisheng Ye
Reviewed-by: Jan Kara
---
fs/dax.c | 9 +++--
1 file
From: Huaisheng Ye
direct_access needs to check the validity of pointer pfn for NULL
assignment. If pfn equals to NULL, it doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye
Reviewed-by: Jan Kara
---
drivers/s390/block/dcssblk.c | 3 ++-
1 file changed, 2 insertions(+), 1
From: Huaisheng Ye
direct_access needs to check the validity of pointer pfn for NULL
assignment. If pfn equals to NULL, it doesn't need to calculate the value.
Suggested-by: Dan Williams
Signed-off-by: Huaisheng Ye
Reviewed-by: Jan Kara
---
tools/testing/nvdimm/pmem-dax.c | 6 --
1 file
From: Huaisheng Ye
Changes since v1 [1]:
* Collect Jan's reviewed-by.
* According to Dan's suggestion, update the unit test infrastructure
tools/testing/nvdimm/pmem-dax.c for checking the validity of gfn.
[1]: https://lkml.org/lkml/2018/7/4/81
---
Some functions within fs/dax don't need
From: Huaisheng Ye
direct_access needs to check the validity of pointer pfn for NULL
assignment. If pfn equals to NULL, it doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye
Reviewed-by: Jan Kara
---
drivers/nvdimm/pmem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
On Wed, 04 Jul 2018 19:30:12 +0800 Jan Kara wrote
> On Wed 04-07-18 14:40:58, Huaisheng Ye wrote:
> > From: Huaisheng Ye
> >
> > Some functions within fs/dax don't need to get gfn from direct_access.
> > Assigning NULL to gfn of dax_dire
From: Huaisheng Ye
Some functions within fs/dax don't need to get gfn from direct_access.
Assigning NULL to gfn of dax_direct_access is more intuitive and simple
than offering a useless local variable.
Signed-off-by: Huaisheng Ye
---
fs/dax.c | 9 +++--
1 file changed, 3 insertions(+), 6
From: Huaisheng Ye
Some functions within fs/dax don't need to get gfn from direct_access.
Assigning NULL to gfn of dax_direct_access is more intuitive and simple
than offering a useless local variable.
So direct_access needs to check validity of the pointer pfn For NULL
assignment.
Signed-off
From: Huaisheng Ye
Some functions within fs/dax don't need to get gfn from direct_access.
Assigning NULL to gfn of dax_direct_access is more intuitive and simple
than offering a useless local variable.
So direct_access needs to check validity of the pointer pfn For NULL
assignment. If pfn
On Mon, 02 Jul 2018 03:26:00 +0800 Al Viro
wrote
> On Sun, Jul 01, 2018 at 02:18:47PM +0800, Huaisheng Ye wrote:
> > From: Huaisheng Ye
> >
> > The type of offset within struct iomap is loff_t, which represents
> > file offset of mapping.
>
From: Huaisheng Ye
The type of offset within struct iomap is loff_t, which represents
file offset of mapping.
In ext2_iomap_begin, iomap->offset shall be given a type cast as
loff_t instead of u64.
Signed-off-by: Huaisheng Ye
---
fs/ext2/inode.c | 2 +-
1 file changed, 1 insertion(+)
From: Huaisheng Ye
If ext2_get_blocks returns negative result, ext2_iomap_begin
will return for error case.
Adjust the judging condition of ret value will be useful for
code simplification.
Signed-off-by: Huaisheng Ye
---
fs/ext2/inode.c | 10 +-
1 file changed, 5 insertions(+), 5
From: Huaisheng Ye
There is no annotation for member ops within struct dax_device.
Add it.
Signed-off-by: Huaisheng Ye
---
drivers/dax/super.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index 2b2332b..aa6382a 100644
--- a/drivers/dax/super.c
49 matches
Mail list logo
