Re: [PATCH v2 RESEND 1/2] arm, arm64: change_memory_common with numpages == 0 should be no-op.

Hi Will, On 26.01.2016 17:59, Will Deacon wrote: > Hi Mika, > > On Tue, Jan 26, 2016 at 04:59:52PM +0200, mika.pentt...@nextfour.com wrote: >> From: Mika Penttilä <mika.pentt...@nextfour.com> >> >> This makes the caller set_memory_xx() consistent with x86. >

[PATCH, REGRESSION v4] mm: make apply_to_page_range more robust

re explanation and stack trace, tagged as regression v4: change BUG_ON() to WARN_ON() and return -EINVAL Signed-off-by: Mika Penttilä mika.pentt...@nextfour.com --- diff --git a/mm/memory.c b/mm/memory.c index 30991f8..9178ee6 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1871,7 +1871,9 @@ in

Re: [PATCH, REGRESSION v3] mm: make apply_to_page_range more robust

On 01/22/2016 01:12 AM, David Rientjes wrote: > On Thu, 21 Jan 2016, Mika Penttilä wrote: > >> Recent changes (4.4.0+) in module loader triggered oops on ARM : >> >> The module in question is in-tree module : >> drivers/misc/ti-st/st_drv.ko >> &g

Re: [PATCH, REGRESSION v3] mm: make apply_to_page_range more robust

On 01/22/2016 01:12 AM, David Rientjes wrote: > On Thu, 21 Jan 2016, Mika Penttilä wrote: > >> Recent changes (4.4.0+) in module loader triggered oops on ARM : >> >> The module in question is in-tree module : >> drivers/misc/ti-st/st_drv.ko >> &g

[PATCH, REGRESSION v4] mm: make apply_to_page_range more robust

re explanation and stack trace, tagged as regression v4: change BUG_ON() to WARN_ON() and return -EINVAL Signed-off-by: Mika Penttilä mika.pentt...@nextfour.com --- diff --git a/mm/memory.c b/mm/memory.c index 30991f8..9178ee6 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1871,7 +1871,9 @@ in

[PATCH, REGRESSION v3] mm: make apply_to_page_range more robust

we have another caller with zero length. And, as Rusty mentioned, he expected a zero-length range to do nothing, which is what intuition says. Fix by letting call with zero size succeed. v2: add more explanation v3: added even more explanation and stack trace, tagged as regression Signed-off-b

[PATCH, REGRESSION v3] mm: make apply_to_page_range more robust

we have another caller with zero length. And, as Rusty mentioned, he expected a zero-length range to do nothing, which is what intuition says. Fix by letting call with zero size succeed. v2: add more explanation v3: added even more explanation and stack trace, tagged as regression Signed-off-b

Re: 4.4-rc crash (af_unix)

call+0x0/0x34) [ 1254.789639] Code: eb070826 e5943004 e5854000 e5853004 (e5835000) [ 1254.789644] ---[ end trace d7af6297ad511a4e ]--- On 12/22/2015 02:51 AM, Cong Wang wrote: > (Cc'ing netdev and Rainer) > > On Thu, Dec 17, 2015 at 9:12 PM, Mika Penttilä > wrote: >> Sti

Re: 4.4-rc crash (af_unix)

call+0x0/0x34) [ 1254.789639] Code: eb070826 e5943004 e5854000 e5853004 (e5835000) [ 1254.789644] ---[ end trace d7af6297ad511a4e ]--- On 12/22/2015 02:51 AM, Cong Wang wrote: > (Cc'ing netdev and Rainer) > > On Thu, Dec 17, 2015 at 9:12 PM, Mika Penttilä > <mika.pentt...@nextfour

4.4-rc5 crash (af_unix)

Still something with af_unix and/or wake code on rc5 : [34971.300210] Unable to handle kernel paging request at virtual address 56ac56ac [34971.307455] pgd = a8c3 [34971.310164] [56ac56ac] *pgd= [34971.313761] Internal error: Oops: 8005 [#1] PREEMPT SMP ARM [34971.319683]

4.4-rc5 crash (af_unix)

Still something with af_unix and/or wake code on rc5 : [34971.300210] Unable to handle kernel paging request at virtual address 56ac56ac [34971.307455] pgd = a8c3 [34971.310164] [56ac56ac] *pgd= [34971.313761] Internal error: Oops: 8005 [#1] PREEMPT SMP ARM [34971.319683]

4.4-rc4 crash net/80211 related

Hi, Triggered this with rc4, but the relevant parts are same in rc5: offending line is : (gdb) list *(ieee80211_scan_rx+0x158) 0xf68 is in ieee80211_scan_rx (net/mac80211/scan.c:205). 200 if (!(sdata1 && 201 (ether_addr_equal(mgmt->da,

4.4-rc4 crash net/80211 related

Hi, Triggered this with rc4, but the relevant parts are same in rc5: offending line is : (gdb) list *(ieee80211_scan_rx+0x158) 0xf68 is in ieee80211_scan_rx (net/mac80211/scan.c:205). 200 if (!(sdata1 && 201 (ether_addr_equal(mgmt->da,

Re: [PATCH v5 01/12] mm: support madvise(MADV_FREE)

> + * If pmd isn't transhuge but the page is THP and > + * is owned by only this process, split it and > + * deactivate all pages. > + */ > + if (PageTransCompound(page)) { > + if (page_mapcount(page) != 1) > +

Re: [PATCH v5 01/12] mm: support madvise(MADV_FREE)

> + * If pmd isn't transhuge but the page is THP and > + * is owned by only this process, split it and > + * deactivate all pages. > + */ > + if (PageTransCompound(page)) { > + if (page_mapcount(page) != 1) > +

4.4-rc2 crash: block related

Hi, With recent block layer pull i see a 100% repeatable crash on boot while mounting roots (ext4 partition on eMMC, with cfq io scheduler). --- 5.674294] Unable to handle kernel NULL pointer dereference at virtual address 0004 [5.682399] pgd = a8ca4000 [5.685113] [0004]

4.4-rc2 crash: block related

Hi, With recent block layer pull i see a 100% repeatable crash on boot while mounting roots (ext4 partition on eMMC, with cfq io scheduler). --- 5.674294] Unable to handle kernel NULL pointer dereference at virtual address 0004 [5.682399] pgd = a8ca4000 [5.685113] [0004]

Deferred struct page initialization issue vs memblocks

deferred_init_memmap() uses for_each_mem_pfn_range() which (in x86) uses memblocks. Because of CONFIG_ARCH_DISCARD_MEMBLOCK, the memblock infos have already been freed to page allocator (in free_low_memory_core_early()), which happens before deferred_init_memmap(). Maybe the fix is not to allow

Deferred struct page initialization issue vs memblocks

deferred_init_memmap() uses for_each_mem_pfn_range() which (in x86) uses memblocks. Because of CONFIG_ARCH_DISCARD_MEMBLOCK, the memblock infos have already been freed to page allocator (in free_low_memory_core_early()), which happens before deferred_init_memmap(). Maybe the fix is not to allow

[no subject]

This one causes imx6q with debug uart connected to "schedule while atomic" endlessly : 9e7b399d6528eac33a6fbfceb2b92af209c3454d is the first bad commit commit 9e7b399d6528eac33a6fbfceb2b92af209c3454d Author: Eduardo Valentin Date: Tue Aug 11 10:21:20 2015 -0700 serial: imx: remove

[no subject]

This one causes imx6q with debug uart connected to "schedule while atomic" endlessly : 9e7b399d6528eac33a6fbfceb2b92af209c3454d is the first bad commit commit 9e7b399d6528eac33a6fbfceb2b92af209c3454d Author: Eduardo Valentin Date: Tue Aug 11 10:21:20 2015 -0700

Re: [PATCH 3/5] x86, acpi, cpu-hotplug: Introduce apicid_to_cpuid[] array to store persistent cpuid <-> apicid mapping.

I think you forgot to reserve CPU 0 for BSP in cpuid mask. --Mika On Tue, Jul 7, 2015 at 12:30 PM, Tang Chen wrote: > From: Gu Zheng > > In this patch, we introduce a new static array named apicid_to_cpuid[], > which is large enough to store info for all possible cpus. > > And then, we modify

Re: [PATCH 3/5] x86, acpi, cpu-hotplug: Introduce apicid_to_cpuid[] array to store persistent cpuid - apicid mapping.

I think you forgot to reserve CPU 0 for BSP in cpuid mask. --Mika On Tue, Jul 7, 2015 at 12:30 PM, Tang Chen tangc...@cn.fujitsu.com wrote: From: Gu Zheng guz.f...@cn.fujitsu.com In this patch, we introduce a new static array named apicid_to_cpuid[], which is large enough to store info for

Fwd: imx6 eth phy broken

Seems to be the same clock tree change problems as in : http://www.spinics.net/lists/arm-kernel/msg400244.html I am able to help to reproduce/test/fix the problem with KaRo imx6q board. --Mika -- Forwarded message -- From: Mika Penttilä Date: Thu, Feb 26, 2015 at 11:58 AM

imx6 eth phy broken

Ethernet phy not working on current linus git on imx6 (KaRo tx6q) : [8.781755] fec 2188000.ethernet eth0: no PHY, assuming direct connection to switch [8.791175] libphy: PHY fixed-0:00 not found [8.797571] fec 2188000.ethernet eth0: could not attach to PHY Bisected :

Fwd: imx6 eth phy broken

Seems to be the same clock tree change problems as in : http://www.spinics.net/lists/arm-kernel/msg400244.html I am able to help to reproduce/test/fix the problem with KaRo imx6q board. --Mika -- Forwarded message -- From: Mika Penttilä mika.j.pentt...@gmail.com Date: Thu, Feb

imx6 eth phy broken

Ethernet phy not working on current linus git on imx6 (KaRo tx6q) : [8.781755] fec 2188000.ethernet eth0: no PHY, assuming direct connection to switch [8.791175] libphy: PHY fixed-0:00 not found [8.797571] fec 2188000.ethernet eth0: could not attach to PHY Bisected :

Re: [PATCH] x86, kaslr: Prevent .bss from overlaping initrd

ady, and bss is included in the output_size for choose_kernel_location(). So something else is going on? --Mika On Thu, Oct 30, 2014 at 9:06 PM, Mika Penttilä wrote: >> When choosing a random address, the current implementation does not take >> into >> account the reversed space fo

Re: [PATCH] x86, kaslr: Prevent .bss from overlaping initrd

is included in the output_size for choose_kernel_location(). So something else is going on? --Mika On Thu, Oct 30, 2014 at 9:06 PM, Mika Penttilä mika.j.pentt...@gmail.com wrote: When choosing a random address, the current implementation does not take into account the reversed space for .bss and .brk

Re: [PATCH] x86: Construct 32 bit boot time page tables in native format.

+ * This is how much memory *in addition to the memory covered up to + * and including _end* we need mapped initially. We need one bit for + * each possible page, but only in low memory, which means + * 2^32/4096/8 = 128K worst case (4G/4G split.) + * + * Modulo rounding, each megabyte

Re: [PATCH] x86: Construct 32 bit boot time page tables in native format.

+ * This is how much memory *in addition to the memory covered up to + * and including _end* we need mapped initially. We need one bit for + * each possible page, but only in low memory, which means + * 2^32/4096/8 = 128K worst case (4G/4G split.) + * + * Modulo rounding, each megabyte

Re: [patch 2/4] x86: PAT followup - Remove KERNPG_TABLE from pte entry

[EMAIL PROTECTED] kirjoitti: KERNPG_TABLE was a bug in earlier patch. Remove it from pte. pte_val() check is redundant as this routine is called immediately after a ptepage is allocated afresh. Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]> Signed-off-by: Suresh Siddha <[EMAIL

Re: [patch 2/4] x86: PAT followup - Remove KERNPG_TABLE from pte entry

[EMAIL PROTECTED] kirjoitti: KERNPG_TABLE was a bug in earlier patch. Remove it from pte. pte_val() check is redundant as this routine is called immediately after a ptepage is allocated afresh. Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED] Signed-off-by: Suresh Siddha [EMAIL PROTECTED]

Re: [PATCH -mm 1/2] wait_task_stopped: remove unneeded delay_group_leader check

wait_task_stopped() doesn't need the "delay_group_leader" parameter. If the child is not traced it must be a group leader. With or without subthreads What do you mean "has to be a group leader"? It could be a stopped thread. ->group_stop_count == 0 when the whole task is stopped.

Re: [PATCH -mm 1/2] wait_task_stopped: remove unneeded delay_group_leader check

wait_task_stopped() doesn't need the delay_group_leader parameter. If the child is not traced it must be a group leader. With or without subthreads What do you mean has to be a group leader? It could be a stopped thread. -group_stop_count == 0 when the whole task is stopped.

Re: nmi_watchdog fix for x86_64 to be more like i386

Thomas Gleixner wrote: On Tue, 2 Oct 2007, Andi Kleen wrote: OTOH, the accounting hook would allow us to remove the IRQ#0 -> CPU#0 restriction. Not sure whether it's worth the trouble. Some SIS chipsets hang the machine when you migrate irq 0 to another CPU. It's better to keep that

Re: nmi_watchdog fix for x86_64 to be more like i386

Thomas Gleixner wrote: On Tue, 2 Oct 2007, Andi Kleen wrote: OTOH, the accounting hook would allow us to remove the IRQ#0 - CPU#0 restriction. Not sure whether it's worth the trouble. Some SIS chipsets hang the machine when you migrate irq 0 to another CPU. It's better to keep that

Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3

huang ying wrote: On 9/21/07, Mika Penttilä <[EMAIL PROTECTED]> wrote: huang ying wrote: On 9/21/07, Mika Penttilä <[EMAIL PROTECTED]> wrote: Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, bu

Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3

huang ying wrote: On 9/21/07, Mika Penttilä <[EMAIL PROTECTED]> wrote: Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced

Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3

Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image CONFIG_PM=y CONFIG_KEXEC_JUMP=y 2. Download

Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3

Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image CONFIG_PM=y CONFIG_KEXEC_JUMP=y 2. Download

Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3

huang ying wrote: On 9/21/07, Mika Penttilä [EMAIL PROTECTED] wrote: Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel

Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3

huang ying wrote: On 9/21/07, Mika Penttilä [EMAIL PROTECTED] wrote: huang ying wrote: On 9/21/07, Mika Penttilä [EMAIL PROTECTED] wrote: Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more

Re: [RFC] Crash on modpost, addend_386_rel()

Atsushi Nemoto wrote: On Tue, 22 May 2007 17:48:09 +0300, Mika_Penttilä <[EMAIL PROTECTED]> wrote: I can't see how this use of r_attend is going to work. find_elf_symbol compares relsym->st_value to Elf_Rela->r_attend. I think it doesn't work for RELA archs and even with this patch for REL.

Re: [RFC] Crash on modpost, addend_386_rel()

Atsushi Nemoto wrote: On Tue, 22 May 2007 17:48:09 +0300, Mika_Penttilä [EMAIL PROTECTED] wrote: I can't see how this use of r_attend is going to work. find_elf_symbol compares relsym-st_value to Elf_Rela-r_attend. I think it doesn't work for RELA archs and even with this patch for REL.

Re: [RFC] Crash on modpost, addend_386_rel()

Atsushi Nemoto kirjoitti: On Tue, 22 May 2007 14:29:29 +0900 (JST), Atsushi Nemoto <[EMAIL PROTECTED]> wrote: Subject: [PATCH] kbuild: make better section mismatch reports on i386, arm and mips (take 3) Updated again to get a little bit better report on i386 relocatable vmlinux.

Re: [RFC] Crash on modpost, addend_386_rel()

Atsushi Nemoto kirjoitti: On Tue, 22 May 2007 14:29:29 +0900 (JST), Atsushi Nemoto [EMAIL PROTECTED] wrote: Subject: [PATCH] kbuild: make better section mismatch reports on i386, arm and mips (take 3) Updated again to get a little bit better report on i386 relocatable vmlinux.

Re: [PATCH 13/14] x86_64 irq: Safely cleanup an irq after moving it.

Eric W. Biederman wrote: * Vectors 0x20-0x2f are used for ISA interrupts. */ -#define IRQ0_VECTORFIRST_EXTERNAL_VECTOR +#define IRQ0_VECTORFIRST_EXTERNAL_VECTOR + 0x10 #define IRQ1_VECTORIRQ0_VECTOR + 1 #define IRQ2_VECTORIRQ0_VECTOR + 2

Re: [PATCH 13/14] x86_64 irq: Safely cleanup an irq after moving it.

Eric W. Biederman wrote: * Vectors 0x20-0x2f are used for ISA interrupts. */ -#define IRQ0_VECTORFIRST_EXTERNAL_VECTOR +#define IRQ0_VECTORFIRST_EXTERNAL_VECTOR + 0x10 #define IRQ1_VECTORIRQ0_VECTOR + 1 #define IRQ2_VECTORIRQ0_VECTOR + 2

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

Al Viro wrote: On Fri, Aug 19, 2005 at 10:16:47PM +0300, Mika Penttilä wrote: Just out of curiosity - what protects even local filesystems against concurrent truncate and symlink resolving when using the page cache helpers? How do you get truncate(2) or ftruncate(2) to do something

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

Al Viro wrote: On Fri, Aug 19, 2005 at 05:53:32PM +0100, Al Viro wrote: I'm taking NFS helpers to libfs.c and switching ncpfs to them. IMO that's better than copying the damn thing and other network filesystems might have the same needs eventually... [something like this -

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

Al Viro wrote: On Fri, Aug 19, 2005 at 05:53:32PM +0100, Al Viro wrote: I'm taking NFS helpers to libfs.c and switching ncpfs to them. IMO that's better than copying the damn thing and other network filesystems might have the same needs eventually... [something like this -

Re: Kernel bug: Bad page state: related to generic symlink code and mmap

Al Viro wrote: On Fri, Aug 19, 2005 at 10:16:47PM +0300, Mika Penttilä wrote: Just out of curiosity - what protects even local filesystems against concurrent truncate and symlink resolving when using the page cache helpers? How do you get truncate(2) or ftruncate(2) to do something

<    1   2