[PATCH 1/2] scsi: megaraid: Remove redundant code in megasas_alloc_cmds

megasas_alloc_cmds is to alloc cmd_list of instance instead of fusion, and fusion is useless in this function. Just remove it. Signed-off-by: Yisheng Xie --- drivers/scsi/megaraid/megaraid_sas_base.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c

Re: [PATCH v2] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

Hi Will, On 2017/10/20 16:36, Will Deacon wrote: > On Fri, Oct 20, 2017 at 03:00:01PM +0800, Yisheng Xie wrote: >> Any comment about this version? > > I have it queued up and plan to send a pull request to Joerg today for 4.15. Fine, thanks. Thanks Yisheng Xie > > Will > > . >

Re: [PATCH v2] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

Hi Will, On 2017/10/20 16:36, Will Deacon wrote: > On Fri, Oct 20, 2017 at 03:00:01PM +0800, Yisheng Xie wrote: >> Any comment about this version? > > I have it queued up and plan to send a pull request to Joerg today for 4.15. Fine, thanks. Thanks Yisheng Xie > > Will > > . >

Re: [PATCH v2] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

Hi Will & Jean, Any comment about this version? Thanks Yisheng Xie On 2017/9/21 20:36, Yisheng Xie wrote: > According to Spec, it is ILLEGAL to set STE.S1STALLD if STALL_MODEL > is not 0b00, which means we should not disable stall mode if stall > or terminate mode is no

Re: [PATCH v2] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

Hi Will & Jean, Any comment about this version? Thanks Yisheng Xie On 2017/9/21 20:36, Yisheng Xie wrote: > According to Spec, it is ILLEGAL to set STE.S1STALLD if STALL_MODEL > is not 0b00, which means we should not disable stall mode if stall > or terminate mode is no

Re: [PATCH] mm/mempolicy: add node_empty check in SYSC_migrate_pages

Hi Vlastimil, Thanks for your comment! On 2017/10/18 18:46, Vlastimil Babka wrote: > On 10/18/2017 11:34 AM, Yisheng Xie wrote: >>>> For MAX_NUMNODES is 4, so 0x10 nodemask will tread as empty set which makes >>>>nodes_subset(*new, node_states[N_MEMORY]) &

Re: [PATCH] mm/mempolicy: add node_empty check in SYSC_migrate_pages

Hi Vlastimil, Thanks for your comment! On 2017/10/18 18:46, Vlastimil Babka wrote: > On 10/18/2017 11:34 AM, Yisheng Xie wrote: >>>> For MAX_NUMNODES is 4, so 0x10 nodemask will tread as empty set which makes >>>>nodes_subset(*new, node_states[N_MEMORY]) &

Re: [PATCH] mm/mempolicy: add node_empty check in SYSC_migrate_pages

Hi Vlastimil, Thanks for you comment! On 2017/10/18 17:34, Yisheng Xie wrote: > Hi Vlastimil, > > Thanks for your comment! > On 2017/10/18 15:54, Vlastimil Babka wrote: >> +CC linux-api >> >> On 10/18/2017 03:37 AM, Yisheng Xie wrote: >>> As Xiao

Re: [PATCH] mm/mempolicy: add node_empty check in SYSC_migrate_pages

Hi Vlastimil, Thanks for you comment! On 2017/10/18 17:34, Yisheng Xie wrote: > Hi Vlastimil, > > Thanks for your comment! > On 2017/10/18 15:54, Vlastimil Babka wrote: >> +CC linux-api >> >> On 10/18/2017 03:37 AM, Yisheng Xie wrote: >>> As Xiao

Re: [PATCH] mm/mempolicy: add node_empty check in SYSC_migrate_pages

Hi Vlastimil, Thanks for your comment! On 2017/10/18 15:54, Vlastimil Babka wrote: > +CC linux-api > > On 10/18/2017 03:37 AM, Yisheng Xie wrote: >> As Xiaojun reported the ltp of migrate_pages01 will failed on ARCH arm64 >> system whoes has 4 nodes[0...3], all have memory a

Re: [PATCH] mm/mempolicy: add node_empty check in SYSC_migrate_pages

Hi Vlastimil, Thanks for your comment! On 2017/10/18 15:54, Vlastimil Babka wrote: > +CC linux-api > > On 10/18/2017 03:37 AM, Yisheng Xie wrote: >> As Xiaojun reported the ltp of migrate_pages01 will failed on ARCH arm64 >> system whoes has 4 nodes[0...3], all have memory a

Re: [bug report & help] arm64: ltp testcase "migrate_pages01" failed

Hi Will, On 2017/10/17 21:19, Yisheng Xie wrote: > Hi Will, > > On 2017/10/17 17:23, Will Deacon wrote: >> On Tue, Oct 17, 2017 at 10:58:53AM +0800, Tan Xiaojun wrote: >>> I'm not sure if this is the problem on arm64 numa. What do you think ? >>> By the way

Re: [bug report & help] arm64: ltp testcase "migrate_pages01" failed

Hi Will, On 2017/10/17 21:19, Yisheng Xie wrote: > Hi Will, > > On 2017/10/17 17:23, Will Deacon wrote: >> On Tue, Oct 17, 2017 at 10:58:53AM +0800, Tan Xiaojun wrote: >>> I'm not sure if this is the problem on arm64 numa. What do you think ? >>> By the way

[PATCH] mm/mempolicy: add node_empty check in SYSC_migrate_pages

node_empty check in SYSC_migrate_pages. Reported-by: Tan Xiaojun <tanxiao...@huawei.com> Signed-off-by: Yisheng Xie <xieyishe...@huawei.com> --- mm/mempolicy.c | 5 + 1 file changed, 5 insertions(+) diff --git a/mm/mempolicy.c b/mm/mempolicy.c index a2af6d5..1dfd3cc 100644 --- a/mm

[PATCH] mm/mempolicy: add node_empty check in SYSC_migrate_pages

node_empty check in SYSC_migrate_pages. Reported-by: Tan Xiaojun Signed-off-by: Yisheng Xie --- mm/mempolicy.c | 5 + 1 file changed, 5 insertions(+) diff --git a/mm/mempolicy.c b/mm/mempolicy.c index a2af6d5..1dfd3cc 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -1388,6 +1388,11 @@ static

Re: [bug report & help] arm64: ltp testcase "migrate_pages01" failed

roduce at certain config on X86-64 e.g. CONFIG_NODES_SHIFT=3 and have 8 node in the system. IMO, if nbits=4, 0x0 or 0x10, 0xFF..F0 should not a subset of anything, so following patch may fix this problem: From: Yisheng Xie <xieyishe...@huawei.com> Date: Tue, 17 Oct 2017 20:53:55 +0800 Sub

Re: [bug report & help] arm64: ltp testcase "migrate_pages01" failed

roduce at certain config on X86-64 e.g. CONFIG_NODES_SHIFT=3 and have 8 node in the system. IMO, if nbits=4, 0x0 or 0x10, 0xFF..F0 should not a subset of anything, so following patch may fix this problem: From: Yisheng Xie Date: Tue, 17 Oct 2017 20:53:55 +0800 Subject: [PATCH] bitmap: f

[PATCH v2] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

0b0 0b1 after apply this patch. Signed-off-by: Yisheng Xie <xieyishe...@huawei.com> --- v2: * Keep the feature bits backward compatible and add new one at the end * Avoid ILLEGAL of CD.S - both as Jean's suggestion. drivers/iommu/arm-smmu-v3.c | 15 --- 1 file changed,

[PATCH v2] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

0b0 0b1 after apply this patch. Signed-off-by: Yisheng Xie --- v2: * Keep the feature bits backward compatible and add new one at the end * Avoid ILLEGAL of CD.S - both as Jean's suggestion. drivers/iommu/arm-smmu-v3.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(

Re: [PATCH] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD

Hi Jean-Philippe, Thanks for reviewing. On 2017/9/19 19:43, Jean-Philippe Brucker wrote: > On 14/09/17 06:08, Yisheng Xie wrote: >> According to Spec, it is ILLEGAL to set STE.S1STALLD if STALL_MODEL >> is not 0b00, which means we should not disable stall mode if stall >&

Re: [PATCH] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD

Hi Jean-Philippe, Thanks for reviewing. On 2017/9/19 19:43, Jean-Philippe Brucker wrote: > On 14/09/17 06:08, Yisheng Xie wrote: >> According to Spec, it is ILLEGAL to set STE.S1STALLD if STALL_MODEL >> is not 0b00, which means we should not disable stall mode if stall >&

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

Hi Tycho, On 2017/9/13 2:13, Tycho Andersen wrote: > Hi Yisheng, > >> On Tue, Sep 12, 2017 at 04:05:22PM +0800, Yisheng Xie wrote: >>> IMO, before a page is allocated, it is in buddy system, which means it is >>> free >>> and no other 'map' on the p

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

Hi Tycho, On 2017/9/13 2:13, Tycho Andersen wrote: > Hi Yisheng, > >> On Tue, Sep 12, 2017 at 04:05:22PM +0800, Yisheng Xie wrote: >>> IMO, before a page is allocated, it is in buddy system, which means it is >>> free >>> and no other 'map' on the p

[PATCH] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD

0b1 0b01 !ARM_SMMU_FEAT_STALLS && !ARM_SMMU_FEAT_STALL_FORCE 0b0 0b10 ARM_SMMU_FEAT_STALLS && ARM_SMMU_FEAT_STALL_FORCE0b0 Signed-off-by: Yisheng Xie <xieyishe...@huawei.com> --- drivers/iommu/arm-smmu-v3.c | 11 +++ 1 file chang

[PATCH] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD

0b1 0b01 !ARM_SMMU_FEAT_STALLS && !ARM_SMMU_FEAT_STALL_FORCE 0b0 0b10 ARM_SMMU_FEAT_STALLS && ARM_SMMU_FEAT_STALL_FORCE0b0 Signed-off-by: Yisheng Xie --- drivers/iommu/arm-smmu-v3.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletion

Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

Hi Will, On 2017/9/13 11:06, Will Deacon wrote: > On Tue, Sep 05, 2017 at 01:54:19PM +0100, Jean-Philippe Brucker wrote: >> On 31/08/17 09:20, Yisheng Xie wrote: >>> It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which >>> means we should not disable st

Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

Hi Will, On 2017/9/13 11:06, Will Deacon wrote: > On Tue, Sep 05, 2017 at 01:54:19PM +0100, Jean-Philippe Brucker wrote: >> On 31/08/17 09:20, Yisheng Xie wrote: >>> It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which >>> means we should not disable st

Re: [PATCH v6 00/11] Add support for eXclusive Page Frame Ownership

On 2017/9/12 15:40, Juerg Haefliger wrote: > > > On 09/12/2017 09:07 AM, Yisheng Xie wrote: >> Hi Tycho, >> >> On 2017/9/11 23:02, Tycho Andersen wrote: >>> Hi Yisheng, >>> >>> On Mon, Sep 11, 2017 at 06:34:45PM +0800, Yisheng Xie wr

Re: [PATCH v6 00/11] Add support for eXclusive Page Frame Ownership

On 2017/9/12 15:40, Juerg Haefliger wrote: > > > On 09/12/2017 09:07 AM, Yisheng Xie wrote: >> Hi Tycho, >> >> On 2017/9/11 23:02, Tycho Andersen wrote: >>> Hi Yisheng, >>> >>> On Mon, Sep 11, 2017 at 06:34:45PM +0800, Yisheng Xie wr

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On 2017/9/12 0:03, Juerg Haefliger wrote: > > > On 09/11/2017 04:50 PM, Tycho Andersen wrote: >> Hi Yisheng, >> >> On Mon, Sep 11, 2017 at 03:24:09PM +0800, Yisheng Xie wrote: >>>> +void xpfo_alloc_pages(struct page *page, int order, gfp_t gf

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On 2017/9/12 0:03, Juerg Haefliger wrote: > > > On 09/11/2017 04:50 PM, Tycho Andersen wrote: >> Hi Yisheng, >> >> On Mon, Sep 11, 2017 at 03:24:09PM +0800, Yisheng Xie wrote: >>>> +void xpfo_alloc_pages(struct page *page, int order, gfp_t gf

Re: [PATCH v6 00/11] Add support for eXclusive Page Frame Ownership

Hi Tycho, On 2017/9/11 23:02, Tycho Andersen wrote: > Hi Yisheng, > > On Mon, Sep 11, 2017 at 06:34:45PM +0800, Yisheng Xie wrote: >> Hi Tycho , >> >> On 2017/9/8 1:35, Tycho Andersen wrote: >>> Hi all, >>> >>> Here is v6 of the XPFO set; se

Re: [PATCH v6 00/11] Add support for eXclusive Page Frame Ownership

Hi Tycho, On 2017/9/11 23:02, Tycho Andersen wrote: > Hi Yisheng, > > On Mon, Sep 11, 2017 at 06:34:45PM +0800, Yisheng Xie wrote: >> Hi Tycho , >> >> On 2017/9/8 1:35, Tycho Andersen wrote: >>> Hi all, >>> >>> Here is v6 of the XPFO set; se

Re: [PATCH v6 00/11] Add support for eXclusive Page Frame Ownership

of Vasileios P. Kemerlis et al, the mainline kernel will not set the Pro. of physmap(direct map area) to RW(X), so do we really need XPFO to protect from ret2dir attack? Thanks Yisheng xie > > Cheers, > > Tycho > > Juerg Haefliger (6): > mm, x86: Add suppo

Re: [PATCH v6 00/11] Add support for eXclusive Page Frame Ownership

of Vasileios P. Kemerlis et al, the mainline kernel will not set the Pro. of physmap(direct map area) to RW(X), so do we really need XPFO to protect from ret2dir attack? Thanks Yisheng xie > > Cheers, > > Tycho > > Juerg Haefliger (6): > mm, x86: Add suppo

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

nd_set_bit(XPFO_PAGE_USER, >flags)) > + flush_tlb = 1; I'm not sure whether I am miss anything, however, when the page was previously allocated to kernel, should we unmap the physmap (the kernel's page table) here? For we allocate the page to user now Yisheng Xie Thanks

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

) > + flush_tlb = 1; I'm not sure whether I am miss anything, however, when the page was previously allocated to kernel, should we unmap the physmap (the kernel's page table) here? For we allocate the page to user now Yisheng Xie Thanks

Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

Hi Jean-Philippe, On 2017/9/5 20:54, Jean-Philippe Brucker wrote: > On 31/08/17 09:20, Yisheng Xie wrote: >> It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which >> means we should not disable stall mode if stall/terminate mode is not >> configuable. >&g

Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

Hi Jean-Philippe, On 2017/9/5 20:54, Jean-Philippe Brucker wrote: > On 31/08/17 09:20, Yisheng Xie wrote: >> It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which >> means we should not disable stall mode if stall/terminate mode is not >> configuable. >&g

Re: [RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform devices

Hi Jean-Philippe, On 2017/9/6 8:51, Bob Liu wrote: > On 2017/9/5 20:53, Jean-Philippe Brucker wrote: >> On 31/08/17 09:20, Yisheng Xie wrote: >>> From: Jean-Philippe Brucker <jean-philippe.bruc...@arm.com> >>> >>> Platform device can re

Re: [RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform devices

Hi Jean-Philippe, On 2017/9/6 8:51, Bob Liu wrote: > On 2017/9/5 20:53, Jean-Philippe Brucker wrote: >> On 31/08/17 09:20, Yisheng Xie wrote: >>> From: Jean-Philippe Brucker >>> >>> Platform device can realise SVM function by using the stall mode. That >&g

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

Hi Jean-Philippe, On 2017/9/5 20:56, Jean-Philippe Brucker wrote: > On 31/08/17 09:20, Yisheng Xie wrote: >> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3: >> https://www.spinics.net/lists/arm-kernel/msg565155.html >> >> But for some p

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

Hi Jean-Philippe, On 2017/9/5 20:56, Jean-Philippe Brucker wrote: > On 31/08/17 09:20, Yisheng Xie wrote: >> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3: >> https://www.spinics.net/lists/arm-kernel/msg565155.html >> >> But for some p

[RFC PATCH 2/6] iommu/of: Add stall and pasid properties to iommu_fwspec

From: Jean-Philippe Brucker Add stall and pasid properties to iommu_fwspec. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/of_iommu.c | 11 +++ include/linux/iommu.h| 2 ++ 2 files changed, 12 insertions(+)

[RFC PATCH 2/6] iommu/of: Add stall and pasid properties to iommu_fwspec

From: Jean-Philippe Brucker Add stall and pasid properties to iommu_fwspec. Signed-off-by: Jean-Philippe Brucker --- drivers/iommu/of_iommu.c | 11 +++ include/linux/iommu.h| 2 ++ 2 files changed, 12 insertions(+) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c

[RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform devices

From: Jean-Philippe Brucker Platform device can realise SVM function by using the stall mode. That is to say, when device access a memory via iova which is not populated, it will stalled and when SMMU try to translate this iova, it also will stall and meanwhile

[RFC PATCH 5/6] iommu/arm-smmu-v3: fix panic when handle stall mode irq

in arm_smmu_bind_task() when smmu do not support the feature of SVM. Signed-off-by: Yisheng Xie <xieyishe...@huawei.com> --- drivers/iommu/arm-smmu-v3.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c index d44256a..dbda2eb

[RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform devices

From: Jean-Philippe Brucker Platform device can realise SVM function by using the stall mode. That is to say, when device access a memory via iova which is not populated, it will stalled and when SMMU try to translate this iova, it also will stall and meanwhile send an event to CPU via MSI.

[RFC PATCH 5/6] iommu/arm-smmu-v3: fix panic when handle stall mode irq

in arm_smmu_bind_task() when smmu do not support the feature of SVM. Signed-off-by: Yisheng Xie --- drivers/iommu/arm-smmu-v3.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c index d44256a..dbda2eb 100644 --- a/drivers/iommu/arm-smmu-v3.c

[RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

properties to iommu_fwspec iommu/arm-smmu-v3: Add SVM support for platform devices Yisheng Xie (3): ACPI: IORT: Add stall and pasid properties to iommu_fwspec iommu/arm-smmu-v3: fix panic when handle stall mode irq iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

[RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

properties to iommu_fwspec iommu/arm-smmu-v3: Add SVM support for platform devices Yisheng Xie (3): ACPI: IORT: Add stall and pasid properties to iommu_fwspec iommu/arm-smmu-v3: fix panic when handle stall mode irq iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

[RFC PATCH 1/6] dt-bindings: document stall and PASID properties for IOMMU masters

From: Jean-Philippe Brucker Document the bindings for stall and PASID capable platform devices. Signed-off-by: Jean-Philippe Brucker --- Documentation/devicetree/bindings/iommu/iommu.txt | 13 + 1 file changed, 13

[RFC PATCH 1/6] dt-bindings: document stall and PASID properties for IOMMU masters

From: Jean-Philippe Brucker Document the bindings for stall and PASID capable platform devices. Signed-off-by: Jean-Philippe Brucker --- Documentation/devicetree/bindings/iommu/iommu.txt | 13 + 1 file changed, 13 insertions(+) diff --git

[RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

atch add ARM_SMMU_FEAT_TERMINATE feature bit for smmu, and use TERMINATE feature checking to ensue above ILLEGAL cases from happening. Signed-off-by: Yisheng Xie <xieyishe...@huawei.com> --- drivers/iommu/arm-smmu-v3.c | 22 -- 1 file changed, 16 insertions(+), 6 deletions(

[RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

atch add ARM_SMMU_FEAT_TERMINATE feature bit for smmu, and use TERMINATE feature checking to ensue above ILLEGAL cases from happening. Signed-off-by: Yisheng Xie --- drivers/iommu/arm-smmu-v3.c | 22 -- 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/drivers/iommu/

[RFC PATCH 3/6] ACPI: IORT: Add stall and pasid properties to iommu_fwspec

32 pasid bits. And this should be enough for platform device. Anyway, this is just a RFC. Signed-off-by: Yisheng Xie <xieyishe...@huawei.com> --- drivers/acpi/arm64/iort.c | 20 include/acpi/actbl2.h | 5 + 2 files changed, 25 insertions(+) diff --git a/driver

[RFC PATCH 3/6] ACPI: IORT: Add stall and pasid properties to iommu_fwspec

32 pasid bits. And this should be enough for platform device. Anyway, this is just a RFC. Signed-off-by: Yisheng Xie --- drivers/acpi/arm64/iort.c | 20 include/acpi/actbl2.h | 5 + 2 files changed, 25 insertions(+) diff --git a/drivers/acpi/arm64/iort.c b/drivers

Re: [PATCH -next] zram: fix compr_data_size stat

On 2017/8/14 17:34, Minchan Kim wrote: > On Mon, Aug 14, 2017 at 05:24:16PM +0800, Yisheng Xie wrote: >> Hi, Minchan >> >> Thanks for your comment! >> On 2017/8/14 16:08, Minchan Kim wrote: >>> Hi Yisheng, >>> >>> Thanks for the all fixup! &

Re: [PATCH -next] zram: fix compr_data_size stat

On 2017/8/14 17:34, Minchan Kim wrote: > On Mon, Aug 14, 2017 at 05:24:16PM +0800, Yisheng Xie wrote: >> Hi, Minchan >> >> Thanks for your comment! >> On 2017/8/14 16:08, Minchan Kim wrote: >>> Hi Yisheng, >>> >>> Thanks for the all fixup! &

[PATCH -next 2/2] zram: fix typo in comment

ZRAM_SAME means page consists the same element not the entirely zero page. Signed-off-by: Yisheng Xie <xieyishe...@huawei.com> --- drivers/block/zram/zram_drv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h

[PATCH -next 1/2] zram: fix compr_data_size stat

The compr_data_size is a stat for compressed size of pages stored, which should be updated when we compresse a page. Meanwhile fix a typo in comment: * read_from_bdev_async() return 1 to avoid call page_endio() in zram_rw_page() Signed-off-by: Yisheng Xie <xieyishe...@huawei.com> --- Hi M

[PATCH -next 2/2] zram: fix typo in comment

ZRAM_SAME means page consists the same element not the entirely zero page. Signed-off-by: Yisheng Xie --- drivers/block/zram/zram_drv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h index 5573dc2..31762db 100644

[PATCH -next 1/2] zram: fix compr_data_size stat

The compr_data_size is a stat for compressed size of pages stored, which should be updated when we compresse a page. Meanwhile fix a typo in comment: * read_from_bdev_async() return 1 to avoid call page_endio() in zram_rw_page() Signed-off-by: Yisheng Xie --- Hi Minchan, It this ok for you

Re: [PATCH -next] zram: fix compr_data_size stat

Hi, Minchan Thanks for your comment! On 2017/8/14 16:08, Minchan Kim wrote: > Hi Yisheng, > > Thanks for the all fixup! > A minor nitpick below: > > On Fri, Aug 11, 2017 at 09:10:32AM +0800, Yisheng Xie wrote: >> The compr_data_size is a stat for compressed size of pages

Re: [PATCH -next] zram: fix compr_data_size stat

Hi, Minchan Thanks for your comment! On 2017/8/14 16:08, Minchan Kim wrote: > Hi Yisheng, > > Thanks for the all fixup! > A minor nitpick below: > > On Fri, Aug 11, 2017 at 09:10:32AM +0800, Yisheng Xie wrote: >> The compr_data_size is a stat for compressed size of pages

Re: [PATCH -next] zram: fix compr_data_size stat

On 2017/8/11 10:07, Yisheng Xie wrote: > > > On 2017/8/11 9:38, Sergey Senozhatsky wrote: >> On (08/11/17 10:35), Sergey Senozhatsky wrote: >>> On (08/11/17 09:10), Yisheng Xie wrote: >>>> The compr_data_size is a stat for compressed size of pages stored, wh

Re: [PATCH -next] zram: fix compr_data_size stat

On 2017/8/11 10:07, Yisheng Xie wrote: > > > On 2017/8/11 9:38, Sergey Senozhatsky wrote: >> On (08/11/17 10:35), Sergey Senozhatsky wrote: >>> On (08/11/17 09:10), Yisheng Xie wrote: >>>> The compr_data_size is a stat for compressed size of pages stored, wh

Re: [PATCH -next] zram: fix compr_data_size stat

On 2017/8/11 9:38, Sergey Senozhatsky wrote: > On (08/11/17 10:35), Sergey Senozhatsky wrote: >> On (08/11/17 09:10), Yisheng Xie wrote: >>> The compr_data_size is a stat for compressed size of pages stored, which >>> should add comp_len when we compresse a page.

Re: [PATCH -next] zram: fix compr_data_size stat

On 2017/8/11 9:38, Sergey Senozhatsky wrote: > On (08/11/17 10:35), Sergey Senozhatsky wrote: >> On (08/11/17 09:10), Yisheng Xie wrote: >>> The compr_data_size is a stat for compressed size of pages stored, which >>> should add comp_len when we compresse a page.

[PATCH -next] zram: fix compr_data_size stat

() in zram_rw_page() Signed-off-by: Yisheng Xie <xieyishe...@huawei.com> --- drivers/block/zram/zram_drv.c | 3 ++- drivers/block/zram/zram_drv.h | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index e27daca..b2b75b1

[PATCH -next] zram: fix compr_data_size stat

() in zram_rw_page() Signed-off-by: Yisheng Xie --- drivers/block/zram/zram_drv.c | 3 ++- drivers/block/zram/zram_drv.h | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index e27daca..b2b75b1 100644 --- a/drivers/block/zram

Re: [PATCH v2] vmalloc: show more detail info in vmallocinfo for clarify

Hi Michael, Thanks for comment! On 2017/8/1 19:00, Michael Ellerman wrote: > Yisheng Xie <xieyishe...@huawei.com> writes: > >> When ioremap a 67112960 bytes vm_area with the vmallocinfo: >> [..] >> 0xec79b000-0xec7fa000 389120 ftl_add_mtd+0x4d0/0x754 pages=94 vma

Re: [PATCH v2] vmalloc: show more detail info in vmallocinfo for clarify

Hi Michael, Thanks for comment! On 2017/8/1 19:00, Michael Ellerman wrote: > Yisheng Xie writes: > >> When ioremap a 67112960 bytes vm_area with the vmallocinfo: >> [..] >> 0xec79b000-0xec7fa000 389120 ftl_add_mtd+0x4d0/0x754 pages=94 vmalloc >>

Re: [PATCH 00/15] HMM (Heterogeneous Memory Management) v24

Hi Jerome, On 2017/7/21 1:18, Jerome Glisse wrote: > On Wed, Jul 19, 2017 at 07:48:08PM +0800, Yisheng Xie wrote: >> Hi Jérôme >> >> On 2017/6/29 2:00, Jérôme Glisse wrote: >>> >>> Patchset is on top of git://git.cmpxchg.org/linux-mmotm.git so i >>&g

Re: [PATCH 00/15] HMM (Heterogeneous Memory Management) v24

Hi Jerome, On 2017/7/21 1:18, Jerome Glisse wrote: > On Wed, Jul 19, 2017 at 07:48:08PM +0800, Yisheng Xie wrote: >> Hi Jérôme >> >> On 2017/6/29 2:00, Jérôme Glisse wrote: >>> >>> Patchset is on top of git://git.cmpxchg.org/linux-mmotm.git so i >>&g

Re: [PATCH 00/15] HMM (Heterogeneous Memory Management) v24

an address of a process is migrated to device memory, it should call migrate_vma() to migrate a range of address back to CPU ? If it is so, I think it should somewhere call this function in this patchset, however, I do not find anywhere in this patchset call this function. Or am I miss anything? Thanks Yisheng Xie

Re: [PATCH 00/15] HMM (Heterogeneous Memory Management) v24

an address of a process is migrated to device memory, it should call migrate_vma() to migrate a range of address back to CPU ? If it is so, I think it should somewhere call this function in this patchset, however, I do not find anywhere in this patchset call this function. Or am I miss anything? Thanks Yisheng Xie

Re: What differences and relations between SVM, HSA, HMM and Unified Memory?

Hi Jérôme and Jean-Philippe , Get it, thanks for all of your detail explain. Thanks Yisheng Xie On 2017/7/17 22:27, Jerome Glisse wrote: > On Mon, Jul 17, 2017 at 07:57:23PM +0800, Yisheng Xie wrote: >> Hi Jean-Philippe， >> >> On 2017/6/12 19:37, Jean-Philippe Bru

Re: What differences and relations between SVM, HSA, HMM and Unified Memory?

Hi Jérôme and Jean-Philippe , Get it, thanks for all of your detail explain. Thanks Yisheng Xie On 2017/7/17 22:27, Jerome Glisse wrote: > On Mon, Jul 17, 2017 at 07:57:23PM +0800, Yisheng Xie wrote: >> Hi Jean-Philippe， >> >> On 2017/6/12 19:37, Jean-Philippe Bru

Re: What differences and relations between SVM, HSA, HMM and Unified Memory?

context, // an OpenCL context where this buffer is available CL_MEM_READ_WRITE | CL_MEM_SVM_FINE_GRAIN_BUFFER, size, // amount of memory to allocate (in bytes) 0 // alignment in bytes (0 means default) ); where this RAM come from， device RAM or host RAM? Thanks Yishen

Re: What differences and relations between SVM, HSA, HMM and Unified Memory?

context, // an OpenCL context where this buffer is available CL_MEM_READ_WRITE | CL_MEM_SVM_FINE_GRAIN_BUFFER, size, // amount of memory to allocate (in bytes) 0 // alignment in bytes (0 means default) ); where this RAM come from， device RAM or host RAM? Thanks Yishen

[RFC] memory corruption caused by efi driver?

ized = 0x0, state_in_sysfs = 0x1, state_add_uevent_sent = 0x0, state_remove_uevent_sent = 0x1, uevent_suppress = 0x0 }, scanning = 0x48, deleting = 0x59 } Any idea about it? Any comment is appreciative! Thanks Yisheng Xie detail log: -- [12476.033560] general protection fault: [#1] SMP

[RFC] memory corruption caused by efi driver?

ized = 0x0, state_in_sysfs = 0x1, state_add_uevent_sent = 0x0, state_remove_uevent_sent = 0x1, uevent_suppress = 0x0 }, scanning = 0x48, deleting = 0x59 } Any idea about it? Any comment is appreciative! Thanks Yisheng Xie detail log: -- [12476.033560] general protection fault: [#1] SMP

[PATCH] ARM/Kconfig: make VMSPLIT_3G_OPT depends on !ARM_LPAE

Linux... done, booting the kernel. For ARM_LPAE only support 3:1, 2:2, 1:3 split of TTBR1, which mention in: http://elinux.org/images/6/6a/Elce11_marinas.pdf - p16 So we should make VMSPLIT_3G_OPT depends on !ARM_LPAE to avoid trigger this bug. Signed-off-by: Yisheng Xie <xieyishe...@huawei.

[PATCH] ARM/Kconfig: make VMSPLIT_3G_OPT depends on !ARM_LPAE

Linux... done, booting the kernel. For ARM_LPAE only support 3:1, 2:2, 1:3 split of TTBR1, which mention in: http://elinux.org/images/6/6a/Elce11_marinas.pdf - p16 So we should make VMSPLIT_3G_OPT depends on !ARM_LPAE to avoid trigger this bug. Signed-off-by: Yisheng Xie --- arch/arm/Kconfig

Re: [PATCH] Revert "ARM: 8433/1: add a VMSPLIT_3G_OPT config option"

Hi Russell, Thanks for comment! On 2017/6/7 17:33, Russell King - ARM Linux wrote: > On Wed, Jun 07, 2017 at 04:59:32PM +0800, Yisheng Xie wrote: >> This reverts commit 63ce446c9b5787a94ed875bab20772e1a2b3092f. > > There's no real reason to revert this, thereby removing it from n

Re: [PATCH] Revert "ARM: 8433/1: add a VMSPLIT_3G_OPT config option"

Hi Russell, Thanks for comment! On 2017/6/7 17:33, Russell King - ARM Linux wrote: > On Wed, Jun 07, 2017 at 04:59:32PM +0800, Yisheng Xie wrote: >> This reverts commit 63ce446c9b5787a94ed875bab20772e1a2b3092f. > > There's no real reason to revert this, thereby removing it from n

[PATCH] Revert "ARM: 8433/1: add a VMSPLIT_3G_OPT config option"

with CONFIG_ARM_LPAE=y, which I reported: https://patchwork.kernel.org/patch/9768573/ For ARM_LPAE only support 3:1, 2:2, 1:3 split of TTBR1, which mention in: http://elinux.org/images/6/6a/Elce11_marinas.pdf - p16 Signed-off-by: Yisheng Xie <xieyishe...@huawei.com> --- arch/arm/Kconfi

[PATCH] Revert "ARM: 8433/1: add a VMSPLIT_3G_OPT config option"

with CONFIG_ARM_LPAE=y, which I reported: https://patchwork.kernel.org/patch/9768573/ For ARM_LPAE only support 3:1, 2:2, 1:3 split of TTBR1, which mention in: http://elinux.org/images/6/6a/Elce11_marinas.pdf - p16 Signed-off-by: Yisheng Xie --- arch/arm/Kconfig | 3 --- 1 file changed, 3 del

[BUG] boot fail with ARM_LPAE and VMSPLIT_3G_OPT

depends on !ARM_LPAE bool "3G/1G user/kernel split (for full 1G low memory)" config VMSPLIT_2G bool "2G/2G user/kernel split" Any comment is more than welcome! Thanks Yisheng Xie

[BUG] boot fail with ARM_LPAE and VMSPLIT_3G_OPT

depends on !ARM_LPAE bool "3G/1G user/kernel split (for full 1G low memory)" config VMSPLIT_2G bool "2G/2G user/kernel split" Any comment is more than welcome! Thanks Yisheng Xie

[PATCH v2] vmalloc: show more detail info in vmallocinfo for clarify

20480 vm_map_ram 0xf0099000-0xf00aa000 69632 vm_map_ram after apply this patch. Signed-off-by: Yisheng Xie <xieyishe...@huawei.com> --- v2: - changed "freeing vm_area" to "unpurged vm_area" to be clearer - Tim mm/vmalloc.c | 10 +- 1 file changed, 9 insertions(+), 1 d

[PATCH v2] vmalloc: show more detail info in vmallocinfo for clarify

20480 vm_map_ram 0xf0099000-0xf00aa000 69632 vm_map_ram after apply this patch. Signed-off-by: Yisheng Xie --- v2: - changed "freeing vm_area" to "unpurged vm_area" to be clearer - Tim mm/vmalloc.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/mm/vm

Re: [RFC PATCH] vmalloc: show more detail info in vmallocinfo for clarify

Hi Tim, Thanks for comment! On 2017/5/31 8:56, Tim Chen wrote: > On 05/19/2017 11:47 PM, Yisheng Xie wrote: >> When ioremap a 67112960 bytes vm_area with the vmallocinfo: >> [..] >> 0xec79b000-0xec7fa000 389120 ftl_add_mtd+0x4d0/0x754 pages=94 vmalloc >> 0x

Re: [RFC PATCH] vmalloc: show more detail info in vmallocinfo for clarify

Hi Tim, Thanks for comment! On 2017/5/31 8:56, Tim Chen wrote: > On 05/19/2017 11:47 PM, Yisheng Xie wrote: >> When ioremap a 67112960 bytes vm_area with the vmallocinfo: >> [..] >> 0xec79b000-0xec7fa000 389120 ftl_add_mtd+0x4d0/0x754 pages=94 vmalloc >> 0x

[PATCH v3] mlock: fix mlock count can not decrease in race condition

Cc: Xishi Qiu <qiuxi...@huawei.com> CC: zhongjiang <zhongji...@huawei.com> Cc: Hanjun Guo <guohan...@huawei.com> Cc: <sta...@vger.kernel.org> --- v2: - use delta_munlocked for it doesn't do the increment in fastpath - Vlastimil v3: - change the changelog to make it mor

[PATCH v3] mlock: fix mlock count can not decrease in race condition

Cc: Xishi Qiu CC: zhongjiang Cc: Hanjun Guo Cc: --- v2: - use delta_munlocked for it doesn't do the increment in fastpath - Vlastimil v3: - change the changelog to make it more clear - Vlastimil Hi Andrew: Could you please help to fold this? Thanks Yisheng Xie mm/mlock.c | 5 +++-- 1 file ch

Re: [PATCH v2] mlock: fix mlock count can not decrease in race condition

Hi Vlastimil, Thanks for comment! On 2017/5/25 14:32, Vlastimil Babka wrote: > On 05/25/2017 04:13 AM, Yisheng Xie wrote: >> Kefeng reported that when run the follow test the mlock count > >> in meminfo >> cannot be decreased: > > "increases permanently."

Re: [PATCH v2] mlock: fix mlock count can not decrease in race condition

Hi Vlastimil, Thanks for comment! On 2017/5/25 14:32, Vlastimil Babka wrote: > On 05/25/2017 04:13 AM, Yisheng Xie wrote: >> Kefeng reported that when run the follow test the mlock count > >> in meminfo >> cannot be decreased: > > "increases permanently."

[PATCH v2] mlock: fix mlock count can not decrease in race condition

cleared. Fixes: 1ebb7cc6a583 (" mm: munlock: batch NR_MLOCK zone state updates") Signed-off-by: Yisheng Xie <xieyishe...@huawei.com> Reported-by: Kefeng Wang <wangkefeng.w...@huawei.com> Tested-by: Kefeng Wang <wangkefeng.w...@huawei.com> Cc: Vlastimil Babka <vba...@su

<    1   2   3   4   5   6   7   8   9   >