Re: [PATCH] arm: kprobe: replace patch_lock to raw lock

-by: Yang Shi <yang@linaro.org> This can also go upstream. Acked-by: Sebastian Andrzej Siewior <bige...@linutronix.de> Yes, thanks for acking. Russell, Could you please consider this patch? Thanks, Yang Sebastian

Re: [PATCH] arm: kprobe: replace patch_lock to raw lock

On 12/1/2016 6:13 AM, Sebastian Andrzej Siewior wrote: On 2016-11-10 16:17:55 [-0800], Yang Shi wrote: Since patch_text_stop_machine() is called in stop_machine() which disables IRQ, sleepable lock should be not used in this atomic context, so replace patch_lock to raw lock. Signed-off-by:

Re: [v2 PATCH] arm64: kasan: instrument user memory access API

uch instrument to ARM64 too. Define __copy_to/from_user in C in order to add kasan_check_read/write call, rename assembly implementation to __arch_copy_to/from_user. Tested by test_kasan module. Signed-off-by: Yang Shi <yang@linaro.org> --- v2: Adopted the comment from Andrey and Mark to

Re: [v2 PATCH] arm64: kasan: instrument user memory access API

Hi Will & Catalin, Any comment for this patch? Thanks, Yang On 5/27/2016 2:01 PM, Yang Shi wrote: The upstream commit 1771c6e1a567ea0ba20a4ffe68a1419fd8ef ("x86/kasan: instrument user memory access API") added KASAN instrument to x86 user memory access API, so added such instrument to

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On 6/1/2016 10:00 PM, Minchan Kim wrote: On Wed, Jun 01, 2016 at 01:40:48PM -0700, Shi, Yang wrote: On 5/29/2016 11:11 PM, Minchan Kim wrote: On Fri, May 27, 2016 at 11:16:41AM -0700, Shi, Yang wrote: If we goes this way, how to guarantee this race? Thanks for pointing out

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On 6/1/2016 10:00 PM, Minchan Kim wrote: On Wed, Jun 01, 2016 at 01:40:48PM -0700, Shi, Yang wrote: On 5/29/2016 11:11 PM, Minchan Kim wrote: On Fri, May 27, 2016 at 11:16:41AM -0700, Shi, Yang wrote: If we goes this way, how to guarantee this race? Thanks for pointing out

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote: On 5/25/2016 5:37 PM, Minchan Kim wrote: On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote: On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote: Per the discussion with Joonsoo Kim [1], we need check the return value

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote: On 5/25/2016 5:37 PM, Minchan Kim wrote: On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote: On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote: Per the discussion with Joonsoo Kim [1], we need check the return value

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On 5/29/2016 11:11 PM, Minchan Kim wrote: On Fri, May 27, 2016 at 11:16:41AM -0700, Shi, Yang wrote: If we goes this way, how to guarantee this race? Thanks for pointing out this. It sounds reasonable. However, this should be only possible to happen on 32 bit since just 32 bit version

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On 5/29/2016 11:11 PM, Minchan Kim wrote: On Fri, May 27, 2016 at 11:16:41AM -0700, Shi, Yang wrote: If we goes this way, how to guarantee this race? Thanks for pointing out this. It sounds reasonable. However, this should be only possible to happen on 32 bit since just 32 bit version

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On 5/27/2016 1:02 PM, Andrew Morton wrote: On Thu, 26 May 2016 16:15:28 -0700 "Shi, Yang" <yang@linaro.org> wrote: I hope we consider this direction, too. Yang, Could you think about this? Thanks a lot for the suggestion. Sorry for the late reply, I was busy on prepari

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On 5/27/2016 1:02 PM, Andrew Morton wrote: On Thu, 26 May 2016 16:15:28 -0700 "Shi, Yang" wrote: I hope we consider this direction, too. Yang, Could you think about this? Thanks a lot for the suggestion. Sorry for the late reply, I was busy on preparing patches.

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On 5/27/2016 1:11 AM, Minchan Kim wrote: On Fri, May 27, 2016 at 03:08:39PM +0900, Joonsoo Kim wrote: On Fri, May 27, 2016 at 02:14:32PM +0900, Minchan Kim wrote: On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote: On 5/25/2016 5:37 PM, Minchan Kim wrote: On Tue, May 24, 2016 at 11:58

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On 5/27/2016 1:11 AM, Minchan Kim wrote: On Fri, May 27, 2016 at 03:08:39PM +0900, Joonsoo Kim wrote: On Fri, May 27, 2016 at 02:14:32PM +0900, Minchan Kim wrote: On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote: On 5/25/2016 5:37 PM, Minchan Kim wrote: On Tue, May 24, 2016 at 11:58

Re: [PATCH] arm64: kasan: instrument user memory access API

On 5/27/2016 10:46 AM, Mark Rutland wrote: On Fri, May 27, 2016 at 09:34:03AM -0700, Shi, Yang wrote: On 5/27/2016 4:02 AM, Andrey Ryabinin wrote: On 05/26/2016 09:43 PM, Yang Shi wrote: The upstream commit 1771c6e1a567ea0ba20a4ffe68a1419fd8ef ("x86/kasan: instrument user memory a

Re: [PATCH] arm64: kasan: instrument user memory access API

On 5/27/2016 10:46 AM, Mark Rutland wrote: On Fri, May 27, 2016 at 09:34:03AM -0700, Shi, Yang wrote: On 5/27/2016 4:02 AM, Andrey Ryabinin wrote: On 05/26/2016 09:43 PM, Yang Shi wrote: The upstream commit 1771c6e1a567ea0ba20a4ffe68a1419fd8ef ("x86/kasan: instrument user memory a

Re: [PATCH] arm64: kasan: instrument user memory access API

ARM64 too. Tested by test_kasan module. Signed-off-by: Yang Shi <yang@linaro.org> --- arch/arm64/include/asm/uaccess.h | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-) Please, cover __copy_from_user() and __copy_to_user() too. Unlike x86, your patch doesn't inst

Re: [PATCH] arm64: kasan: instrument user memory access API

On 5/27/2016 4:02 AM, Andrey Ryabinin wrote: On 05/26/2016 09:43 PM, Yang Shi wrote: The upstream commit 1771c6e1a567ea0ba20a4ffe68a1419fd8ef ("x86/kasan: instrument user memory access API") added KASAN instrument to x86 user memory access API, so added such instrument to ARM64 too.

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

NULL in some cases, although it is unlikely, i.e. memory hotplug. Tested with ltp with "page_owner=0". [1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE Signed-off-by: Yang Shi <yang@linaro.org> I didn't read code code in detail to see how page_ext memory

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

On 5/25/2016 5:37 PM, Minchan Kim wrote: On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote: On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote: Per the discussion with Joonsoo Kim [1], we need check the return value of lookup_page_ext() for all call sites since it might return

Re: [PATCH] mm: use early_pfn_to_nid in register_page_bootmem_info_node

On 5/25/2016 3:23 PM, Andrew Morton wrote: On Wed, 25 May 2016 14:00:07 -0700 Yang Shi <yang@linaro.org> wrote: register_page_bootmem_info_node() is invoked in mem_init(), so it will be called before page_alloc_init_late() if CONFIG_DEFERRED_STRUCT_PAGE_INIT is enabled. But, pfn_

Re: [PATCH] mm: use early_pfn_to_nid in register_page_bootmem_info_node

On 5/25/2016 3:23 PM, Andrew Morton wrote: On Wed, 25 May 2016 14:00:07 -0700 Yang Shi wrote: register_page_bootmem_info_node() is invoked in mem_init(), so it will be called before page_alloc_init_late() if CONFIG_DEFERRED_STRUCT_PAGE_INIT is enabled. But, pfn_to_nid() depends on memmap

Re: [PATCH] Fixing compilation error from file include/linux/page_idle.h

On 5/25/2016 3:11 AM, shakilk1...@gmail.com wrote: From: shakil khan Thanks for the patch, this issue had been fixed by Arnd. Yang --- include/linux/page_idle.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git

Re: [PATCH] Fixing compilation error from file include/linux/page_idle.h

On 5/25/2016 3:11 AM, shakilk1...@gmail.com wrote: From: shakil khan Thanks for the patch, this issue had been fixed by Arnd. Yang --- include/linux/page_idle.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/include/linux/page_idle.h

Re: [PATCH] mm: page_is_guard return false when page_ext arrays are not allocated yet

On 5/23/2016 10:37 PM, Joonsoo Kim wrote: On Fri, May 20, 2016 at 10:00:06AM -0700, Shi, Yang wrote: On 5/19/2016 7:40 PM, Joonsoo Kim wrote: 2016-05-20 2:18 GMT+09:00 Shi, Yang <yang@linaro.org>: On 5/18/2016 5:28 PM, Joonsoo Kim wrote: Vlastiml, thanks for ccing me on origin

Re: [PATCH] mm: page_is_guard return false when page_ext arrays are not allocated yet

On 5/23/2016 10:37 PM, Joonsoo Kim wrote: On Fri, May 20, 2016 at 10:00:06AM -0700, Shi, Yang wrote: On 5/19/2016 7:40 PM, Joonsoo Kim wrote: 2016-05-20 2:18 GMT+09:00 Shi, Yang : On 5/18/2016 5:28 PM, Joonsoo Kim wrote: Vlastiml, thanks for ccing me on original bug report. On Wed, May 18

Re: [PATCH] mm: fix build problems from lookup_page_ext

Hi Arnd, Thanks a lot for the patch. My bad, sorry for the inconvenience. I omitted the specific page_idle change is for 32 bit only. And, my host compiler looks old which is still 4.8 so it might not catch the warning. I will update my compiler. Regards, Yang On 5/24/2016 3:08 AM, Arnd

Re: [PATCH] mm: fix build problems from lookup_page_ext

Hi Arnd, Thanks a lot for the patch. My bad, sorry for the inconvenience. I omitted the specific page_idle change is for 32 bit only. And, my host compiler looks old which is still 4.8 so it might not catch the warning. I will update my compiler. Regards, Yang On 5/24/2016 3:08 AM, Arnd

Re: [PATCH] mm: make CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on !FLATMEM explicitly

s a lot. It sounds way better. Will address in V2. Yang [1] http://lkml.kernel.org/r/20160523073157.gd2...@dhcp22.suse.cz Signed-off-by: Yang Shi <yang@linaro.org> --- mm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/Kconfig b/mm/Kconfig index 2664c11..22fa818 10064

Re: [PATCH] mm: make CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on !FLATMEM explicitly

On 5/23/2016 11:22 AM, Michal Hocko wrote: On Mon 23-05-16 09:54:31, Yang Shi wrote: Per the suggestion from Michal Hocko [1], CONFIG_DEFERRED_STRUCT_PAGE_INIT should be incompatible with FLATMEM, make this explicitly in Kconfig. I guess the changelog could benefit from some clarification.

Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

On 5/23/2016 12:31 AM, Michal Hocko wrote: On Fri 20-05-16 08:41:09, Shi, Yang wrote: On 5/20/2016 6:16 AM, Michal Hocko wrote: On Thu 19-05-16 15:13:26, Yang Shi wrote: [...] diff --git a/init/main.c b/init/main.c index b3c6e36..2075faf 100644 --- a/init/main.c +++ b/init/main.c @@ -606,7

Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

On 5/23/2016 12:31 AM, Michal Hocko wrote: On Fri 20-05-16 08:41:09, Shi, Yang wrote: On 5/20/2016 6:16 AM, Michal Hocko wrote: On Thu 19-05-16 15:13:26, Yang Shi wrote: [...] diff --git a/init/main.c b/init/main.c index b3c6e36..2075faf 100644 --- a/init/main.c +++ b/init/main.c @@ -606,7

Re: [PATCH] mm: page_is_guard return false when page_ext arrays are not allocated yet

On 5/19/2016 7:40 PM, Joonsoo Kim wrote: 2016-05-20 2:18 GMT+09:00 Shi, Yang <yang@linaro.org>: On 5/18/2016 5:28 PM, Joonsoo Kim wrote: Vlastiml, thanks for ccing me on original bug report. On Wed, May 18, 2016 at 03:23:45PM -0700, Yang Shi wrote: When enabling the below

Re: [PATCH] mm: page_is_guard return false when page_ext arrays are not allocated yet

On 5/19/2016 7:40 PM, Joonsoo Kim wrote: 2016-05-20 2:18 GMT+09:00 Shi, Yang : On 5/18/2016 5:28 PM, Joonsoo Kim wrote: Vlastiml, thanks for ccing me on original bug report. On Wed, May 18, 2016 at 03:23:45PM -0700, Yang Shi wrote: When enabling the below kernel configs

Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

On 5/20/2016 6:16 AM, Michal Hocko wrote: On Thu 19-05-16 15:13:26, Yang Shi wrote: [...] diff --git a/init/main.c b/init/main.c index b3c6e36..2075faf 100644 --- a/init/main.c +++ b/init/main.c @@ -606,7 +606,6 @@ asmlinkage __visible void __init start_kernel(void) initrd_start

Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

On 5/20/2016 6:16 AM, Michal Hocko wrote: On Thu 19-05-16 15:13:26, Yang Shi wrote: [...] diff --git a/init/main.c b/init/main.c index b3c6e36..2075faf 100644 --- a/init/main.c +++ b/init/main.c @@ -606,7 +606,6 @@ asmlinkage __visible void __init start_kernel(void) initrd_start

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

On 5/19/2016 4:21 PM, Andrew Morton wrote: On Thu, 19 May 2016 15:35:15 -0700 "Shi, Yang" <yang@linaro.org> wrote: On 5/19/2016 3:30 PM, Andrew Morton wrote: On Thu, 19 May 2016 14:29:05 -0700 Yang Shi <yang@linaro.org> wrote: When DEFERRED_STRUCT_PAGE_INIT is

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

On 5/19/2016 4:21 PM, Andrew Morton wrote: On Thu, 19 May 2016 15:35:15 -0700 "Shi, Yang" wrote: On 5/19/2016 3:30 PM, Andrew Morton wrote: On Thu, 19 May 2016 14:29:05 -0700 Yang Shi wrote: When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot are i

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

On 5/19/2016 3:30 PM, Andrew Morton wrote: On Thu, 19 May 2016 14:29:05 -0700 Yang Shi <yang@linaro.org> wrote: When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot are initialized, then the rest are initialized in parallel by starting one-off "pgdatin

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

On 5/19/2016 3:30 PM, Andrew Morton wrote: On Thu, 19 May 2016 14:29:05 -0700 Yang Shi wrote: When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot are initialized, then the rest are initialized in parallel by starting one-off "pgdatinitX" kernel thread for each node X.

Re: [PATCH] mm: page_is_guard return false when page_ext arrays are not allocated yet

On 5/18/2016 5:28 PM, Joonsoo Kim wrote: Vlastiml, thanks for ccing me on original bug report. On Wed, May 18, 2016 at 03:23:45PM -0700, Yang Shi wrote: When enabling the below kernel configs: CONFIG_DEFERRED_STRUCT_PAGE_INIT CONFIG_DEBUG_PAGEALLOC CONFIG_PAGE_EXTENSION CONFIG_DEBUG_VM

Re: [PATCH] mm: page_is_guard return false when page_ext arrays are not allocated yet

On 5/18/2016 5:28 PM, Joonsoo Kim wrote: Vlastiml, thanks for ccing me on original bug report. On Wed, May 18, 2016 at 03:23:45PM -0700, Yang Shi wrote: When enabling the below kernel configs: CONFIG_DEFERRED_STRUCT_PAGE_INIT CONFIG_DEBUG_PAGEALLOC CONFIG_PAGE_EXTENSION CONFIG_DEBUG_VM

Re: [BUG] Null pointer dereference when freeing pages on 4.6-rc6

On 5/16/2016 5:44 AM, Vlastimil Babka wrote: [+CC Joonsoo based on git blame] On 05/05/2016 11:13 PM, Shi, Yang wrote: Hi folks, When I enable the below kernel configs on 4.6-rc6, I came across null pointer deference issue in boot stage. CONFIG_SPARSEMEM CONFIG_DEFERRED_STRUCT_PAGE_INIT

Re: [BUG] Null pointer dereference when freeing pages on 4.6-rc6

On 5/16/2016 5:44 AM, Vlastimil Babka wrote: [+CC Joonsoo based on git blame] On 05/05/2016 11:13 PM, Shi, Yang wrote: Hi folks, When I enable the below kernel configs on 4.6-rc6, I came across null pointer deference issue in boot stage. CONFIG_SPARSEMEM CONFIG_DEFERRED_STRUCT_PAGE_INIT

Re: [PATCH net-next] bpf: arm64: remove callee-save registers use for tmp registers

On 5/16/2016 4:45 PM, Z Lim wrote: Hi Yang, On Mon, May 16, 2016 at 4:09 PM, Yang Shi <yang@linaro.org> wrote: In the current implementation of ARM64 eBPF JIT, R23 and R24 are used for tmp registers, which are callee-saved registers. This leads to variable size of JIT prologue and ep

Re: [PATCH net-next] bpf: arm64: remove callee-save registers use for tmp registers

On 5/16/2016 4:45 PM, Z Lim wrote: Hi Yang, On Mon, May 16, 2016 at 4:09 PM, Yang Shi wrote: In the current implementation of ARM64 eBPF JIT, R23 and R24 are used for tmp registers, which are callee-saved registers. This leads to variable size of JIT prologue and epilogue. The latest blinding

Re: [PATCH] mm: slab: remove ZONE_DMA_FLAG

On 5/5/2016 4:49 AM, Michal Hocko wrote: On Wed 04-05-16 10:01:37, Yang Shi wrote: Now we have IS_ENABLED helper to check if a Kconfig option is enabled or not, so ZONE_DMA_FLAG sounds no longer useful. And, the use of ZONE_DMA_FLAG in slab looks pointless according to the comment [1] from

Re: [PATCH] mm: slab: remove ZONE_DMA_FLAG

On 5/5/2016 4:49 AM, Michal Hocko wrote: On Wed 04-05-16 10:01:37, Yang Shi wrote: Now we have IS_ENABLED helper to check if a Kconfig option is enabled or not, so ZONE_DMA_FLAG sounds no longer useful. And, the use of ZONE_DMA_FLAG in slab looks pointless according to the comment [1] from

[BUG] Null pointer dereference when freeing pages on 4.6-rc6

Hi folks, When I enable the below kernel configs on 4.6-rc6, I came across null pointer deference issue in boot stage. CONFIG_SPARSEMEM CONFIG_DEFERRED_STRUCT_PAGE_INIT CONFIG_DEBUG_PAGEALLOC CONFIG_PAGE_EXTENSION CONFIG_DEBUG_VM The splat is: BUG: unable to handle kernel NULL pointer

[BUG] Null pointer dereference when freeing pages on 4.6-rc6

Hi folks, When I enable the below kernel configs on 4.6-rc6, I came across null pointer deference issue in boot stage. CONFIG_SPARSEMEM CONFIG_DEFERRED_STRUCT_PAGE_INIT CONFIG_DEBUG_PAGEALLOC CONFIG_PAGE_EXTENSION CONFIG_DEBUG_VM The splat is: BUG: unable to handle kernel NULL pointer

Re: [PATCH] mm: move huge_pmd_set_accessed out of huge_memory.c

On 4/22/2016 2:48 AM, Kirill A. Shutemov wrote: On Thu, Apr 21, 2016 at 03:56:07PM -0700, Shi, Yang wrote: On 4/21/2016 12:30 AM, Kirill A. Shutemov wrote: On Wed, Apr 20, 2016 at 02:00:11PM -0700, Shi, Yang wrote: Hi folks, I didn't realize pmd_* functions are protected

Re: [PATCH] mm: move huge_pmd_set_accessed out of huge_memory.c

On 4/22/2016 2:48 AM, Kirill A. Shutemov wrote: On Thu, Apr 21, 2016 at 03:56:07PM -0700, Shi, Yang wrote: On 4/21/2016 12:30 AM, Kirill A. Shutemov wrote: On Wed, Apr 20, 2016 at 02:00:11PM -0700, Shi, Yang wrote: Hi folks, I didn't realize pmd_* functions are protected

Re: [BUG linux-next] Kernel panic found with linux-next-20160414

On 4/27/2016 1:14 AM, Hugh Dickins wrote: On Wed, 20 Apr 2016, Shi, Yang wrote: On 4/20/2016 1:01 AM, Hugh Dickins wrote: On Tue, 19 Apr 2016, Shi, Yang wrote: Hi folks, When I ran ltp on linux-next-20160414 on my ARM64 machine, I got the below kernel panic: Unable to handle kernel paging

Re: [BUG linux-next] Kernel panic found with linux-next-20160414

On 4/27/2016 1:14 AM, Hugh Dickins wrote: On Wed, 20 Apr 2016, Shi, Yang wrote: On 4/20/2016 1:01 AM, Hugh Dickins wrote: On Tue, 19 Apr 2016, Shi, Yang wrote: Hi folks, When I ran ltp on linux-next-20160414 on my ARM64 machine, I got the below kernel panic: Unable to handle kernel paging

Re: [BUG] set_pte_at: racy dirty state clearing warning

On 4/21/2016 1:49 AM, Catalin Marinas wrote: On Wed, Apr 20, 2016 at 04:01:39PM -0700, Shi, Yang wrote: When I enable memory comact via # echo 1 > /proc/sys/vm/compact_memory I got the below WARNING: set_pte_at: racy dirty state clearing: 0x006899371bd3 -> 0x006899

Re: [BUG] set_pte_at: racy dirty state clearing warning

On 4/21/2016 1:49 AM, Catalin Marinas wrote: On Wed, Apr 20, 2016 at 04:01:39PM -0700, Shi, Yang wrote: When I enable memory comact via # echo 1 > /proc/sys/vm/compact_memory I got the below WARNING: set_pte_at: racy dirty state clearing: 0x006899371bd3 -> 0x006899

Re: [BUG linux-next] kernel NULL pointer dereference on linux-next-20160420

Did some preliminary investigation on this one. The problem is the cc->freepages list is empty, but cc->nr_freepages > 0, it looks the list and nr_freepages get out-of-sync somewhere. Any hint is appreciated. Thanks, Yang On 4/21/2016 5:38 PM, Shi, Yang wrote: Hi folks, I did

Re: [BUG linux-next] kernel NULL pointer dereference on linux-next-20160420

Did some preliminary investigation on this one. The problem is the cc->freepages list is empty, but cc->nr_freepages > 0, it looks the list and nr_freepages get out-of-sync somewhere. Any hint is appreciated. Thanks, Yang On 4/21/2016 5:38 PM, Shi, Yang wrote: Hi folks, I did

Re: [PATCH] panic: lockdep: correct lock debugging state check

On 4/26/2016 5:39 AM, Peter Zijlstra wrote: On Mon, Apr 25, 2016 at 08:36:37PM -0700, Yang Shi wrote: When kernel oops happens, lock debugging is turned off by debug_locks_off() in oops_enter() via calling __debug_locks_off() which set debug_locks to 0 via xchg(). But, calling to

Re: [PATCH] panic: lockdep: correct lock debugging state check

On 4/26/2016 5:39 AM, Peter Zijlstra wrote: On Mon, Apr 25, 2016 at 08:36:37PM -0700, Yang Shi wrote: When kernel oops happens, lock debugging is turned off by debug_locks_off() in oops_enter() via calling __debug_locks_off() which set debug_locks to 0 via xchg(). But, calling to

Re: [linux-next PATCH] sched: cgroup: enable interrupt before calling threadgroup_change_begin

On 4/25/2016 10:35 AM, Shi, Yang wrote: On 4/23/2016 2:14 AM, Peter Zijlstra wrote: On Fri, Apr 22, 2016 at 08:56:28PM -0700, Yang Shi wrote: When kernel oops happens in some kernel thread, i.e. kcompactd in the test, the below bug might be triggered by the oops handler: What are you trying

Re: [linux-next PATCH] sched: cgroup: enable interrupt before calling threadgroup_change_begin

On 4/25/2016 10:35 AM, Shi, Yang wrote: On 4/23/2016 2:14 AM, Peter Zijlstra wrote: On Fri, Apr 22, 2016 at 08:56:28PM -0700, Yang Shi wrote: When kernel oops happens in some kernel thread, i.e. kcompactd in the test, the below bug might be triggered by the oops handler: What are you trying

Re: [linux-next PATCH] sched: cgroup: enable interrupt before calling threadgroup_change_begin

On 4/23/2016 2:14 AM, Peter Zijlstra wrote: On Fri, Apr 22, 2016 at 08:56:28PM -0700, Yang Shi wrote: When kernel oops happens in some kernel thread, i.e. kcompactd in the test, the below bug might be triggered by the oops handler: What are you trying to fix? You already oopsed the thing is

Re: [linux-next PATCH] sched: cgroup: enable interrupt before calling threadgroup_change_begin

On 4/23/2016 2:14 AM, Peter Zijlstra wrote: On Fri, Apr 22, 2016 at 08:56:28PM -0700, Yang Shi wrote: When kernel oops happens in some kernel thread, i.e. kcompactd in the test, the below bug might be triggered by the oops handler: What are you trying to fix? You already oopsed the thing is

Re: Warning triggered by lockdep checks for sock_owned_by_user on linux-next-20160420

On 4/22/2016 9:50 PM, Eric Dumazet wrote: On Fri, 2016-04-22 at 21:02 -0700, Shi, Yang wrote: Hi David, When I ran some test on a nfs mounted rootfs, I got the below warning with LOCKDEP enabled on linux-next-20160420: WARNING: CPU: 9 PID: 0 at include/net/sock.h:1408 udp_queue_rcv_skb+0x3d0

Re: Warning triggered by lockdep checks for sock_owned_by_user on linux-next-20160420

On 4/22/2016 9:50 PM, Eric Dumazet wrote: On Fri, 2016-04-22 at 21:02 -0700, Shi, Yang wrote: Hi David, When I ran some test on a nfs mounted rootfs, I got the below warning with LOCKDEP enabled on linux-next-20160420: WARNING: CPU: 9 PID: 0 at include/net/sock.h:1408 udp_queue_rcv_skb+0x3d0

Warning triggered by lockdep checks for sock_owned_by_user on linux-next-20160420

Hi David, When I ran some test on a nfs mounted rootfs, I got the below warning with LOCKDEP enabled on linux-next-20160420: WARNING: CPU: 9 PID: 0 at include/net/sock.h:1408 udp_queue_rcv_skb+0x3d0/0x660 Modules linked in: CPU: 9 PID: 0 Comm: swapper/9 Tainted: G D

Warning triggered by lockdep checks for sock_owned_by_user on linux-next-20160420

Hi David, When I ran some test on a nfs mounted rootfs, I got the below warning with LOCKDEP enabled on linux-next-20160420: WARNING: CPU: 9 PID: 0 at include/net/sock.h:1408 udp_queue_rcv_skb+0x3d0/0x660 Modules linked in: CPU: 9 PID: 0 Comm: swapper/9 Tainted: G D

[BUG linux-next] kernel NULL pointer dereference on linux-next-20160420

Hi folks, I did the below test with huge tmpfs on linux-next-20160420: # mount -t tmpfs huge=1 tmpfs /mnt # cd /mnt Then clone linux kernel Then I got the below bug, such test works well on non-huge tmpfs. BUG: unable to handle kernel NULL pointer dereference at (null) IP: []

[BUG linux-next] kernel NULL pointer dereference on linux-next-20160420

Hi folks, I did the below test with huge tmpfs on linux-next-20160420: # mount -t tmpfs huge=1 tmpfs /mnt # cd /mnt Then clone linux kernel Then I got the below bug, such test works well on non-huge tmpfs. BUG: unable to handle kernel NULL pointer dereference at (null) IP: []

Re: [PATCH] mm: move huge_pmd_set_accessed out of huge_memory.c

On 4/21/2016 2:15 AM, Hugh Dickins wrote: On Wed, 20 Apr 2016, Shi, Yang wrote: Hi folks, I didn't realize pmd_* functions are protected by CONFIG_TRANSPARENT_HUGEPAGE on the most architectures before I made this change. Before I fix all the affected architectures code, I want to check

Re: [PATCH] mm: move huge_pmd_set_accessed out of huge_memory.c

On 4/21/2016 2:15 AM, Hugh Dickins wrote: On Wed, 20 Apr 2016, Shi, Yang wrote: Hi folks, I didn't realize pmd_* functions are protected by CONFIG_TRANSPARENT_HUGEPAGE on the most architectures before I made this change. Before I fix all the affected architectures code, I want to check

Re: [PATCH] mm: move huge_pmd_set_accessed out of huge_memory.c

On 4/21/2016 12:30 AM, Kirill A. Shutemov wrote: On Wed, Apr 20, 2016 at 02:00:11PM -0700, Shi, Yang wrote: Hi folks, I didn't realize pmd_* functions are protected by CONFIG_TRANSPARENT_HUGEPAGE on the most architectures before I made this change. Before I fix all the affected architectures

Re: [PATCH] mm: move huge_pmd_set_accessed out of huge_memory.c

On 4/21/2016 12:30 AM, Kirill A. Shutemov wrote: On Wed, Apr 20, 2016 at 02:00:11PM -0700, Shi, Yang wrote: Hi folks, I didn't realize pmd_* functions are protected by CONFIG_TRANSPARENT_HUGEPAGE on the most architectures before I made this change. Before I fix all the affected architectures

[BUG] set_pte_at: racy dirty state clearing warning

Hi Will and Catalin, When I enable memory comact via # echo 1 > /proc/sys/vm/compact_memory I got the below WARNING: set_pte_at: racy dirty state clearing: 0x006899371bd3 -> 0x006899371fd3 [ cut here ] WARNING: CPU: 5 PID: 294 at

[BUG] set_pte_at: racy dirty state clearing warning

Hi Will and Catalin, When I enable memory comact via # echo 1 > /proc/sys/vm/compact_memory I got the below WARNING: set_pte_at: racy dirty state clearing: 0x006899371bd3 -> 0x006899371fd3 [ cut here ] WARNING: CPU: 5 PID: 294 at

Re: [PATCH] mm: move huge_pmd_set_accessed out of huge_memory.c

, Yang Shi wrote: huge_pmd_set_accessed is only called by __handle_mm_fault from memory.c, move the definition to memory.c and make it static like create_huge_pmd and wp_huge_pmd. Signed-off-by: Yang Shi <yang@linaro.org> --- include/linux/huge_mm.h | 4 mm/huge_memory.c

Re: [PATCH] mm: move huge_pmd_set_accessed out of huge_memory.c

Hi folks, I didn't realize pmd_* functions are protected by CONFIG_TRANSPARENT_HUGEPAGE on the most architectures before I made this change. Before I fix all the affected architectures code, I want to check if you guys think this change is worth or not? Thanks, Yang On 4/20/2016 11:24

[BUG linux-next] KASAN bug is raised on linux-next-20160414 with huge tmpfs on

Hi folks, When I run the below test on my ARM64 machine with NFS mounted rootfs, I got KASAN bug report. The test runs well if mnt is not mounted with "huge=1". # mount -t tmpfs -o huge=1 tmpfs /mnt # cp -a /opt/ltp /mnt/ BUG: KASAN: use-after-free in nfs_readdir+0x2c4/0x848 at addr

[BUG linux-next] KASAN bug is raised on linux-next-20160414 with huge tmpfs on

Hi folks, When I run the below test on my ARM64 machine with NFS mounted rootfs, I got KASAN bug report. The test runs well if mnt is not mounted with "huge=1". # mount -t tmpfs -o huge=1 tmpfs /mnt # cp -a /opt/ltp /mnt/ BUG: KASAN: use-after-free in nfs_readdir+0x2c4/0x848 at addr

Re: [BUG linux-next] Kernel panic found with linux-next-20160414

On 4/20/2016 1:01 AM, Hugh Dickins wrote: On Tue, 19 Apr 2016, Shi, Yang wrote: Hi folks, When I ran ltp on linux-next-20160414 on my ARM64 machine, I got the below kernel panic: Unable to handle kernel paging request at virtual address ffc007846000 pgd = ffc01e21d000

Re: [BUG linux-next] Kernel panic found with linux-next-20160414

On 4/20/2016 1:01 AM, Hugh Dickins wrote: On Tue, 19 Apr 2016, Shi, Yang wrote: Hi folks, When I ran ltp on linux-next-20160414 on my ARM64 machine, I got the below kernel panic: Unable to handle kernel paging request at virtual address ffc007846000 pgd = ffc01e21d000

Re: [PATCHv7 00/29] THP-enabled tmpfs/shmem using compound pages

On 4/19/2016 9:50 AM, Andrea Arcangeli wrote: Hello, On Mon, Apr 18, 2016 at 03:55:44PM -0700, Shi, Yang wrote: Hi Kirill, Finally, I got some time to look into and try yours and Hugh's patches, got two problems. One thing that come to mind to test is this: qemu with -machine accel=kvm -mem

Re: [PATCHv7 00/29] THP-enabled tmpfs/shmem using compound pages

On 4/19/2016 9:50 AM, Andrea Arcangeli wrote: Hello, On Mon, Apr 18, 2016 at 03:55:44PM -0700, Shi, Yang wrote: Hi Kirill, Finally, I got some time to look into and try yours and Hugh's patches, got two problems. One thing that come to mind to test is this: qemu with -machine accel=kvm -mem

[BUG linux-next] Kernel panic found with linux-next-20160414

Hi folks, When I ran ltp on linux-next-20160414 on my ARM64 machine, I got the below kernel panic: Unable to handle kernel paging request at virtual address ffc007846000 pgd = ffc01e21d000 [ffc007846000] *pgd=, *pud= Internal error: Oops: 9647

[BUG linux-next] Kernel panic found with linux-next-20160414

Hi folks, When I ran ltp on linux-next-20160414 on my ARM64 machine, I got the below kernel panic: Unable to handle kernel paging request at virtual address ffc007846000 pgd = ffc01e21d000 [ffc007846000] *pgd=, *pud= Internal error: Oops: 9647

KASAN can't change FRAME_WARN

Hi Andrey, When I enable KASAN for 4.5 and 4.6 (I didn't try with older versions), I got FRAME_WARN warning for frame size exceeds 2048 bytes. Then I found the kconfig looks like: range 0 8192 default 0 if KASAN default 1024 if !64BIT default 2048 if 64BIT In my understanding, FRAME_WARN

KASAN can't change FRAME_WARN

Hi Andrey, When I enable KASAN for 4.5 and 4.6 (I didn't try with older versions), I got FRAME_WARN warning for frame size exceeds 2048 bytes. Then I found the kconfig looks like: range 0 8192 default 0 if KASAN default 1024 if !64BIT default 2048 if 64BIT In my understanding, FRAME_WARN

Re: [PATCHv7 00/29] THP-enabled tmpfs/shmem using compound pages

On 4/19/2016 7:33 AM, Jerome Marchand wrote: On 04/19/2016 12:55 AM, Shi, Yang wrote: 2. I ran my THP test (generated a program with 4MB text section) on both x86-64 and ARM64 with yours and Hugh's patches (linux-next tree), I got the program execution time reduced by ~12% on x86-64, it looks

Re: [PATCHv7 00/29] THP-enabled tmpfs/shmem using compound pages

On 4/19/2016 7:33 AM, Jerome Marchand wrote: On 04/19/2016 12:55 AM, Shi, Yang wrote: 2. I ran my THP test (generated a program with 4MB text section) on both x86-64 and ARM64 with yours and Hugh's patches (linux-next tree), I got the program execution time reduced by ~12% on x86-64, it looks

Re: [PATCHv7 00/29] THP-enabled tmpfs/shmem using compound pages

Hi Kirill, Finally, I got some time to look into and try yours and Hugh's patches, got two problems. 1. A quick boot up test on my ARM64 machine with your v7 tree shows some unexpected error: systemd-journald[285]: Failed to save stream data /run/systemd/journal/streams/8:16863: No space

Re: [PATCHv7 00/29] THP-enabled tmpfs/shmem using compound pages

Hi Kirill, Finally, I got some time to look into and try yours and Hugh's patches, got two problems. 1. A quick boot up test on my ARM64 machine with your v7 tree shows some unexpected error: systemd-journald[285]: Failed to save stream data /run/systemd/journal/streams/8:16863: No space

Re: [PATCH] locktorture: make verbose writable and control stats print

On 4/15/2016 5:09 PM, Paul E. McKenney wrote: On Fri, Apr 15, 2016 at 04:45:32PM -0700, Shi, Yang wrote: On 4/15/2016 4:26 PM, Paul E. McKenney wrote: On Fri, Apr 15, 2016 at 01:28:11PM -0700, Yang Shi wrote: When building locktorture test into kernel image, it keeps printing out stats

Re: [PATCH] locktorture: make verbose writable and control stats print

On 4/15/2016 5:09 PM, Paul E. McKenney wrote: On Fri, Apr 15, 2016 at 04:45:32PM -0700, Shi, Yang wrote: On 4/15/2016 4:26 PM, Paul E. McKenney wrote: On Fri, Apr 15, 2016 at 01:28:11PM -0700, Yang Shi wrote: When building locktorture test into kernel image, it keeps printing out stats

Re: [PATCH] locktorture: make verbose writable and control stats print

, but it is read-only, so it can't be changed at runtime. Make verbose read-write and control stats print. Signed-off-by: Yang Shi <yang@linaro.org> Interesting change! But just out of curiosity, when you boot with locktorture built in, do you specify the shutdown_secs boot parameter?

Re: [PATCH] locktorture: make verbose writable and control stats print

On 4/15/2016 4:26 PM, Paul E. McKenney wrote: On Fri, Apr 15, 2016 at 01:28:11PM -0700, Yang Shi wrote: When building locktorture test into kernel image, it keeps printing out stats information even though there is no lock type specified. There is already verbose parameter to control print,

Re: [PATCH] arm64: Kconfig: make SCHED_MC and SCHED_SMT depend on SMP

On 4/14/2016 1:47 AM, Will Deacon wrote: On Wed, Apr 13, 2016 at 05:54:12PM -0700, Yang Shi wrote: SCHED_MC and SCHED_SMT are pointless when SMP is disabled. Although SMP is rarely disabled for ARM64, it looks more consistent to have such depend in Kconfig. You can't disable CONFIG_SMP for

Re: [PATCH] arm64: Kconfig: make SCHED_MC and SCHED_SMT depend on SMP

On 4/14/2016 1:47 AM, Will Deacon wrote: On Wed, Apr 13, 2016 at 05:54:12PM -0700, Yang Shi wrote: SCHED_MC and SCHED_SMT are pointless when SMP is disabled. Although SMP is rarely disabled for ARM64, it looks more consistent to have such depend in Kconfig. You can't disable CONFIG_SMP for

Re: [RFC V4 PATCH] trace: writeback: replace cgroup path to cgroup ino

Hi Steven, Any comment on this one? I'm supposed it will be taken by your tracing tree? Thanks, Yang On 3/4/2016 4:52 AM, Tejun Heo wrote: On Thu, Mar 03, 2016 at 01:08:57AM -0800, Yang Shi wrote: commit 5634cc2aa9aebc77bc862992e7805469dcf83dac ("writeback: update writeback tracepoints to

Re: [RFC V4 PATCH] trace: writeback: replace cgroup path to cgroup ino

Hi Steven, Any comment on this one? I'm supposed it will be taken by your tracing tree? Thanks, Yang On 3/4/2016 4:52 AM, Tejun Heo wrote: On Thu, Mar 03, 2016 at 01:08:57AM -0800, Yang Shi wrote: commit 5634cc2aa9aebc77bc862992e7805469dcf83dac ("writeback: update writeback tracepoints to

  1   2   3   >