Please Kindly Acknowledge Our New Order
Dear sir, Kindly find the attachment of our new order as discussed with our agent who is currently not available, Please kindly arrange to send your best quote for our inquiry doc54698754 and also tell me the possible time for delivery basis. We kindly request you to arrange the quotation at the earliest. Z poważaniem / Best Regards Monika Krekora-Ansorge Senior Export Manager International Sales Department mob.: +48 660 089 689 e-mail: i...@messenietrade.com Dr Gerard sp. z o.o. ul. Salsy 2 02-823 Warszawa tel.: +48 22 722 46 46 ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH v2] fs/dax: deposit pagetable even when installing zero page
Hi Dan/Andrew/Jan,
"Aneesh Kumar K.V" writes:
> Architectures like ppc64 use the deposited page table to store hardware
> page table slot information. Make sure we deposit a page table when
> using zero page at the pmd level for hash.
>
> Without this we hit
>
> Unable to handle kernel paging request for data at address 0x
> Faulting instruction address: 0xc0082a74
> Oops: Kernel access of bad area, sig: 11 [#1]
>
>
> NIP [c0082a74] __hash_page_thp+0x224/0x5b0
> LR [c00829a4] __hash_page_thp+0x154/0x5b0
> Call Trace:
> hash_page_mm+0x43c/0x740
> do_hash_page+0x2c/0x3c
> copy_from_iter_flushcache+0xa4/0x4a0
> pmem_copy_from_iter+0x2c/0x50 [nd_pmem]
> dax_copy_from_iter+0x40/0x70
> dax_iomap_actor+0x134/0x360
> iomap_apply+0xfc/0x1b0
> dax_iomap_rw+0xac/0x130
> ext4_file_write_iter+0x254/0x460 [ext4]
> __vfs_write+0x120/0x1e0
> vfs_write+0xd8/0x220
> SyS_write+0x6c/0x110
> system_call+0x3c/0x130
>
> Fixes: b5beae5e224f ("powerpc/pseries: Add driver for PAPR SCM regions")
> Reviewed-by: Jan Kara
> Signed-off-by: Aneesh Kumar K.V
Any suggestion on which tree this patch should got to? Also since this
fix a kernel crash, we may want to get this to 5.1?
> ---
> Changes from v1:
> * Add reviewed-by:
> * Add Fixes:
>
> fs/dax.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 6959837cc465..01bfb2ac34f9 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
> #include "internal.h"
>
> #define CREATE_TRACE_POINTS
> @@ -1410,7 +1411,9 @@ static vm_fault_t dax_pmd_load_hole(struct xa_state
> *xas, struct vm_fault *vmf,
> {
> struct address_space *mapping = vmf->vma->vm_file->f_mapping;
> unsigned long pmd_addr = vmf->address & PMD_MASK;
> + struct vm_area_struct *vma = vmf->vma;
> struct inode *inode = mapping->host;
> + pgtable_t pgtable = NULL;
> struct page *zero_page;
> spinlock_t *ptl;
> pmd_t pmd_entry;
> @@ -1425,12 +1428,22 @@ static vm_fault_t dax_pmd_load_hole(struct xa_state
> *xas, struct vm_fault *vmf,
> *entry = dax_insert_entry(xas, mapping, vmf, *entry, pfn,
> DAX_PMD | DAX_ZERO_PAGE, false);
>
> + if (arch_needs_pgtable_deposit()) {
> + pgtable = pte_alloc_one(vma->vm_mm);
> + if (!pgtable)
> + return VM_FAULT_OOM;
> + }
> +
> ptl = pmd_lock(vmf->vma->vm_mm, vmf->pmd);
> if (!pmd_none(*(vmf->pmd))) {
> spin_unlock(ptl);
> goto fallback;
> }
>
> + if (pgtable) {
> + pgtable_trans_huge_deposit(vma->vm_mm, vmf->pmd, pgtable);
> + mm_inc_nr_ptes(vma->vm_mm);
> + }
> pmd_entry = mk_pmd(zero_page, vmf->vma->vm_page_prot);
> pmd_entry = pmd_mkhuge(pmd_entry);
> set_pmd_at(vmf->vma->vm_mm, pmd_addr, vmf->pmd, pmd_entry);
> @@ -1439,6 +1452,8 @@ static vm_fault_t dax_pmd_load_hole(struct xa_state
> *xas, struct vm_fault *vmf,
> return VM_FAULT_NOPAGE;
>
> fallback:
> + if (pgtable)
> + pte_free(vma->vm_mm, pgtable);
> trace_dax_pmd_load_hole_fallback(inode, vmf, zero_page, *entry);
> return VM_FAULT_FALLBACK;
> }
> --
> 2.20.1
-aneesh
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
Ycae
The original message was received at Wed, 13 Mar 2019 11:53:14 +0800 from lists.01.org [84.31.171.236] - The following addresses had permanent fatal errors - ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
如何做好客户服务
linux-nvdimm@lists.01.org ¸½ ¼þ ÄÚ ÈÝ Çë Äú ²é ÔÄ ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH] acpi/nfit: Always dump _DSM output payload
On Tue, 2019-03-12 at 14:37 -0700, Dan Williams wrote:
> The dynamic-debug statements for command payload output only get
> emitted
> when the command is not ND_CMD_CALL. Move the output payload dumping
> ahead of the early return path for ND_CMD_CALL.
>
> Fixes: 31eca76ba2fc9 ("...whitelisted dimm command marshaling
> mechanism")
> Reported-by: Vishal Verma
> Signed-off-by: Dan Williams
> ---
> drivers/acpi/nfit/core.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
Looks good to me,
Reviewed-by: Vishal Verma
> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> index a22e2f2bbb75..c9367e78521b 100644
> --- a/drivers/acpi/nfit/core.c
> +++ b/drivers/acpi/nfit/core.c
> @@ -546,6 +546,12 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor
> *nd_desc, struct nvdimm *nvdimm,
> goto out;
> }
>
> + dev_dbg(dev, "%s cmd: %s output length: %d\n", dimm_name,
> + cmd_name, out_obj->buffer.length);
> + print_hex_dump_debug(cmd_name, DUMP_PREFIX_OFFSET, 4, 4,
> + out_obj->buffer.pointer,
> + min_t(u32, 128, out_obj->buffer.length), true);
> +
> if (call_pkg) {
> call_pkg->nd_fw_size = out_obj->buffer.length;
> memcpy(call_pkg->nd_payload + call_pkg->nd_size_in,
> @@ -564,12 +570,6 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor
> *nd_desc, struct nvdimm *nvdimm,
> return 0;
> }
>
> - dev_dbg(dev, "%s cmd: %s output length: %d\n", dimm_name,
> - cmd_name, out_obj->buffer.length);
> - print_hex_dump_debug(cmd_name, DUMP_PREFIX_OFFSET, 4, 4,
> - out_obj->buffer.pointer,
> - min_t(u32, 128, out_obj->buffer.length), true);
> -
> for (i = 0, offset = 0; i < desc->out_num; i++) {
> u32 out_size = nd_cmd_out_size(nvdimm, cmd, desc, i,
> buf,
> (u32 *) out_obj->buffer.pointer,
>
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
[GIT PULL] Filesystem-DAX fixes for 5.1
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/fsdax-for-5.1 ...to receive a small collection of cleanups and an Xarray fix for v5.1-rc1. It has soaked in -next without issue, although the Xarray fix was recently re-flowed to fix up a tracepoint argument and add Jan's reviewed-by. --- The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9: Linux 5.0-rc6 (2019-02-10 14:42:20 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/fsdax-for-5.1 for you to fetch changes up to e4b3448bc346fedf36db64124a664a959995b085: dax: Flush partial PMDs correctly (2019-03-01 17:24:48 -0800) filesystem-dax for 5.1 * Fix handling of PMD-sized entries in the Xarray that lead to a crash scenario. * Miscellaneous cleanups and small fixes Ira Weiny (1): fs/dax: NIT fix comment regarding start/end vs range Matthew Wilcox (1): dax: Flush partial PMDs correctly Souptick Joarder (1): fs/dax: Convert to use vmf_error() fs/dax.c | 25 +++-- 1 file changed, 11 insertions(+), 14 deletions(-) ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [mm PATCH v6 6/7] mm: Add reserved flag setting to set_page_links
On Tue, 2019-03-12 at 15:07 -0700, Andrew Morton wrote: > On Wed, 5 Dec 2018 21:42:47 +0100 Michal Hocko wrote: > > > > I got your explanation. However Andrew had already applied the patches > > > and I had some outstanding issues in them that needed to be addressed. > > > So I thought it best to send out this set of patches with those fixes > > > before the code in mm became too stale. I am still working on what to > > > do about the Reserved bit, and plan to submit it as a follow-up set. > > > From my experience Andrew can drop patches between different versions of > > the patchset. Things can change a lot while they are in mmotm and under > > the discussion. > > It's been a while and everyone has forgotten everything, so I'll drop > this version of the patchset. > As far as getting to the reserved bit I probably won't have the time in the near future. If I were to resubmit the first 4 patches as a standalone patch set would that be acceptable, or would they be held up as well until the reserved bit issues is addressed? - Alex ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [mm PATCH v6 6/7] mm: Add reserved flag setting to set_page_links
On Wed, 5 Dec 2018 21:42:47 +0100 Michal Hocko wrote: > > I got your explanation. However Andrew had already applied the patches > > and I had some outstanding issues in them that needed to be addressed. > > So I thought it best to send out this set of patches with those fixes > > before the code in mm became too stale. I am still working on what to > > do about the Reserved bit, and plan to submit it as a follow-up set. > > >From my experience Andrew can drop patches between different versions of > the patchset. Things can change a lot while they are in mmotm and under > the discussion. It's been a while and everyone has forgotten everything, so I'll drop this version of the patchset. ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
[PATCH] acpi/nfit: Always dump _DSM output payload
The dynamic-debug statements for command payload output only get emitted
when the command is not ND_CMD_CALL. Move the output payload dumping
ahead of the early return path for ND_CMD_CALL.
Fixes: 31eca76ba2fc9 ("...whitelisted dimm command marshaling mechanism")
Reported-by: Vishal Verma
Signed-off-by: Dan Williams
---
drivers/acpi/nfit/core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index a22e2f2bbb75..c9367e78521b 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -546,6 +546,12 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc,
struct nvdimm *nvdimm,
goto out;
}
+ dev_dbg(dev, "%s cmd: %s output length: %d\n", dimm_name,
+ cmd_name, out_obj->buffer.length);
+ print_hex_dump_debug(cmd_name, DUMP_PREFIX_OFFSET, 4, 4,
+ out_obj->buffer.pointer,
+ min_t(u32, 128, out_obj->buffer.length), true);
+
if (call_pkg) {
call_pkg->nd_fw_size = out_obj->buffer.length;
memcpy(call_pkg->nd_payload + call_pkg->nd_size_in,
@@ -564,12 +570,6 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc,
struct nvdimm *nvdimm,
return 0;
}
- dev_dbg(dev, "%s cmd: %s output length: %d\n", dimm_name,
- cmd_name, out_obj->buffer.length);
- print_hex_dump_debug(cmd_name, DUMP_PREFIX_OFFSET, 4, 4,
- out_obj->buffer.pointer,
- min_t(u32, 128, out_obj->buffer.length), true);
-
for (i = 0, offset = 0; i < desc->out_num; i++) {
u32 out_size = nd_cmd_out_size(nvdimm, cmd, desc, i, buf,
(u32 *) out_obj->buffer.pointer,
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
RE: Hang / zombie process from Xarray page-fault conversion (bisected)
Hi Guys, "> It's limited to xfs, no failure on ext4 to date", this is incorrect. I have been able to reproduce this issue with ext4. In order to do that, I need to run the full test (on both pmems in the system) and not the half test (only 1 pmem) that I use for inducing the hang under XFS. The test also runs considerably longer before failing with ext4 than XFS. Thx bob -Original Message- From: Dave Chinner [mailto:da...@fromorbit.com] Sent: Monday, March 11, 2019 9:38 PM To: Williams, Dan J Cc: Matthew Wilcox ; Linux MM ; linux-nvdimm ; linux-fsdevel ; Barror, Robert Subject: Re: Hang / zombie process from Xarray page-fault conversion (bisected) On Mon, Mar 11, 2019 at 08:35:05PM -0700, Dan Williams wrote: > On Mon, Mar 11, 2019 at 8:10 AM Matthew Wilcox wrote: > > > > On Thu, Mar 07, 2019 at 10:16:17PM -0800, Dan Williams wrote: > > > Hi Willy, > > > > > > We're seeing a case where RocksDB hangs and becomes defunct when > > > trying to kill the process. v4.19 succeeds and v4.20 fails. Robert > > > was able to bisect this to commit b15cd800682f "dax: Convert page > > > fault handlers to XArray". > > > > > > I see some direct usage of xa_index and wonder if there are some > > > more pmd fixups to do? > > > > > > Other thoughts? > > > > I don't see why killing a process would have much to do with PMD > > misalignment. The symptoms (hanging on a signal) smell much more > > like leaving a locked entry in the tree. Is this easy to reproduce? > > Can you get /proc/$pid/stack for a hung task? > > It's fairly easy to reproduce, I'll see if I can package up all the > dependencies into something that fails in a VM. > > It's limited to xfs, no failure on ext4 to date. > > The hung process appears to be: > > kworker/53:1-xfs-sync/pmem0 That's completely internal to XFS. Every 30s the work is triggered and it either does a log flush (if the fs is active) or it syncs the superblock to clean the log and idle the filesystem. It has nothing to do with user processes, and I don't see why killing a process has any effect on what it does... > ...and then the rest of the database processes grind to a halt from there. > > Robert was kind enough to capture /proc/$pid/stack, but nothing interesting: > > [<0>] worker_thread+0xb2/0x380 > [<0>] kthread+0x112/0x130 > [<0>] ret_from_fork+0x1f/0x40 > [<0>] 0x Much more useful would be: # echo w > /proc/sysrq-trigger And post the entire output of dmesg. Cheers, Dave. -- Dave Chinner da...@fromorbit.com ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
[PATCH] nvdimm: namespace_devs: fix a potential NULL pointer dereference
In case kmemdup fails, the fix goes to blk_err to avoid NULL
pointer dereference
Signed-off-by: Kangjie Lu
---
drivers/nvdimm/namespace_devs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index 4b077555ac70..6f65261e151f 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -2245,9 +2245,12 @@ static struct device *create_namespace_blk(struct
nd_region *nd_region,
if (!nsblk->uuid)
goto blk_err;
memcpy(name, nd_label->name, NSLABEL_NAME_LEN);
- if (name[0])
+ if (name[0]) {
nsblk->alt_name = kmemdup(name, NSLABEL_NAME_LEN,
GFP_KERNEL);
+ if (!nsblk->alt_name)
+ goto blk_err;
+ }
res = nsblk_add_resource(nd_region, ndd, nsblk,
__le64_to_cpu(nd_label->dpa));
if (!res)
--
2.17.1
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
[PATCH] nvdimm: btt_devs: fix a NULL pointer dereference and a memory leak
In case kmemdup fails, the fix releases resources and returns to
avoid the NULL pointer dereference.
Also, the error paths in the following code should release
resources to avoid memory leaks.
Signed-off-by: Kangjie Lu
---
drivers/nvdimm/btt_devs.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
index 795ad4ff35ca..565ea0b6f765 100644
--- a/drivers/nvdimm/btt_devs.c
+++ b/drivers/nvdimm/btt_devs.c
@@ -196,8 +196,13 @@ static struct device *__nd_btt_create(struct nd_region
*nd_region,
}
nd_btt->lbasize = lbasize;
- if (uuid)
+ if (uuid) {
uuid = kmemdup(uuid, 16, GFP_KERNEL);
+ if (!uuid) {
+ kfree(nd_btt);
+ return NULL;
+ }
+ }
nd_btt->uuid = uuid;
dev = &nd_btt->dev;
dev_set_name(dev, "btt%d.%d", nd_region->id, nd_btt->id);
@@ -209,6 +214,7 @@ static struct device *__nd_btt_create(struct nd_region
*nd_region,
dev_dbg(&ndns->dev, "failed, already claimed by %s\n",
dev_name(ndns->claim));
put_device(dev);
+ kfree(uuid);
return NULL;
}
return dev;
--
2.17.1
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
