Re: [PATCH v11 19/26] mm: provide speculative fault infrastructure

On 2018/7/25 18:44, Laurent Dufour wrote: > > On 25/07/2018 11:04, zhong jiang wrote: >> On 2018/7/25 0:10, Laurent Dufour wrote: >>> On 24/07/2018 16:26, zhong jiang wrote: >>>> On 2018/5/17 19:06, Laurent Dufour wrote: >>>>> From: Peter Zi

Re: [PATCH v11 19/26] mm: provide speculative fault infrastructure

On 2018/7/25 0:10, Laurent Dufour wrote: > > On 24/07/2018 16:26, zhong jiang wrote: >> On 2018/5/17 19:06, Laurent Dufour wrote: >>> From: Peter Zijlstra >>> >>> Provide infrastructure to do a speculative fault (not holding >>> mmap_sem). >&

Re: [PATCH v11 19/26] mm: provide speculative fault infrastructure

On 2018/7/25 0:10, Laurent Dufour wrote: > > On 24/07/2018 16:26, zhong jiang wrote: >> On 2018/5/17 19:06, Laurent Dufour wrote: >>> From: Peter Zijlstra >>> >>> Provide infrastructure to do a speculative fault (not holding >>> mmap_sem). >&

[tip:x86/mm] x86/mm/tlb: Make clear_asid_other() static

Commit-ID: 387048f51aecaa083e660fe0f15ad339354b116e Gitweb: https://git.kernel.org/tip/387048f51aecaa083e660fe0f15ad339354b116e Author: zhong jiang AuthorDate: Sat, 21 Jul 2018 15:55:32 +0800 Committer: Ingo Molnar CommitDate: Tue, 24 Jul 2018 09:52:32 +0200 x86/mm/tlb: Make

[tip:x86/mm] x86/mm/tlb: Make clear_asid_other() static

Commit-ID: 387048f51aecaa083e660fe0f15ad339354b116e Gitweb: https://git.kernel.org/tip/387048f51aecaa083e660fe0f15ad339354b116e Author: zhong jiang AuthorDate: Sat, 21 Jul 2018 15:55:32 +0800 Committer: Ingo Molnar CommitDate: Tue, 24 Jul 2018 09:52:32 +0200 x86/mm/tlb: Make

[PATCH linux-next] gpio: fix meaningless return expression

Fix the following sparse error: drivers/gpio/gpio-ath79.c:54:16: error: return expression in void function Signed-off-by: zhong jiang --- drivers/gpio/gpio-ath79.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-ath79.c b/drivers/gpio/gpio-ath79.c index

[PATCH linux-next] gpio: fix meaningless return expression

Fix the following sparse error: drivers/gpio/gpio-ath79.c:54:16: error: return expression in void function Signed-off-by: zhong jiang --- drivers/gpio/gpio-ath79.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-ath79.c b/drivers/gpio/gpio-ath79.c index

[PATCH linux-next] driver/gpu: Fix mismatch in funciton argument type

Fix the following warning: drivers/gpu/drm/nouveau/dispnv50/wndw.c:570:1: error: symbol 'nv50_wndw_new_' redeclared with different type (originally declared at drivers/gpu/drm/nouveau/dispnv50/wndw.h:39) - incompatible argument 7 (different signedness) Signed-off-by: zhong jiang --- drivers

[PATCH linux-next] driver/gpu: Fix mismatch in funciton argument type

Fix the following warning: drivers/gpu/drm/nouveau/dispnv50/wndw.c:570:1: error: symbol 'nv50_wndw_new_' redeclared with different type (originally declared at drivers/gpu/drm/nouveau/dispnv50/wndw.h:39) - incompatible argument 7 (different signedness) Signed-off-by: zhong jiang --- drivers

[PATCH linux-next] kernel/exit: fix mismatch in function argument types

Fix following warning: kernel/exit.c:1634:6: error: symbol 'kernel_wait4' redeclared with different type (originally declared at ./include/linux/sched/task.h:78) - incompatible argument 2 (different address spaces) Signed-off-by: zhong jiang --- include/linux/sched/task.h | 2 +- 1 file

[PATCH linux-next] kernel/exit: fix mismatch in function argument types

Fix following warning: kernel/exit.c:1634:6: error: symbol 'kernel_wait4' redeclared with different type (originally declared at ./include/linux/sched/task.h:78) - incompatible argument 2 (different address spaces) Signed-off-by: zhong jiang --- include/linux/sched/task.h | 2 +- 1 file

[PATCH linux-next] x86: should use NULL pointer to replace plain integer

Fixes the following sparse warnings: arch/x86/kernel/pci-iommu_table.c:63:37: warning: Using plain integer as NULL pointer Signed-off-by: zhong jiang --- arch/x86/kernel/pci-iommu_table.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/pci-iommu_table.c b

[PATCH linux-next] x86: should use NULL pointer to replace plain integer

Fixes the following sparse warnings: arch/x86/kernel/pci-iommu_table.c:63:37: warning: Using plain integer as NULL pointer Signed-off-by: zhong jiang --- arch/x86/kernel/pci-iommu_table.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/pci-iommu_table.c b

[PATCH linux-next] mm/tlb: make some function static to avoid warning

Fixes the following sparse warnings: arch/x86/mm/tlb.c:38:6: warning: symbol 'clear_asid_other' was not declared. Should it be static? Signed-off-by: zhong jiang --- arch/x86/mm/tlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c

[PATCH linux-next] mm/tlb: make some function static to avoid warning

Fixes the following sparse warnings: arch/x86/mm/tlb.c:38:6: warning: symbol 'clear_asid_other' was not declared. Should it be static? Signed-off-by: zhong jiang --- arch/x86/mm/tlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c

Re: [RESEND] x86/numa: move setting parsed numa node to num_add_memblk

On 2017/12/11 21:45, Michal Hocko wrote: > On Mon 11-12-17 20:59:29, zhong jiang wrote: >> On 2017/12/11 20:03, Michal Hocko wrote: >>> On Fri 01-12-17 18:13:52, zhong jiang wrote: >>>> The acpi table are very much like user input. it is likely to >>>>

Re: [RESEND] x86/numa: move setting parsed numa node to num_add_memblk

On 2017/12/11 21:45, Michal Hocko wrote: > On Mon 11-12-17 20:59:29, zhong jiang wrote: >> On 2017/12/11 20:03, Michal Hocko wrote: >>> On Fri 01-12-17 18:13:52, zhong jiang wrote: >>>> The acpi table are very much like user input. it is likely to >>>>

Re: [RESEND] x86/numa: move setting parsed numa node to num_add_memblk

On 2017/12/11 20:03, Michal Hocko wrote: > On Fri 01-12-17 18:13:52, zhong jiang wrote: >> The acpi table are very much like user input. it is likely to >> introduce some unreasonable node in some architecture. but >> they do not ingore the node and bail out in

Re: [RESEND] x86/numa: move setting parsed numa node to num_add_memblk

On 2017/12/11 20:03, Michal Hocko wrote: > On Fri 01-12-17 18:13:52, zhong jiang wrote: >> The acpi table are very much like user input. it is likely to >> introduce some unreasonable node in some architecture. but >> they do not ingore the node and bail out in

[RESEND] x86/numa: move setting parsed numa node to num_add_memblk

emblk node. Signed-off-by: zhong jiang <zhongji...@huawei.com> --- arch/x86/mm/amdtopology.c | 1 - arch/x86/mm/numa.c| 3 ++- drivers/acpi/numa.c | 5 - 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/x86/mm/amdtopology.c b/arch/x86/mm/amdtopology

[RESEND] x86/numa: move setting parsed numa node to num_add_memblk

emblk node. Signed-off-by: zhong jiang --- arch/x86/mm/amdtopology.c | 1 - arch/x86/mm/numa.c| 3 ++- drivers/acpi/numa.c | 5 - 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/x86/mm/amdtopology.c b/arch/x86/mm/amdtopology.c index 91f501b..7657042 100644 ---

Re: [PATCH] x86/numa: move setting parse numa node to num_add_memblk

On 2017/12/1 16:58, Michal Hocko wrote: > On Fri 01-12-17 16:48:25, zhong jiang wrote: >> +cc more mm maintainer. >> >> Any one has any object. please let me know. > Please repost with the changelog which actually tells 1) what is the > problem 2) why do we need to

Re: [PATCH] x86/numa: move setting parse numa node to num_add_memblk

On 2017/12/1 16:58, Michal Hocko wrote: > On Fri 01-12-17 16:48:25, zhong jiang wrote: >> +cc more mm maintainer. >> >> Any one has any object. please let me know. > Please repost with the changelog which actually tells 1) what is the > problem 2) why do we need to

Re: [PATCH] x86/numa: move setting parse numa node to num_add_memblk

+cc more mm maintainer. Any one has any object. please let me know. Thanks zhongjiang On 2017/11/29 17:13, zhong jiang wrote: > Currently, Arm64 and x86 use the common code wehn parsing numa node > in a acpi way. The arm64 will set the parsed node in numa_add_memblk, > but the x86 i

Re: [PATCH] x86/numa: move setting parse numa node to num_add_memblk

+cc more mm maintainer. Any one has any object. please let me know. Thanks zhongjiang On 2017/11/29 17:13, zhong jiang wrote: > Currently, Arm64 and x86 use the common code wehn parsing numa node > in a acpi way. The arm64 will set the parsed node in numa_add_memblk, > but the x86 i

Re: [PATCH] x86/numa: move setting parse numa node to num_add_memblk

On 2017/11/29 22:14, Dou Liyang wrote: > Hi Jiang, > > At 11/29/2017 09:44 PM, zhong jiang wrote: >> On 2017/11/29 21:33, Michal Hocko wrote: >>> On Wed 29-11-17 21:26:19, zhong jiang wrote: >>>> On 2017/11/29 21:01, Michal Hocko wrote: >>>&

Re: [PATCH] x86/numa: move setting parse numa node to num_add_memblk

On 2017/11/29 22:14, Dou Liyang wrote: > Hi Jiang, > > At 11/29/2017 09:44 PM, zhong jiang wrote: >> On 2017/11/29 21:33, Michal Hocko wrote: >>> On Wed 29-11-17 21:26:19, zhong jiang wrote: >>>> On 2017/11/29 21:01, Michal Hocko wrote: >>>&

Re: [PATCH] x86/numa: move setting parse numa node to num_add_memblk

On 2017/11/29 21:33, Michal Hocko wrote: > On Wed 29-11-17 21:26:19, zhong jiang wrote: >> On 2017/11/29 21:01, Michal Hocko wrote: >>> On Wed 29-11-17 20:41:25, zhong jiang wrote: >>>> On 2017/11/29 20:03, Michal Hocko wrote: >>>>> On Wed 29-11-17

Re: [PATCH] x86/numa: move setting parse numa node to num_add_memblk

On 2017/11/29 21:33, Michal Hocko wrote: > On Wed 29-11-17 21:26:19, zhong jiang wrote: >> On 2017/11/29 21:01, Michal Hocko wrote: >>> On Wed 29-11-17 20:41:25, zhong jiang wrote: >>>> On 2017/11/29 20:03, Michal Hocko wrote: >>>>> On Wed 29-11-17

Re: [PATCH] x86/numa: move setting parse numa node to num_add_memblk

On 2017/11/29 21:01, Michal Hocko wrote: > On Wed 29-11-17 20:41:25, zhong jiang wrote: >> On 2017/11/29 20:03, Michal Hocko wrote: >>> On Wed 29-11-17 17:13:27, zhong jiang wrote: >>>> Currently, Arm64 and x86 use the common code wehn parsing numa node >>

Re: [PATCH] x86/numa: move setting parse numa node to num_add_memblk

On 2017/11/29 21:01, Michal Hocko wrote: > On Wed 29-11-17 20:41:25, zhong jiang wrote: >> On 2017/11/29 20:03, Michal Hocko wrote: >>> On Wed 29-11-17 17:13:27, zhong jiang wrote: >>>> Currently, Arm64 and x86 use the common code wehn parsing numa node >>

Re: [PATCH] x86/numa: move setting parse numa node to num_add_memblk

On 2017/11/29 20:03, Michal Hocko wrote: > On Wed 29-11-17 17:13:27, zhong jiang wrote: >> Currently, Arm64 and x86 use the common code wehn parsing numa node >> in a acpi way. The arm64 will set the parsed node in numa_add_memblk, >> but the x86 is not set in that

Re: [PATCH] x86/numa: move setting parse numa node to num_add_memblk

On 2017/11/29 20:03, Michal Hocko wrote: > On Wed 29-11-17 17:13:27, zhong jiang wrote: >> Currently, Arm64 and x86 use the common code wehn parsing numa node >> in a acpi way. The arm64 will set the parsed node in numa_add_memblk, >> but the x86 is not set in that

[PATCH] x86/numa: move setting parse numa node to num_add_memblk

it although it also still works. because the parsed node is unresonable. so we should skip related operate in this node. This patch just set node in various architecture individually. it is no functional change. Signed-off-by: zhong jiang <zhongji...@huawei.com> --- arch/x86/mm/amdtopology

[PATCH] x86/numa: move setting parse numa node to num_add_memblk

it although it also still works. because the parsed node is unresonable. so we should skip related operate in this node. This patch just set node in various architecture individually. it is no functional change. Signed-off-by: zhong jiang --- arch/x86/mm/amdtopology.c | 1 - arch/x86/mm/numa.c

Re: [PATCH v2 4/5] mm: memory_hotplug: Add memory hotremove probe device

t; On Fri 24 Nov 2017, 18:35, zhong jiang wrote: >> HI, Andrea >> >> I don't see "memory_add_physaddr_to_nid" in arch/arm64. >> Am I miss something? > When !CONFIG_NUMA it is defined in include/linux/memory_hotplug.h as 0. > In patch 1/5 of this series we req

Re: [PATCH v2 4/5] mm: memory_hotplug: Add memory hotremove probe device

t; On Fri 24 Nov 2017, 18:35, zhong jiang wrote: >> HI, Andrea >> >> I don't see "memory_add_physaddr_to_nid" in arch/arm64. >> Am I miss something? > When !CONFIG_NUMA it is defined in include/linux/memory_hotplug.h as 0. > In patch 1/5 of this series we req

Re: [PATCH v2 4/5] mm: memory_hotplug: Add memory hotremove probe device

HI, Andrea I don't see "memory_add_physaddr_to_nid" in arch/arm64. Am I miss something? Thnaks zhongjiang On 2017/11/23 19:14, Andrea Reale wrote: > Adding a "remove" sysfs handle that can be used to trigger > memory hotremove manually, exactly simmetrically with > what happens with the "probe"

Re: [PATCH v2 4/5] mm: memory_hotplug: Add memory hotremove probe device

HI, Andrea I don't see "memory_add_physaddr_to_nid" in arch/arm64. Am I miss something? Thnaks zhongjiang On 2017/11/23 19:14, Andrea Reale wrote: > Adding a "remove" sysfs handle that can be used to trigger > memory hotremove manually, exactly simmetrically with > what happens with the "probe"

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

On 2017/8/26 5:13, Thomas Gleixner wrote: > On Fri, 25 Aug 2017, zhong jiang wrote: >> From: zhong jiang <zhongji...@huawei.com> >> Date: Fri, 25 Aug 2017 12:05:56 +0800 >> Subject: [PATCH v2] futex: avoid undefined behaviour when shift exponent is >> negative >

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

On 2017/8/26 5:13, Thomas Gleixner wrote: > On Fri, 25 Aug 2017, zhong jiang wrote: >> From: zhong jiang >> Date: Fri, 25 Aug 2017 12:05:56 +0800 >> Subject: [PATCH v2] futex: avoid undefined behaviour when shift exponent is >> negative > Please do not send patche

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

On 2017/6/29 6:13, Thomas Gleixner wrote: > On Wed, 28 Jun 2017, zhong jiang wrote: >> On 2017/6/22 0:40, Ingo Molnar wrote: >>> * zhong jiang <zhongji...@huawei.com> wrote: >>> >>>> when shift expoment is negative, left shift alway zero. therefore, w

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

On 2017/6/29 6:13, Thomas Gleixner wrote: > On Wed, 28 Jun 2017, zhong jiang wrote: >> On 2017/6/22 0:40, Ingo Molnar wrote: >>> * zhong jiang wrote: >>> >>>> when shift expoment is negative, left shift alway zero. therefore, we >>>> modify th

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

On 2017/6/29 14:33, Thomas Gleixner wrote: > On Thu, 29 Jun 2017, zhong jiang wrote: >> On 2017/6/29 6:13, Thomas Gleixner wrote: >>> That's simply wrong. If oparg is negative and the SHIFT bit is set then the >>> result is undefined today and there is no way that

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

On 2017/6/29 14:33, Thomas Gleixner wrote: > On Thu, 29 Jun 2017, zhong jiang wrote: >> On 2017/6/29 6:13, Thomas Gleixner wrote: >>> That's simply wrong. If oparg is negative and the SHIFT bit is set then the >>> result is undefined today and there is no way that

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

On 2017/6/29 12:29, h...@zytor.com wrote: > On June 28, 2017 7:12:04 PM PDT, zhong jiang <zhongji...@huawei.com> wrote: >> On 2017/6/29 5:43, h...@zytor.com wrote: >>> On June 27, 2017 9:35:10 PM PDT, zhong jiang <zhongji...@huawei.com> >> wrote: >>>&g

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

On 2017/6/29 12:29, h...@zytor.com wrote: > On June 28, 2017 7:12:04 PM PDT, zhong jiang wrote: >> On 2017/6/29 5:43, h...@zytor.com wrote: >>> On June 27, 2017 9:35:10 PM PDT, zhong jiang >> wrote: >>>> Hi, Ingo >>>> >>>> Thank yo

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

On 2017/6/29 5:43, h...@zytor.com wrote: > On June 27, 2017 9:35:10 PM PDT, zhong jiang <zhongji...@huawei.com> wrote: >> Hi, Ingo >> >> Thank you for the comment. >> On 2017/6/22 0:40, Ingo Molnar wrote: >>> * zhong jiang <zhongji...@huawei.com>

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

On 2017/6/29 5:43, h...@zytor.com wrote: > On June 27, 2017 9:35:10 PM PDT, zhong jiang wrote: >> Hi, Ingo >> >> Thank you for the comment. >> On 2017/6/22 0:40, Ingo Molnar wrote: >>> * zhong jiang wrote: >>> >>>> when shift expo

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

Hi, Thomas Thank you for clarification. On 2017/6/29 6:13, Thomas Gleixner wrote: > On Wed, 28 Jun 2017, zhong jiang wrote: >> On 2017/6/22 0:40, Ingo Molnar wrote: >>> * zhong jiang <zhongji...@huawei.com> wrote: >>> >>>> when shift expoment is n

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

Hi, Thomas Thank you for clarification. On 2017/6/29 6:13, Thomas Gleixner wrote: > On Wed, 28 Jun 2017, zhong jiang wrote: >> On 2017/6/22 0:40, Ingo Molnar wrote: >>> * zhong jiang wrote: >>> >>>> when shift expoment is negative, left shift alway ze

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

Hi, Ingo Thank you for the comment. On 2017/6/22 0:40, Ingo Molnar wrote: > * zhong jiang <zhongji...@huawei.com> wrote: > >> when shift expoment is negative, left shift alway zero. therefore, we >> modify the logic to avoid the warining. >> >> Signed-off-by

Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative

Hi, Ingo Thank you for the comment. On 2017/6/22 0:40, Ingo Molnar wrote: > * zhong jiang wrote: > >> when shift expoment is negative, left shift alway zero. therefore, we >> modify the logic to avoid the warining. >> >> Signed-off-by: zhong jiang >> ---

Re: [PATCH] x86/mm: Don't reenter flush_tlb_func_common()

On 2017/6/19 23:05, Andy Lutomirski wrote: > On Mon, Jun 19, 2017 at 6:33 AM, zhong jiang <zhongji...@huawei.com> wrote: >> On 2017/6/19 12:48, Andy Lutomirski wrote: >>> It was historically possible to have two concurrent TLB flushes >>> targeting the same C

Re: [PATCH] x86/mm: Don't reenter flush_tlb_func_common()

On 2017/6/19 23:05, Andy Lutomirski wrote: > On Mon, Jun 19, 2017 at 6:33 AM, zhong jiang wrote: >> On 2017/6/19 12:48, Andy Lutomirski wrote: >>> It was historically possible to have two concurrent TLB flushes >>> targeting the same CPU: one initiated locally and

Re: [PATCH] x86/mm: Don't reenter flush_tlb_func_common()

On 2017/6/19 12:48, Andy Lutomirski wrote: > It was historically possible to have two concurrent TLB flushes > targeting the same CPU: one initiated locally and one initiated > remotely. This can now cause an OOPS in leave_mm() at > arch/x86/mm/tlb.c:47: > > if

Re: [PATCH] x86/mm: Don't reenter flush_tlb_func_common()

On 2017/6/19 12:48, Andy Lutomirski wrote: > It was historically possible to have two concurrent TLB flushes > targeting the same CPU: one initiated locally and one initiated > remotely. This can now cause an OOPS in leave_mm() at > arch/x86/mm/tlb.c:47: > > if

Re: [HMM 07/15] mm/ZONE_DEVICE: new type of ZONE_DEVICE for unaddressable memory v3

On 2017/5/25 1:20, Jérôme Glisse wrote: > HMM (heterogeneous memory management) need struct page to support migration > from system main memory to device memory. Reasons for HMM and migration to > device memory is explained with HMM core patch. > > This patch deals with device memory that is

Re: [HMM 07/15] mm/ZONE_DEVICE: new type of ZONE_DEVICE for unaddressable memory v3

On 2017/5/25 1:20, Jérôme Glisse wrote: > HMM (heterogeneous memory management) need struct page to support migration > from system main memory to device memory. Reasons for HMM and migration to > device memory is explained with HMM core patch. > > This patch deals with device memory that is

Re: [PATCH] fs/fcntl: return -ESRCH in f_setown when pid/pgid can't be found

ssed in an argument of 0. For anything else, we want to > return ESRCH if it doesn't refer to a valid pid. > > The relevant POSIX spec page is here: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html > > Cc: Jiri Slaby <jsl...@suse.cz> > Cc: zho

Re: [PATCH] fs/fcntl: return -ESRCH in f_setown when pid/pgid can't be found

ssed in an argument of 0. For anything else, we want to > return ESRCH if it doesn't refer to a valid pid. > > The relevant POSIX spec page is here: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html > > Cc: Jiri Slaby > Cc: zhong jiang > S

Re: [PATCH v3 2/2] fs/fcntl: f_setown, avoid undefined behaviour

On 2017/6/13 20:13, Jeff Layton wrote: > On Tue, 2017-06-13 at 13:35 +0200, Jiri Slaby wrote: >> fcntl(0, F_SETOWN, 0x8000) triggers: >> UBSAN: Undefined behaviour in fs/fcntl.c:118:7 >> negation of -2147483648 cannot be represented in type 'int': >> CPU: 1 PID: 18261 Comm: syz-executor Not

Re: [PATCH v3 2/2] fs/fcntl: f_setown, avoid undefined behaviour

On 2017/6/13 20:13, Jeff Layton wrote: > On Tue, 2017-06-13 at 13:35 +0200, Jiri Slaby wrote: >> fcntl(0, F_SETOWN, 0x8000) triggers: >> UBSAN: Undefined behaviour in fs/fcntl.c:118:7 >> negation of -2147483648 cannot be represented in type 'int': >> CPU: 1 PID: 18261 Comm: syz-executor Not

[PATCH v2] exit: avoid undefined behaviour when call wait4

b/0x70 [518871.538598] [] SyS_wait4+0x1cb/0x1e0 [518871.543999] [] ? SyS_waitid+0x220/0x220 [518871.549661] [] ? __audit_syscall_entry+0x1f7/0x2a0 [518871.556278] [] system_call_fastpath+0x16/0x1b The patch by excluding the overflow to avoid the UBSAN warning. Signed-off-by: zhong jiang <zhongji...@h

[PATCH v2] exit: avoid undefined behaviour when call wait4

/0x1e0 [518871.543999] [] ? SyS_waitid+0x220/0x220 [518871.549661] [] ? __audit_syscall_entry+0x1f7/0x2a0 [518871.556278] [] system_call_fastpath+0x16/0x1b The patch by excluding the overflow to avoid the UBSAN warning. Signed-off-by: zhong jiang --- kernel/exit.c | 4 1 file changed, 4

Re: [PATCH v3 1/2] fs/fcntl: f_setown, allow returning error

On 2017/6/13 19:35, Jiri Slaby wrote: > Allow f_setown to return an error value. We will fail in the next patch > with EINVAL for bad input to f_setown, so tile the path for the later > patch. > > Signed-off-by: Jiri Slaby > Reviewed-by: Jeff Layton > Cc: Jeff

Re: [PATCH v3 1/2] fs/fcntl: f_setown, allow returning error

On 2017/6/13 19:35, Jiri Slaby wrote: > Allow f_setown to return an error value. We will fail in the next patch > with EINVAL for bad input to f_setown, so tile the path for the later > patch. > > Signed-off-by: Jiri Slaby > Reviewed-by: Jeff Layton > Cc: Jeff Layton > Cc: "J. Bruce Fields" >

Re: [PATCH] fs: fcntl, avoid undefined behaviour

On 2017/6/13 17:29, Jiri Slaby wrote: > On 06/12/2017, 07:03 AM, zhong jiang wrote: >> On 2016/10/14 17:23, Jiri Slaby wrote: >>> fcntl(0, F_SETOWN, 0x8000) triggers: >>> UBSAN: Undefined behaviour in fs/fcntl.c:118:7 >>> negation of -2147483648 cannot be r

Re: [PATCH] fs: fcntl, avoid undefined behaviour

On 2017/6/13 17:29, Jiri Slaby wrote: > On 06/12/2017, 07:03 AM, zhong jiang wrote: >> On 2016/10/14 17:23, Jiri Slaby wrote: >>> fcntl(0, F_SETOWN, 0x8000) triggers: >>> UBSAN: Undefined behaviour in fs/fcntl.c:118:7 >>> negation of -2147483648 cannot be r

Re: [PATCH] fs: fcntl, avoid undefined behaviour

On 2016/10/14 17:23, Jiri Slaby wrote: > fcntl(0, F_SETOWN, 0x8000) triggers: > UBSAN: Undefined behaviour in fs/fcntl.c:118:7 > negation of -2147483648 cannot be represented in type 'int': > CPU: 1 PID: 18261 Comm: syz-executor Not tainted 4.8.1-0-syzkaller #1 > ... > Call Trace: > ... > []

Re: [PATCH] fs: fcntl, avoid undefined behaviour

On 2016/10/14 17:23, Jiri Slaby wrote: > fcntl(0, F_SETOWN, 0x8000) triggers: > UBSAN: Undefined behaviour in fs/fcntl.c:118:7 > negation of -2147483648 cannot be represented in type 'int': > CPU: 1 PID: 18261 Comm: syz-executor Not tainted 4.8.1-0-syzkaller #1 > ... > Call Trace: > ... > []

Re: [PATCH 3/3] mm: migrate: Stabilise page count when migrating transparent hugepages

On 2017/6/8 20:07, Will Deacon wrote: > On Thu, Jun 08, 2017 at 12:52:07PM +0200, Vlastimil Babka wrote: >> On 06/06/2017 07:58 PM, Will Deacon wrote: >>> When migrating a transparent hugepage, migrate_misplaced_transhuge_page >>> guards itself against a concurrent fastgup of the page by checking

Re: [PATCH 3/3] mm: migrate: Stabilise page count when migrating transparent hugepages

On 2017/6/8 20:07, Will Deacon wrote: > On Thu, Jun 08, 2017 at 12:52:07PM +0200, Vlastimil Babka wrote: >> On 06/06/2017 07:58 PM, Will Deacon wrote: >>> When migrating a transparent hugepage, migrate_misplaced_transhuge_page >>> guards itself against a concurrent fastgup of the page by checking

Re: [PATCH 3/3] mm: migrate: Stabilise page count when migrating transparent hugepages

On 2017/6/8 20:07, Will Deacon wrote: > On Thu, Jun 08, 2017 at 12:52:07PM +0200, Vlastimil Babka wrote: >> On 06/06/2017 07:58 PM, Will Deacon wrote: >>> When migrating a transparent hugepage, migrate_misplaced_transhuge_page >>> guards itself against a concurrent fastgup of the page by checking

Re: [PATCH 3/3] mm: migrate: Stabilise page count when migrating transparent hugepages

On 2017/6/8 20:07, Will Deacon wrote: > On Thu, Jun 08, 2017 at 12:52:07PM +0200, Vlastimil Babka wrote: >> On 06/06/2017 07:58 PM, Will Deacon wrote: >>> When migrating a transparent hugepage, migrate_misplaced_transhuge_page >>> guards itself against a concurrent fastgup of the page by checking

Re: [PATCH] mm: correct the comment when reclaimed pages exceed the scanned pages

On 2017/6/8 14:46, Minchan Kim wrote: > On Wed, Jun 07, 2017 at 04:31:06PM +0800, zhongjiang wrote: >> The commit e1587a494540 ("mm: vmpressure: fix sending wrong events on >> underflow") declare that reclaimed pages exceed the scanned pages due >> to the thp reclaim. it is incorrect because THP

Re: [PATCH] mm: correct the comment when reclaimed pages exceed the scanned pages

On 2017/6/8 14:46, Minchan Kim wrote: > On Wed, Jun 07, 2017 at 04:31:06PM +0800, zhongjiang wrote: >> The commit e1587a494540 ("mm: vmpressure: fix sending wrong events on >> underflow") declare that reclaimed pages exceed the scanned pages due >> to the thp reclaim. it is incorrect because THP

Re: mm, something wring in page_lock_anon_vma_read()?

On 2017/6/8 21:59, Vlastimil Babka wrote: > On 06/08/2017 03:44 PM, Xishi Qiu wrote: >> On 2017/5/23 17:33, Vlastimil Babka wrote: >> >>> On 05/23/2017 11:21 AM, zhong jiang wrote: >>>> On 2017/5/23 0:51, Vlastimil Babka wrote: >>>>> On 05/20/20

Re: mm, something wring in page_lock_anon_vma_read()?

On 2017/6/8 21:59, Vlastimil Babka wrote: > On 06/08/2017 03:44 PM, Xishi Qiu wrote: >> On 2017/5/23 17:33, Vlastimil Babka wrote: >> >>> On 05/23/2017 11:21 AM, zhong jiang wrote: >>>> On 2017/5/23 0:51, Vlastimil Babka wrote: >>>>> On 05/20/20

Re: [PATCH] mm: correct the comment when reclaimed pages exceed the scanned pages

On 2017/6/7 16:31, zhongjiang wrote: > The commit e1587a494540 ("mm: vmpressure: fix sending wrong events on > underflow") declare that reclaimed pages exceed the scanned pages due > to the thp reclaim. it is incorrect because THP will be spilt to normal > page and loop again. which will result in

Re: [PATCH] mm: correct the comment when reclaimed pages exceed the scanned pages

On 2017/6/7 16:31, zhongjiang wrote: > The commit e1587a494540 ("mm: vmpressure: fix sending wrong events on > underflow") declare that reclaimed pages exceed the scanned pages due > to the thp reclaim. it is incorrect because THP will be spilt to normal > page and loop again. which will result in

Re: [PATCH] Revert "mm: vmpressure: fix sending wrong events on underflow"

On 2017/6/7 14:17, vinayak menon wrote: > On Wed, Jun 7, 2017 at 11:42 AM, Minchan Kim <minc...@kernel.org> wrote: >> On Wed, Jun 07, 2017 at 12:56:57PM +0800, zhong jiang wrote: >>> On 2017/6/7 11:55, Minchan Kim wrote: >>>> On Wed, Jun 07, 2017 a

Re: [PATCH] Revert "mm: vmpressure: fix sending wrong events on underflow"

On 2017/6/7 14:17, vinayak menon wrote: > On Wed, Jun 7, 2017 at 11:42 AM, Minchan Kim wrote: >> On Wed, Jun 07, 2017 at 12:56:57PM +0800, zhong jiang wrote: >>> On 2017/6/7 11:55, Minchan Kim wrote: >>>> On Wed, Jun 07, 2017 at 11:08:37AM +0800, zhongjiang wr

Re: [PATCH] Revert "mm: vmpressure: fix sending wrong events on underflow"

On 2017/6/7 11:55, Minchan Kim wrote: > On Wed, Jun 07, 2017 at 11:08:37AM +0800, zhongjiang wrote: >> This reverts commit e1587a4945408faa58d0485002c110eb2454740c. >> >> THP lru page is reclaimed , THP is split to normal page and loop again. >> reclaimed pages should not be bigger than nr_scan.

Re: [PATCH] Revert "mm: vmpressure: fix sending wrong events on underflow"

On 2017/6/7 11:55, Minchan Kim wrote: > On Wed, Jun 07, 2017 at 11:08:37AM +0800, zhongjiang wrote: >> This reverts commit e1587a4945408faa58d0485002c110eb2454740c. >> >> THP lru page is reclaimed , THP is split to normal page and loop again. >> reclaimed pages should not be bigger than nr_scan.

Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

On 2017/6/7 10:53, Minchan Kim wrote: > Hi, > > On Tue, Jun 06, 2017 at 09:00:55PM +0800, zhong jiang wrote: >> On 2017/1/31 7:40, Minchan Kim wrote: >>> Hi Vinayak, >>> Sorry for late response. It was Lunar New Year holidays. >>> >>> On Fri, Ja

Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

On 2017/6/7 10:53, Minchan Kim wrote: > Hi, > > On Tue, Jun 06, 2017 at 09:00:55PM +0800, zhong jiang wrote: >> On 2017/1/31 7:40, Minchan Kim wrote: >>> Hi Vinayak, >>> Sorry for late response. It was Lunar New Year holidays. >>> >>> On Fri, Ja

Re: double call identical release when there is a race hitting

On 2017/6/6 23:56, Oleg Nesterov wrote: > I can't answer authoritatively, but > > On 06/06, zhong jiang wrote: >> Hi >> >> when I review the code, I find the following scenario will lead to a race , >> but I am not sure whether the real

Re: double call identical release when there is a race hitting

On 2017/6/6 23:56, Oleg Nesterov wrote: > I can't answer authoritatively, but > > On 06/06, zhong jiang wrote: >> Hi >> >> when I review the code, I find the following scenario will lead to a race , >> but I am not sure whether the real

double call identical release when there is a race hitting

Hi when I review the code, I find the following scenario will lead to a race , but I am not sure whether the real issue will hit or not. cpu1 cpu2 exit_mmap mmu_notifier_unregister

double call identical release when there is a race hitting

Hi when I review the code, I find the following scenario will lead to a race , but I am not sure whether the real issue will hit or not. cpu1 cpu2 exit_mmap mmu_notifier_unregister

Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

On 2017/1/31 7:40, Minchan Kim wrote: > Hi Vinayak, > Sorry for late response. It was Lunar New Year holidays. > > On Fri, Jan 27, 2017 at 01:43:23PM +0530, vinayak menon wrote: >>> Thanks for the explain. However, such case can happen with THP page >>> as well as slab. In case of THP page,

Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure

On 2017/1/31 7:40, Minchan Kim wrote: > Hi Vinayak, > Sorry for late response. It was Lunar New Year holidays. > > On Fri, Jan 27, 2017 at 01:43:23PM +0530, vinayak menon wrote: >>> Thanks for the explain. However, such case can happen with THP page >>> as well as slab. In case of THP page,

Re: [PATCH v2] signal: Avoid undefined behaviour in kill_something_info

On 2017/6/5 21:31, Oleg Nesterov wrote: > On 06/05, zhongjiang wrote: >> --- a/kernel/signal.c >> +++ b/kernel/signal.c >> @@ -1395,6 +1395,12 @@ static int kill_something_info(int sig, struct >> siginfo *info, pid_t pid) >> >> read_lock(_lock); >> if (pid != -1) { >> +/* >>

Re: [PATCH v2] signal: Avoid undefined behaviour in kill_something_info

On 2017/6/5 21:31, Oleg Nesterov wrote: > On 06/05, zhongjiang wrote: >> --- a/kernel/signal.c >> +++ b/kernel/signal.c >> @@ -1395,6 +1395,12 @@ static int kill_something_info(int sig, struct >> siginfo *info, pid_t pid) >> >> read_lock(_lock); >> if (pid != -1) { >> +/* >>

Re: [PATCH v2] signal: Avoid undefined behaviour in kill_something_info

On 2017/6/5 21:09, Michal Hocko wrote: > On Mon 05-06-17 20:53:27, zhongjiang wrote: >> diff --git a/kernel/signal.c b/kernel/signal.c >> index ca92bcf..63148f7 100644 >> --- a/kernel/signal.c >> +++ b/kernel/signal.c >> @@ -1395,6 +1395,12 @@ static int kill_something_info(int sig, struct >>

Re: [PATCH v2] signal: Avoid undefined behaviour in kill_something_info

On 2017/6/5 21:09, Michal Hocko wrote: > On Mon 05-06-17 20:53:27, zhongjiang wrote: >> diff --git a/kernel/signal.c b/kernel/signal.c >> index ca92bcf..63148f7 100644 >> --- a/kernel/signal.c >> +++ b/kernel/signal.c >> @@ -1395,6 +1395,12 @@ static int kill_something_info(int sig, struct >>

Re: [PATCH] signal: Avoid undefined behaviour in kill_something_info

On 2017/6/5 20:37, Oleg Nesterov wrote: > On 06/05, zhongjiang wrote: >> static int kill_something_info(int sig, struct siginfo *info, pid_t pid) >> { >> -int ret; >> +int ret, vpid; >> >> if (pid > 0) { >> rcu_read_lock(); >> @@ -1395,8 +1395,12 @@ static int

Re: [PATCH] signal: Avoid undefined behaviour in kill_something_info

On 2017/6/5 20:37, Oleg Nesterov wrote: > On 06/05, zhongjiang wrote: >> static int kill_something_info(int sig, struct siginfo *info, pid_t pid) >> { >> -int ret; >> +int ret, vpid; >> >> if (pid > 0) { >> rcu_read_lock(); >> @@ -1395,8 +1395,12 @@ static int

Re: [PATCH] mm/vmalloc: a slight change of compare target in __insert_vmap_area()

On 2017/6/2 9:45, Wei Yang wrote: > On Fri, May 26, 2017 at 09:55:31AM +0800, zhong jiang wrote: >> On 2017/5/26 9:36, Wei Yang wrote: >>> On Thu, May 25, 2017 at 11:04:44AM +0800, zhong jiang wrote: >>>> I hit the overlap issue, but it is hard to reproduced.

<    1   2   3   4   5   6   7   8   >