Category: feature
Bugzilla: NA
CVE: NA
Use reserved memory to create a pmem device to store the
processes information that dumped before kernel update.
When you want to use this feature you need to declare by
"pmemmem=pmem_size:pmem_phystart" in cmdline.
(exp: pmemmem=100M:0x2020)
Signed-
Since owner tarcking is triggerred by pmem device, these functions are
useless. So remove it.
Signed-off-by: Shiyang Ruan
---
fs/dax.c| 112
include/linux/dax.h | 2 -
2 files changed, 114 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
Pmem device could be a target of mapped device. In order to obtain
superblock on the mapped device, we introduce this to translate offset
from target device to md device.
Currently, we implement it on linear target, which is easy to do the
translation. Other targets will be supported in the futu
Obtain the superblock of a pmem disk, and call filesystem's
->corrupted_range() to handle the corrupted data.
Signed-off-by: Shiyang Ruan
---
block/genhd.c | 12
drivers/nvdimm/pmem.c | 24
include/linux/genhd.h | 1 +
3 files changed, 37 insertions
This function is used to handle errors which may cause data lost in
filesystem. Such as memory failure in fsdax mode.
In XFS, it requires "rmapbt" feature in order to query for files or
metadata which associated to the corrupted data. Then we could call fs
recover functions to try to repair the
Call the ->memory_failure() which is implemented by pmem driver, in
order to finally notify filesystem to handle the corrupted data. The
old collecting and killing processes are moved into
mf_dax_mapping_kill_procs(), which will be called by filesystem.
Signed-off-by: Shiyang Ruan
---
drivers/n
With the support of ->rmap(), it is possible to obtain the superblock on
a mapped device.
If a pmem device is used as one target of mapped device, we cannot
obtain its superblock directly. With the help of SYSFS, the mapped
device can be found on the target devices. So, we iterate the
bdev->bd_h
The current memory_failure_dev_pagemap() can only handle single-mapped
dax page for fsdax mode. The dax page could be mapped by multiple files
and offsets if we let reflink feature & fsdax mode work together. So,
we refactor current implementation to support handle memory failure on
each file and
Memory failure occurs in fsdax mode will finally be handled in
filesystem. We introduce this interface to find out files or metadata
affected by the corrupted range, and try to recover the corrupted data
if possiable.
Signed-off-by: Shiyang Ruan
---
include/linux/fs.h | 2 ++
1 file changed, 2
In fsdax mode, the memory failure happens on block device. So, it is
needed to introduce an interface for block devices. Each kind of block
device can handle the memory failure in ther own ways.
Signed-off-by: Shiyang Ruan
---
include/linux/blkdev.h | 2 ++
1 file changed, 2 insertions(+)
dif
This patchset is aimed to support shared pages tracking for fsdax.
Change from RFC v3:
- Do not lock dax entry in memory failure handler
- Add a helper function for corrupted_range
- Add restrictions in xfs code
- Fix code style
- remove the useless association and lock in fsdax
Change
When memory-failure occurs, we call this function which is implemented
by each kind of devices. For the fsdax case, pmem device driver
implements it. Pmem device driver will find out the block device where
the error page locates in, and try to get the filesystem on this block
device. And finally
From: Dan Williams
[ Upstream commit 6268d7da4d192af339f4d688942b9ccb45a65e04 ]
There are multiple locations that open-code the release of the last
range in a device-dax instance. Consolidate this into a new
dev_dax_trim_range() helper.
This also addresses a kmemleak report:
# cat /sys/kernel/
13 matches
Mail list logo
