[GIT PULL] libnvdimm fixes for v4.6-rc4
by Ross Zwisler
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes
to receive 2 fixes.
1) Fix memcpy_from_pmem() to fallback to memcpy() for architectures where
CONFIG_ARCH_HAS_PMEM_API=n.
2) Add a comment explaining why we write data twice when clearing poison in
pmem_do_bvec().
This has passed a boot test on an X86_32 config. This was the architecture
where issue #1 above was first noticed.
----------------------------------------------------------------
Dan Williams (1):
libnvdimm, pmem: clarify the write+clear_poison+write flow
Toshi Kani (1):
pmem: fix BUG() error in pmem.h:48 on X86_32
drivers/nvdimm/pmem.c | 14 ++++++++++++++
include/linux/pmem.h | 22 ++++++++++++++++------
2 files changed, 30 insertions(+), 6 deletions(-)
commit 0a370d261c805286cbdfa1f96661322a28cce860
Author: Dan Williams <dan.j.williams(a)intel.com>
Date: Thu Apr 14 19:40:47 2016 -0700
libnvdimm, pmem: clarify the write+clear_poison+write flow
The ACPI specification does not specify the state of data after a clear
poison operation. Potential future libnvdimm bus implementations for
other architectures also might not specify or disagree on the state of
data after clear poison. Clarify why we write twice.
Reported-by: Jeff Moyer <jmoyer(a)redhat.com>
Reported-by: Vishal Verma <vishal.l.verma(a)intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Reviewed-by: Johannes Thumshirn <jthumshirn(a)suse.de>
Reviewed-by: Jeff Moyer <jmoyer(a)redhat.com>
Reviewed-by: Vishal Verma <vishal.l.verma(a)intel.com>
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 8e09c54..f798899 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -103,6 +103,20 @@ static int pmem_do_bvec(struct pmem_device *pmem, struct page *page,
flush_dcache_page(page);
}
} else {
+ /*
+ * Note that we write the data both before and after
+ * clearing poison. The write before clear poison
+ * handles situations where the latest written data is
+ * preserved and the clear poison operation simply marks
+ * the address range as valid without changing the data.
+ * In this case application software can assume that an
+ * interrupted write will either return the new good
+ * data or an error.
+ *
+ * However, if pmem_clear_poison() leaves the data in an
+ * indeterminate state we need to perform the write
+ * after clear poison.
+ */
flush_dcache_page(page);
memcpy_to_pmem(pmem_addr, mem + off, len);
if (unlikely(bad_pmem)) {
commit cba2e47abcbd80e3f46f460899290402f98090ec
Author: Toshi Kani <toshi.kani(a)hpe.com>
Date: Tue Apr 12 18:10:52 2016 -0600
pmem: fix BUG() error in pmem.h:48 on X86_32
After 'commit fc0c2028135c ("x86, pmem: use memcpy_mcsafe()
for memcpy_from_pmem()")', probing a PMEM device hits the BUG()
error below on X86_32 kernel.
kernel BUG at include/linux/pmem.h:48!
memcpy_from_pmem() calls arch_memcpy_from_pmem(), which is
unimplemented since CONFIG_ARCH_HAS_PMEM_API is undefined on
X86_32.
Fix the BUG() error by adding default_memcpy_from_pmem().
Acked-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com>
Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: Ross Zwisler <ross.zwisler(a)linux.intel.com>
diff --git a/include/linux/pmem.h b/include/linux/pmem.h
index ac6d872..57d146f 100644
--- a/include/linux/pmem.h
+++ b/include/linux/pmem.h
@@ -72,6 +72,18 @@ static inline void arch_invalidate_pmem(void __pmem *addr, size_t size)
}
#endif
+static inline bool arch_has_pmem_api(void)
+{
+ return IS_ENABLED(CONFIG_ARCH_HAS_PMEM_API);
+}
+
+static inline int default_memcpy_from_pmem(void *dst, void __pmem const *src,
+ size_t size)
+{
+ memcpy(dst, (void __force *) src, size);
+ return 0;
+}
+
/*
* memcpy_from_pmem - read from persistent memory with error handling
* @dst: destination buffer
@@ -83,12 +95,10 @@ static inline void arch_invalidate_pmem(void __pmem *addr, size_t size)
static inline int memcpy_from_pmem(void *dst, void __pmem const *src,
size_t size)
{
- return arch_memcpy_from_pmem(dst, src, size);
-}
-
-static inline bool arch_has_pmem_api(void)
-{
- return IS_ENABLED(CONFIG_ARCH_HAS_PMEM_API);
+ if (arch_has_pmem_api())
+ return arch_memcpy_from_pmem(dst, src, size);
+ else
+ return default_memcpy_from_pmem(dst, src, size);
}
/**
4 years, 7 months
[PATCH] dax: integrate *sync code & multi-order radix tree
by Ross Zwisler
With the new addition of the multi-order radix tree support we can simplify
the DAX *sync PMD support a bit. Instead of manually checking to see if
our index is covered by a PMD entry we can rely on the new radix tree to
return the PMD entry if present.
Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com>
---
fs/dax.c | 31 +++++++++++--------------------
1 file changed, 11 insertions(+), 20 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 735a608..3f87fcc 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -40,6 +40,7 @@
#define RADIX_DAX_SECTOR(entry) (((unsigned long)entry >> RADIX_DAX_SHIFT))
#define RADIX_DAX_ENTRY(sector, pmd) ((void *)((unsigned long)sector << \
RADIX_DAX_SHIFT | (pmd ? RADIX_DAX_PMD : RADIX_DAX_PTE)))
+#define RADIX_DAX_ORDER(pmd) (pmd ? PMD_SHIFT - PAGE_SHIFT : 0)
static long dax_map_atomic(struct block_device *bdev, struct blk_dax_ctl *dax)
{
@@ -360,13 +361,11 @@ static int copy_user_bh(struct page *to, struct inode *inode,
}
#define NO_SECTOR -1
-#define DAX_PMD_INDEX(page_index) (page_index & (PMD_MASK >> PAGE_CACHE_SHIFT))
static int dax_radix_entry(struct address_space *mapping, pgoff_t index,
sector_t sector, bool pmd_entry, bool dirty)
{
struct radix_tree_root *page_tree = &mapping->page_tree;
- pgoff_t pmd_index = DAX_PMD_INDEX(index);
int type, error = 0;
void *entry;
@@ -376,12 +375,6 @@ static int dax_radix_entry(struct address_space *mapping, pgoff_t index,
spin_lock_irq(&mapping->tree_lock);
- entry = radix_tree_lookup(page_tree, pmd_index);
- if (entry && RADIX_DAX_TYPE(entry) == RADIX_DAX_PMD) {
- index = pmd_index;
- goto dirty;
- }
-
entry = radix_tree_lookup(page_tree, index);
if (entry) {
type = RADIX_DAX_TYPE(entry);
@@ -418,7 +411,8 @@ static int dax_radix_entry(struct address_space *mapping, pgoff_t index,
goto unlock;
}
- error = radix_tree_insert(page_tree, index,
+ error = __radix_tree_insert(page_tree, index,
+ RADIX_DAX_ORDER(pmd_entry),
RADIX_DAX_ENTRY(sector, pmd_entry));
if (error)
goto unlock;
@@ -462,6 +456,13 @@ static int dax_writeback_one(struct block_device *bdev,
goto unlock;
}
+ /*
+ * Even if dax_writeback_mapping_range() was given a wbc->range_start
+ * in the middle of a PMD, the 'index' we are given will be aligned to
+ * the start index of the PMD, as will the sector we pull from
+ * 'entry'. This allows us to flush for PMD_SIZE and not have to
+ * worry about partial PMD writebacks.
+ */
dax.sector = RADIX_DAX_SECTOR(entry);
dax.size = (type == RADIX_DAX_PMD ? PMD_SIZE : PAGE_SIZE);
spin_unlock_irq(&mapping->tree_lock);
@@ -502,12 +503,11 @@ int dax_writeback_mapping_range(struct address_space *mapping,
struct block_device *bdev, struct writeback_control *wbc)
{
struct inode *inode = mapping->host;
- pgoff_t start_index, end_index, pmd_index;
+ pgoff_t start_index, end_index;
pgoff_t indices[PAGEVEC_SIZE];
struct pagevec pvec;
bool done = false;
int i, ret = 0;
- void *entry;
if (WARN_ON_ONCE(inode->i_blkbits != PAGE_SHIFT))
return -EIO;
@@ -517,15 +517,6 @@ int dax_writeback_mapping_range(struct address_space *mapping,
start_index = wbc->range_start >> PAGE_CACHE_SHIFT;
end_index = wbc->range_end >> PAGE_CACHE_SHIFT;
- pmd_index = DAX_PMD_INDEX(start_index);
-
- rcu_read_lock();
- entry = radix_tree_lookup(&mapping->page_tree, pmd_index);
- rcu_read_unlock();
-
- /* see if the start of our range is covered by a PMD entry */
- if (entry && RADIX_DAX_TYPE(entry) == RADIX_DAX_PMD)
- start_index = pmd_index;
tag_pages_for_writeback(mapping, start_index, end_index);
--
2.5.5
4 years, 7 months
[PATCH] libnvdimm, btt: add btt startup debug
by Dan Williams
Report the reason for btt probe failures when debug is enabled.
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
---
drivers/nvdimm/btt.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
index cc9fafed9362..68a7c3c1eed9 100644
--- a/drivers/nvdimm/btt.c
+++ b/drivers/nvdimm/btt.c
@@ -1383,11 +1383,15 @@ int nvdimm_namespace_attach_btt(struct nd_namespace_common *ndns)
struct btt *btt;
size_t rawsize;
- if (!nd_btt->uuid || !nd_btt->ndns || !nd_btt->lbasize)
+ if (!nd_btt->uuid || !nd_btt->ndns || !nd_btt->lbasize) {
+ dev_dbg(&nd_btt->dev, "incomplete btt configuration\n");
return -ENODEV;
+ }
rawsize = nvdimm_namespace_capacity(ndns) - SZ_4K;
if (rawsize < ARENA_MIN_SIZE) {
+ dev_dbg(&nd_btt->dev, "%s must be at least %ld bytes\n",
+ dev_name(&ndns->dev), ARENA_MIN_SIZE + SZ_4K);
return -ENXIO;
}
nd_region = to_nd_region(nd_btt->dev.parent);
4 years, 7 months
[PATCH] libnvdimm, pmem: clarify the write+clear_poison+write flow
by Dan Williams
The ACPI specification does not specify the state of data after a clear
poison operation. Potential future libnvdimm bus implementations for
other architectures also might not specify or disagree on the state of
data after clear poison. Clarify why we write twice.
Reported-by: Jeff Moyer <jmoyer(a)redhat.com>
Reported-by: Vishal Verma <vishal.l.verma(a)intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
---
drivers/nvdimm/pmem.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index c6befaa9c708..d9a0dbc2d023 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -86,6 +86,20 @@ static int pmem_do_bvec(struct pmem_device *pmem, struct page *page,
flush_dcache_page(page);
}
} else {
+ /*
+ * Note that we write the data both before and after
+ * clearing poison. The write before clear poison
+ * handles situations where the latest written data is
+ * preserved and the clear poison operation simply marks
+ * the address range as valid without changing the data.
+ * In this case application software can assume that an
+ * interrupted write will either return the new good
+ * data or an error.
+ *
+ * However, if pmem_clear_poison() leaves the data in an
+ * indeterminate state we need to perform the write
+ * after clear poison.
+ */
flush_dcache_page(page);
memcpy_to_pmem(pmem_addr, mem + off, len);
if (unlikely(bad_pmem)) {
4 years, 7 months
20:12:00
by 计思卉
linux-nvdimm：您好！！
班组长精益化安全管理技能提升
课程概述
班组长作为“兵头将尾”，是企业贯彻制度的桥梁与纽带，是生产现场的直接指挥者和组织者，也是班组安全生产的第一责任者。 班组长安全管理技能提升，对企业提升安全管理水平，以及安全政策与制度的落地，将起到积极推进作用。
本课程的结构与大量的管理与工具，为咨询顾问团队独家研发，是帮助企业的班组安全管理落地的一门系统课程。旨在解决以下问题：
班组长安全管理意识单薄，不愿意参与日常安全管理；
班组安全管理粗暴简单，未基于事故风险展开系统控制；
班组长被动应付企业各类安全管理的要求，但实质的成果不多，大量工作流于形式；
班组长不了解安全管理的具体工具，头痛医头、脚痛医脚；
……
课程中，不仅仅讲授班组长安全管理的要点，介绍先进安全管理理念和实用方法，更注重学员的参与和互动，引导学员融入课程，循序渐进将学员引入全新的管理领域。培训过程通过系统的理论讲解、实际案例分析总结、实战演练等方法，帮助学员提高意识、树立信心、增强技管理能、得到意想不到的收获……
课程简介
培训对象：班组长、班组长、工位长、工段长等一线主管即将成为基层管理人员的班组骨干等
授课形式：知识讲授、视频分析、案例展示、角色扮演、实操演练等
课程时间：2天 ( 2016年4月23-24上海、7月23-24日上海、11月18-19日上海 )
课程费用：2580元/人/2天
费用包含：课程资料费、午餐、茶点、发票（普票）
联系电话：0512-687.006.53 （0）1801.5596.327
课程特色
班组管理手册：指导班组长在课程中建立标准的管理手册，用大量的指导性文件和标准纪录，让班组日常安全管理更加标准化、简单、高效。
班组标准管理模型：从班前、班中到班后，指导班组长建立标准的、高效的管理路径，提升班组长在安全管理中的效率和质量，降低过多的形式主义。
风险管理为轴线：课程中大量的管理工具，让班组安全管理活动紧扣风险的系统控制来开展，包括培训、检查、改善、活动等，降低班组日常管理中的负担，并提高事故控制的能力。
课程收获
管理意识：掌握班组长在安全管理过程中的四大角色，并引导学员认识到班组安全管理的必要性和管理方向。
风险系统控制技术：使用班组布局图，快速识别班组存在的风险，并基于风险制定系统的管控措施，用于现场目视化、员工培训等，切实降低事故风险。
检查与隐患治理技巧：掌握识别班组隐患、善意提醒不安全行为、根治隐患确保不重复发生的等管理技巧。
班组日常管理活动：掌握班会、日常改善、安全绩效管理、安全活动等班组必须的管理活动的实施技巧，提高安全管理的效率。
课程大纲
第一部分：班组安全管理的全面认识
第二部分：班组作业风险的动态管理（独家研发：快速风险评估法）
第三部分 作业现场安全目视化
第四部分 班组安全培训与安全活动实施技巧
第五部分 班组安全检查与行为安全管理
第六部分 班组事故管理
第七部分 班组日常安全管理
2dispabgflpzzkgtfh7kmjpqg0q9rbj5pmxxa8g1w2kaqm33qj84ooka1mv0
4 years, 7 months
[PATCH v8 00/10] nvdimm: Add an IOCTL pass thru for DSM calls
by Jerry Hoemann
The NVDIMM code in the kernel supports an IOCTL interface to user
space based upon the Intel Example DSM:
http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
This interface cannot be used by other NVDIMM DSMs that support
incompatible functions.
An alternative DSM specification for Type N DSM being developed
by Hewlett Packard Enterprise can be found at:
https://github.com/HewlettPackard/hpe-nvm/tree/master/Documentation
To accommodate multiple and conflicting DSM specifications, this patch
set adds a generic "pass-thru" IOCTL interface which is not tied to
a particular DSM.
A new _IOC_NR ND_CMD_CALL == "10" is added for the pass thru call.
The new data structure nd_cmd_pkg serves as a wrapper for the
pass-thru calls. This wrapper supplies the data that the kernel
needs to make the _DSM call.
Unlike the definitions of the _DSM functions themselves, the nd_cmd_pkg
provides the calling information (input/output sizes) in an uniform
manner making the kernel marshaling of the arguments straight
forward.
This shifts the marshaling burden from the kernel to the user
space application while still permitting the kernel to internally
call _DSM functions.
The kernel functions __nd_ioctl and acpi_nfit_ctl were modified
to accommodate ND_CMD_CALL.
Changes in version 8:
---------------------
1. augmented family_to_uuid() to return uuid. This to address bug
in prior version where acpi_nfit_ctl wasn't updating uuid
with value associated with command family.
2. patch 0006 changes name of nvdimm_bus_descriptor.dsm_mask to .cmd_mask
3. patch 0008 adds field cmd_ioctl if kernel supports full ioctl
as with Intel example dsm.
4. patch 0009 make determination if kernel supports the full
cmd_ioctl for that dsm. Updates the commands_show function
to invert the sense of display of commands. All dsm support
pass-thru, only the Intel Example DSM supports the full
ioctl interface.
5. patch 0010 adds explicit ioctl interface to return command mask.
This was done in part to avoid "unknown" command in sysfs.
Changes in version 7:
--------------------
0. change name ND_CMD_CALL_DSM to ND_CMD_CALL
- part of abstracting out DSM missed in version 6.
1. change name in struct nd_call_dsm
a) "ncp_" -> "nd_"
b) ncp_pot_size -> nd_fw_size
c) ncp_type -> nd_family
o) cascade name changes to other patches
2. Expanded comment around data structure nd_cmd_pkg
3. At Dan's request, hard coding "root" UUID.
a) retract extension of dsm_uuid to nvdimm_bus_descriptor.
b) reverted nfit.c/acpi_nfit_init_dsms() with the exception of
allowing function 0 in mask.
4. At Dan's request, removed "rev" from nd_cmd_pkg. Hard-coding
use of rev "1" in acpi_nfit_ctl.
Changes in version 6:
---------------------
Built against
git://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git
libnvdimm-pending
0. Patches "Clean-up access mode check" and "Fix security issue with DSM IOCTL"
already in above libnvdimm-pending. So omitted here.
1. Incorporated changes from Dan's RFC patch set
https://lists.01.org/pipermail/linux-nvdimm/2016-January/004049.html
2. Dan asked me to abstract out the DSM aspects from the ndm_cmd_dsmcall_pkg.
This became nd_cmd_pkg. UUIDs are no longer passed in from
user applications.
3. To accommodate multiple UUIDS, added table cmd_type_tbl which is used
to determine UUID for the acpi object by calling function 0 for
each UUID in table until success.
This table also provides a MASK field that the kernel can use
to exclude functions being called.
This table can be thought of a list of "acceptable" DSMs.
4. The cmd_type_tbl is also used by acpi_nfit_ctl to map the
external handle of calls to internal handle, UUID.
Note, code only validates that the requested type of call is one in
cmd_type_tbl, but it might not necessarily be the same found during
acpi_nfit_add_dimm. The ACPI SPEC appears to allow and firmware
does implement multiple UUID per object.
In the case where type is in table, but the UUID isn't supported
by the underlying firmware, firmware shall return an error when
called.
This allows for use of a secondary DSM on an object. This could
be considered a feature or a defect. This can be tightened
up if needed.
Changes in version 5:
---------------------
0. Fixed submit comment for drivers/acpi/utils.c.
Changes in version 4:
---------------------
0. Added patch to correct parameter type passed to acpi_evaluate_dsm
ACPI defines arguments rev and fun as 64 bit quantities and the ioctl
exports to user face rev and func. We want those to match the ACPI spec.
Also modified acpi_evaluate_dsm_typed and acpi_check dsm which had
similar issue.
1. nd_cmd_dsmcall_pkg rearrange a reserve and rounded up total size
to 16 byte boundary.
2. Created stand alone patch for the pre-existing security issue related
to "read only" IOCTL calls.
3. Added patch for increasing envelope size of IOCTL. Needed to
be able to read in the wrapper to know remaining size to copy in.
Note: in_env, out_env are statics sized based upon this change.
4. Moved copyin code to table driven nd_cmd_desc
Note, the last 40 lines or so of acpi_nfit_ctl will not return _DSM
data unless the size allocated in user space buffer equals
out_obj->buffer.length.
The semantic we want in the pass thru case is to return as much
of the _DSM data as the user space buffer would accommodate.
Hence, in acpi_nfit_ctl I have retained the line:
memcpy(pkg->dsm_buf + pkg->h.dsm_in,
out_obj->buffer.pointer,
min(pkg->h.dsm_size, pkg->h.dsm_out));
and the early return from the function.
Changes in version 3:
---------------------
1. Changed name ND_CMD_PASSTHRU to ND_CMD_CALL_DSM.
2. Value of ND_CMD_CALL_DSM is 10, not 100.
3. Changed name of nd_passthru_pkg to nd_cmd_dsmcall_pkg.
4. Removed separate functions for handling ND_CMD_CALL_DSM.
Moved functionality to __nd_ioctl and acpi_nfit_ctl proper.
The resultant code looks very different from prior versions.
5. BUGFIX: __nd_ioctl: Change the if read_only switch to use
_IOC_NR cmd (not ioctl_cmd) for better protection.
Do we want to make a stand alone patch for this issue?
Changes in version 2:
---------------------
1. Cleanup access mode check in nd_ioctl and nvdimm_ioctl.
2. Change name of ndn_pkg to nd_passthru_pkg
3. Adjust sizes in nd_passthru_pkg. DSM integers are 64 bit.
4. No new ioctl type, instead tunnel into the existing number space.
5. Push down one function level where determine ioctl cmd type.
6. re-work diagnostic print/dump message in pass-thru functions.
Jerry Hoemann (10):
ACPI / util: Fix acpi_evaluate_dsm() argument type
nvdimm: Add wrapper for IOCTL pass thru
nvdimm: Increase max envelope size for IOCTL
nvdimm: Add UUIDs
nvdimm: Add IOCTL pass thru functions
libnvdimm: nvdimm_bus_descriptor field name change
tools/testing/nvdimm: 'call_dsm' support
nvdimm: command ioctl support
nvdimm: sysfs shows which dsm support full command ioctl.
nvdimm: Add ioctl to return command mask.
drivers/acpi/nfit.c | 154 +++++++++++++++++++++++++++++++++------
drivers/acpi/nfit.h | 6 ++
drivers/acpi/utils.c | 4 +-
drivers/nvdimm/bus.c | 55 +++++++++++++-
drivers/nvdimm/core.c | 3 +-
drivers/nvdimm/dimm_devs.c | 12 ++-
drivers/nvdimm/nd-core.h | 1 +
include/acpi/acpi_bus.h | 6 +-
include/linux/libnvdimm.h | 6 +-
include/uapi/linux/ndctl.h | 62 ++++++++++++++++
tools/testing/nvdimm/test/nfit.c | 15 +++-
11 files changed, 283 insertions(+), 41 deletions(-)
--
1.7.11.3
4 years, 7 months
ext4 error
by Eric Shang
HI All:
I meet an ext4 error, following is the error log. After panic, I check the emmc by the tool debufs, the inode 69878 i_nlink is not zero. And this inode don't belong to parent dir 6987, it belong to other file(this inode belong to two files when check by debugfs ncheck), I guess than this inode has beed deleted in memory and already used by other file. But the parent dentry buff_head not flush to emmc. But when lookup this dentry can't find it' in dentry cache, and then lookup_real, read the dentry from emmc, get the file inode which already be deleted.
Can any give me some help how to check this issue. My kernel version is 3.18 form Android . I thinks something wrong with dentry cache flush and dirty buff_head flush to emmc. Thanks all!
:Sending Trackball (ACTION_MOVE): 0:(-[44802.841647] EXT4-fs error (device mmcblk0p16): ext4_lookup:1417: inode #69877: comm installd: deleted inode referenced: 69878
5.0[44802.853210] Aborting journal on device mmcblk0p16-8.
,2.[44802.858345] Kernel panic - not syncing: EXT4-fs (device mmcblk0p16): panic forced after error
[44802.858345]
[44802.868322] CPU: 1 PID: 216 Comm: installd Tainted: P O 3.18.0-94.02.04 #1
[44802.876223] [<c0016874>] (unwind_backtrace) from [<c00123e8>] (show_stack+0x10/0x14)
[44802.883927] [<c00123e8>] (show_stack) from [<c07af1b0>] (dump_stack+0x70/0xbc)
[44802.891117] [<c07af1b0>] (dump_stack) from [<c07ab328>] (panic+0xa4/0x218)
[44802.897965] [<c07ab328>] (panic) from [<c01c2fa4>] (ext4_handle_error+0x6c/0xa8)
[44802.905330] [<c01c2fa4>] (ext4_handle_error) from [<c01c323c>] (__ext4_error_inode+0x6c/0x114)
[44802.913909] [<c01c323c>] (__ext4_error_inode) from [<c01b2e18>] (ext4_lookup+0xf0/0x148)
[44802.921970] [<c01b2e18>] (ext4_lookup) from [<c0130148>] (lookup_real+0x20/0x50)
[44802.929336] [<c0130148>] (lookup_real) from [<c0130c60>] (__lookup_hash+0x34/0x44)
[44802.936873] [<c0130c60>] (__lookup_hash) from [<c0131f98>] (lookup_slow+0x38/0x9c)
[44802.944414] [<c0131f98>] (lookup_slow) from [<c0132a34>] (path_lookupat+0x228/0x728)
[44802.952127] [<c0132a34>] (path_lookupat) from [<c0132f54>] (filename_lookup+0x20/0xbc)
[44802.960013] [<c0132f54>] (filename_lookup) from [<c0136128>] (user_path_at_empty+0x50/0x78)
[44802.968334] [<c0136128>] (user_path_at_empty) from [<c0136164>] (user_path_at+0x14/0x1c)
[44802.976394] [<c0136164>] (user_path_at) from [<c012c52c>] (vfs_fstatat+0x48/0x8c)
[44802.983847] [<c012c52c>] (vfs_fstatat) from [<c012c820>] (SyS_fstatat64+0x14/0x30)
[44802.991389] [<c012c820>] (SyS_fstatat64) from [<c000eae0>] (ret_fast_syscall+0x0/0x48)
Best Regards
EricShang
4 years, 7 months
