* Dynamic ftrace self test broken on ARM
@ 2018-06-18 21:09 Stefan Agner
2018-06-18 21:54 ` Steven Rostedt
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Agner @ 2018-06-18 21:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On a ARM (i.MX 7) I noticed today that the kernel crashes after dynamic
ftrace self test. I tried v4.18-rc1 first, but it seems that at least
also v4.17 is affected.
Booting Linux on physical CPU 0x0
Linux version 4.17.0 (ags at trochilidae) (gcc version 7.2.1 20171011
(Linaro GCC 7.2-2017.11)) #564 SMP Mon Jun 18 23:00:48 CEST 2018
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
CPU: div instructions available: patching division code
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt: Machine model: Toradex Colibri iMX7D 1GB (eMMC) on Colibri
Evaluation Board V3
bootconsole [earlycon0] enabled
Memory policy: Data cache writealloc
Ignoring RAM at 0xb0000000-0xc0000000
Consider using a HIGHMEM enabled kernel.
cma: Reserved 256 MiB at 0xa0000000
psci: probing for conduit method from DT.
psci: Using PSCI v0.1 Function IDs from DT
percpu: Embedded 17 pages/cpu @(ptrval) s39308 r8192 d22132 u69632
Built 1 zonelists, mobility grouping on. Total pages: 195072
Kernel command line: earlyprintk root=/dev/mmcblk0p2 rootfstype=ext4
rootwait ip=off console=tty1 console=ttymxc0,115200n8 ${extraargs}
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 501152K/786432K available (9216K kernel code, 682K rwdata, 3016K
rodata, 1024K init, 397K bss, 23136K reserved, 262144K cma-reserved)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xf0800000 - 0xff800000 ( 240 MB)
lowmem : 0xc0000000 - 0xf0000000 ( 768 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0x(ptrval) - 0x(ptrval) (10208 kB)
.init : 0x(ptrval) - 0x(ptrval) (1024 kB)
.data : 0x(ptrval) - 0x(ptrval) ( 683 kB)
.bss : 0x(ptrval) - 0x(ptrval) ( 398 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
ftrace: allocating 32657 entries in 96 pages
Hierarchical RCU implementation.
RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
GIC: Using split EOI/Deactivate mode
arch_timer: cp15 timer(s) running at 8.00MHz (phys).
clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles:
0x1d854df40, max_idle_ns: 440795202120 ns
sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every
2199023255500ns
Switching to timer-based delay loop, resolution 125ns
Switching to timer-based delay loop, resolution 41ns
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
89478484971ns
clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 79635851949 ns
Console: colour dummy device 80x30
console [tty1] enabled
Calibrating delay loop (skipped), value calculated using timer
frequency.. 48.00 BogoMIPS (lpj=240000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: update cpu_capacity 1024
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x80100000 - 0x80100060
Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...
CPU1: update cpu_capacity 1024
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
smp: Brought up 1 node, 2 CPUs
SMP: Total of 2 processors activated (96.00 BogoMIPS).
CPU: All CPU(s) started in HYP mode.
CPU: Virtualization extensions available.
devtmpfs: initialized
random: get_random_u32 called from bucket_table_alloc+0x84/0x19c with
crng_init=0
VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 19112604462750000 ns
futex hash table entries: 512 (order: 3, 32768 bytes)
Running postponed tracer tests:
Testing tracer function: PASSED
Testing dynamic ftrace: PASSED
Testing dynamic ftrace ops #1:
(1 0 1 0 0)
(1 1 2 0 0)
(2 1 3 0 93620)
(2 2 4 0 93807) PASSED
Testing dynamic ftrace ops #2:
(1 0 1 96630 0)
(1 1 2 96804 0)
(2 1 3 1 342)
(2 2 4 121 462) PASSED
Testing ftrace recursion: PASSED
Testing ftrace recursion safe: PASSED
Testing ftrace regs: PASSED
Testing tracer nop: PASSED
Testing tracer function_graph: PASSED
pinctrl core: initialized pinctrl subsystem
Unable to handle kernel paging request at virtual address c0ca14e4
pgd = (ptrval)
[c0ca14e4] *pgd=80c1940e(bad)
Internal error: Oops: 80d [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.17.0 #564
Hardware name: Freescale i.MX7 Dual (Device Tree)
PC is at skb_init+0x50/0x7c
LR is at kmem_cache_create_usercopy+0x10c/0x320
pc : [<c0e63b80>] lr : [<c023bd5c>] psr: 60000013
sp : dc11be98 ip : dc11be58 fp : dc11bebc
r10: c0e006f0 r9 : c0e82820 r8 : c0faa8c0
r7 : c0e63a10 r6 : 00000000 r5 : 00000000 r4 : c0ca14e4
r3 : c0eb72c8 r2 : 00000000 r1 : 1ea8b000 r0 : dc0eef00
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 8000406a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
Stack: (0xdc11be98 to 0xdc11c000)
be80: 00000018
00000030
bea0: 00000000 c07fda4c 00000000 ffffe000 dc11bedc dc11bec0 c0e63a38
c0e63b3c
bec0: c0e5d488 c0170c64 c0fa7140 c0fa7140 dc11bf44 dc11bee0 c0103080
c0e63a1c
bee0: c0145d74 c0e006fc c0bf3c00 c0bf3ca4 c0bf3cf0 c0c03b98 00000000
c0bf3c7c
bf00: 00000001 00000001 c0bf6c04 c0cf0b68 dffffc66 00000000 00000000
c0fa7140
bf20: c0e82844 00000002 c0fa7140 c0eb6264 00000002 c0faa8c0 dc11bf94
dc11bf48
bf40: c0e011d8 c0103038 00000001 00000001 00000000 c0e006f0 00000000
c0f09fc0
bf60: c0cf0b68 000000dc c0989c58 00000000 c0989c58 00000000 00000000
00000000
bf80: 00000000 00000000 dc11bfac dc11bf98 c0989c70 c0e00f74 00000000
c0989c58
bfa0: 00000000 dc11bfb0 c01010e8 c0989c64 00000000 00000000 00000000
00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000
00000000
[<c0e63b80>] (skb_init) from [<c0e63a38>] (sock_init+0x28/0xc8)
[<c0e63a38>] (sock_init) from [<c0103080>] (do_one_initcall+0x54/0x1e8)
[<c0103080>] (do_one_initcall) from [<c0e011d8>]
(kernel_init_freeable+0x270/0x308)
[<c0e011d8>] (kernel_init_freeable) from [<c0989c70>]
(kernel_init+0x18/0x124)
[<c0989c70>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
Exception stack(0xdc11bfb0 to 0xdc11bff8)
bfa0: 00000000 00000000 00000000
00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: e58d3000 e3a010b8 e3a03a42 ebcf6033 (e5840000)
---[ end trace fff84001ba23c9c9 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 2.292924]
CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.17.0 #564
Hardware name: Freescale i.MX7 Dual (Device Tree)
[<c01128a4>] (unwind_backtrace) from [<c010d868>] (show_stack+0x20/0x24)
[<c010d868>] (show_stack) from [<c0975590>] (dump_stack+0x90/0xa4)
[<c0975590>] (dump_stack) from [<c0110608>] (handle_IPI+0x2dc/0x2fc)
[<c0110608>] (handle_IPI) from [<c010233c>] (gic_handle_irq+0x9c/0xa0)
[<c010233c>] (gic_handle_irq) from [<c0101a0c>] (__irq_svc+0x6c/0x90)
Exception stack(0xdc14df18 to 0xdc14df60)
df00: 00000000
00000324
df20: df957420 c011c4c0 ffffe000 c0f05d28 c0f05d6c 00000002 00000000
c0f05d80
df40: 00000000 dc14df74 dc14df78 dc14df68 c0109938 c010993c 60000013
ffffffff
[<c0101a0c>] (__irq_svc) from [<c010993c>] (arch_cpu_idle+0x48/0x4c)
[<c010993c>] (arch_cpu_idle) from [<c098f81c>]
(default_idle_call+0x30/0x3c)
[<c098f81c>] (default_idle_call) from [<c01566a4>] (do_idle+0x1bc/0x284)
[<c01566a4>] (do_idle) from [<c0156a18>] (cpu_startup_entry+0x28/0x30)
[<c0156a18>] (cpu_startup_entry) from [<c01100b0>]
(secondary_start_kernel+0x158/0x164)
[<c01100b0>] (secondary_start_kernel) from [<8010274c>] (0x8010274c)
---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
]---
I tested with imx_v6_v7_defconfig and enabled the following options:
CONFIG_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_FTRACE_MCOUNT_RECORD=y
CONFIG_FTRACE_SELFTEST=y
CONFIG_FTRACE_STARTUP_TEST=y
I guess startup test should leave the kernel unencumbered?
--
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Dynamic ftrace self test broken on ARM
2018-06-18 21:09 Dynamic ftrace self test broken on ARM Stefan Agner
@ 2018-06-18 21:54 ` Steven Rostedt
2018-06-19 8:16 ` Stefan Agner
0 siblings, 1 reply; 13+ messages in thread
From: Steven Rostedt @ 2018-06-18 21:54 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 18 Jun 2018 23:09:04 +0200
Stefan Agner <stefan@agner.ch> wrote:
> Hi,
>
> On a ARM (i.MX 7) I noticed today that the kernel crashes after dynamic
> ftrace self test. I tried v4.18-rc1 first, but it seems that at least
> also v4.17 is affected.
>
> VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
> max_idle_ns: 19112604462750000 ns
> futex hash table entries: 512 (order: 3, 32768 bytes)
> Running postponed tracer tests:
> Testing tracer function: PASSED
> Testing dynamic ftrace: PASSED
> Testing dynamic ftrace ops #1:
> (1 0 1 0 0)
> (1 1 2 0 0)
> (2 1 3 0 93620)
> (2 2 4 0 93807) PASSED
> Testing dynamic ftrace ops #2:
> (1 0 1 96630 0)
> (1 1 2 96804 0)
> (2 1 3 1 342)
> (2 2 4 121 462) PASSED
> Testing ftrace recursion: PASSED
> Testing ftrace recursion safe: PASSED
> Testing ftrace regs: PASSED
> Testing tracer nop: PASSED
> Testing tracer function_graph: PASSED
> pinctrl core: initialized pinctrl subsystem
> Unable to handle kernel paging request at virtual address c0ca14e4
> pgd = (ptrval)
> [c0ca14e4] *pgd=80c1940e(bad)
> Internal error: Oops: 80d [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.17.0 #564
> Hardware name: Freescale i.MX7 Dual (Device Tree)
> PC is at skb_init+0x50/0x7c
> LR is at kmem_cache_create_usercopy+0x10c/0x320
> pc : [<c0e63b80>] lr : [<c023bd5c>] psr: 60000013
> sp : dc11be98 ip : dc11be58 fp : dc11bebc
> r10: c0e006f0 r9 : c0e82820 r8 : c0faa8c0
> r7 : c0e63a10 r6 : 00000000 r5 : 00000000 r4 : c0ca14e4
> r3 : c0eb72c8 r2 : 00000000 r1 : 1ea8b000 r0 : dc0eef00
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 10c5387d Table: 8000406a DAC: 00000051
> Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
> Stack: (0xdc11be98 to 0xdc11c000)
> be80: 00000018
> 00000030
> bea0: 00000000 c07fda4c 00000000 ffffe000 dc11bedc dc11bec0 c0e63a38
> c0e63b3c
> bec0: c0e5d488 c0170c64 c0fa7140 c0fa7140 dc11bf44 dc11bee0 c0103080
> c0e63a1c
> bee0: c0145d74 c0e006fc c0bf3c00 c0bf3ca4 c0bf3cf0 c0c03b98 00000000
> c0bf3c7c
> bf00: 00000001 00000001 c0bf6c04 c0cf0b68 dffffc66 00000000 00000000
> c0fa7140
> bf20: c0e82844 00000002 c0fa7140 c0eb6264 00000002 c0faa8c0 dc11bf94
> dc11bf48
> bf40: c0e011d8 c0103038 00000001 00000001 00000000 c0e006f0 00000000
> c0f09fc0
> bf60: c0cf0b68 000000dc c0989c58 00000000 c0989c58 00000000 00000000
> 00000000
> bf80: 00000000 00000000 dc11bfac dc11bf98 c0989c70 c0e00f74 00000000
> c0989c58
> bfa0: 00000000 dc11bfb0 c01010e8 c0989c64 00000000 00000000 00000000
> 00000000
> bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000
> bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000
> 00000000
> [<c0e63b80>] (skb_init) from [<c0e63a38>] (sock_init+0x28/0xc8)
> [<c0e63a38>] (sock_init) from [<c0103080>] (do_one_initcall+0x54/0x1e8)
> [<c0103080>] (do_one_initcall) from [<c0e011d8>]
> (kernel_init_freeable+0x270/0x308)
> [<c0e011d8>] (kernel_init_freeable) from [<c0989c70>]
> (kernel_init+0x18/0x124)
> [<c0989c70>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
> Exception stack(0xdc11bfb0 to 0xdc11bff8)
> bfa0: 00000000 00000000 00000000
> 00000000
> bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000
> bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> Code: e58d3000 e3a010b8 e3a03a42 ebcf6033 (e5840000)
> ---[ end trace fff84001ba23c9c9 ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [ 2.292924]
> CPU1: stopping
> CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.17.0 #564
> Hardware name: Freescale i.MX7 Dual (Device Tree)
> [<c01128a4>] (unwind_backtrace) from [<c010d868>] (show_stack+0x20/0x24)
> [<c010d868>] (show_stack) from [<c0975590>] (dump_stack+0x90/0xa4)
> [<c0975590>] (dump_stack) from [<c0110608>] (handle_IPI+0x2dc/0x2fc)
> [<c0110608>] (handle_IPI) from [<c010233c>] (gic_handle_irq+0x9c/0xa0)
> [<c010233c>] (gic_handle_irq) from [<c0101a0c>] (__irq_svc+0x6c/0x90)
> Exception stack(0xdc14df18 to 0xdc14df60)
> df00: 00000000
> 00000324
> df20: df957420 c011c4c0 ffffe000 c0f05d28 c0f05d6c 00000002 00000000
> c0f05d80
> df40: 00000000 dc14df74 dc14df78 dc14df68 c0109938 c010993c 60000013
> ffffffff
> [<c0101a0c>] (__irq_svc) from [<c010993c>] (arch_cpu_idle+0x48/0x4c)
> [<c010993c>] (arch_cpu_idle) from [<c098f81c>]
> (default_idle_call+0x30/0x3c)
> [<c098f81c>] (default_idle_call) from [<c01566a4>] (do_idle+0x1bc/0x284)
> [<c01566a4>] (do_idle) from [<c0156a18>] (cpu_startup_entry+0x28/0x30)
> [<c0156a18>] (cpu_startup_entry) from [<c01100b0>]
> (secondary_start_kernel+0x158/0x164)
> [<c01100b0>] (secondary_start_kernel) from [<8010274c>] (0x8010274c)
> ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b
> ]---
>
> I tested with imx_v6_v7_defconfig and enabled the following options:
>
> CONFIG_DYNAMIC_FTRACE=y
>
> CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
>
> CONFIG_FTRACE_MCOUNT_RECORD=y
>
> CONFIG_FTRACE_SELFTEST=y
>
> CONFIG_FTRACE_STARTUP_TEST=y
>
> I guess startup test should leave the kernel unencumbered?
>
>
I'm guessing that it boots fine with CONFIG_FTRACE_STARTUP_TEST=n? Can
you try disable the tracers to see if it's the function graph or
function tracer that is causing the issue? That is, turn off
CONFIG_FUNCTION_GRAPH_TRACER and test it again, and if that crashes,
turn off CONFIG_FUNCTION_TRACER to make sure the crash goes away there
too.
-- Steve
^ permalink raw reply [flat|nested] 13+ messages in thread
* Dynamic ftrace self test broken on ARM
2018-06-18 21:54 ` Steven Rostedt
@ 2018-06-19 8:16 ` Stefan Agner
2018-06-19 13:17 ` Steven Rostedt
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Agner @ 2018-06-19 8:16 UTC (permalink / raw)
To: linux-arm-kernel
On 18.06.2018 23:54, Steven Rostedt wrote:
> On Mon, 18 Jun 2018 23:09:04 +0200
> Stefan Agner <stefan@agner.ch> wrote:
>
>> Hi,
>>
>> On a ARM (i.MX 7) I noticed today that the kernel crashes after dynamic
>> ftrace self test. I tried v4.18-rc1 first, but it seems that at least
>> also v4.17 is affected.
>>
>
>
>> VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
>> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
>> max_idle_ns: 19112604462750000 ns
>> futex hash table entries: 512 (order: 3, 32768 bytes)
>> Running postponed tracer tests:
>> Testing tracer function: PASSED
>> Testing dynamic ftrace: PASSED
>> Testing dynamic ftrace ops #1:
>> (1 0 1 0 0)
>> (1 1 2 0 0)
>> (2 1 3 0 93620)
>> (2 2 4 0 93807) PASSED
>> Testing dynamic ftrace ops #2:
>> (1 0 1 96630 0)
>> (1 1 2 96804 0)
>> (2 1 3 1 342)
>> (2 2 4 121 462) PASSED
>> Testing ftrace recursion: PASSED
>> Testing ftrace recursion safe: PASSED
>> Testing ftrace regs: PASSED
>> Testing tracer nop: PASSED
>> Testing tracer function_graph: PASSED
>> pinctrl core: initialized pinctrl subsystem
>> Unable to handle kernel paging request at virtual address c0ca14e4
>> pgd = (ptrval)
>> [c0ca14e4] *pgd=80c1940e(bad)
>> Internal error: Oops: 80d [#1] SMP ARM
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.17.0 #564
>> Hardware name: Freescale i.MX7 Dual (Device Tree)
>> PC is at skb_init+0x50/0x7c
>> LR is at kmem_cache_create_usercopy+0x10c/0x320
>> pc : [<c0e63b80>] lr : [<c023bd5c>] psr: 60000013
>> sp : dc11be98 ip : dc11be58 fp : dc11bebc
>> r10: c0e006f0 r9 : c0e82820 r8 : c0faa8c0
>> r7 : c0e63a10 r6 : 00000000 r5 : 00000000 r4 : c0ca14e4
>> r3 : c0eb72c8 r2 : 00000000 r1 : 1ea8b000 r0 : dc0eef00
>> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
>> Control: 10c5387d Table: 8000406a DAC: 00000051
>> Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
>> Stack: (0xdc11be98 to 0xdc11c000)
>> be80: 00000018
>> 00000030
>> bea0: 00000000 c07fda4c 00000000 ffffe000 dc11bedc dc11bec0 c0e63a38
>> c0e63b3c
>> bec0: c0e5d488 c0170c64 c0fa7140 c0fa7140 dc11bf44 dc11bee0 c0103080
>> c0e63a1c
>> bee0: c0145d74 c0e006fc c0bf3c00 c0bf3ca4 c0bf3cf0 c0c03b98 00000000
>> c0bf3c7c
>> bf00: 00000001 00000001 c0bf6c04 c0cf0b68 dffffc66 00000000 00000000
>> c0fa7140
>> bf20: c0e82844 00000002 c0fa7140 c0eb6264 00000002 c0faa8c0 dc11bf94
>> dc11bf48
>> bf40: c0e011d8 c0103038 00000001 00000001 00000000 c0e006f0 00000000
>> c0f09fc0
>> bf60: c0cf0b68 000000dc c0989c58 00000000 c0989c58 00000000 00000000
>> 00000000
>> bf80: 00000000 00000000 dc11bfac dc11bf98 c0989c70 c0e00f74 00000000
>> c0989c58
>> bfa0: 00000000 dc11bfb0 c01010e8 c0989c64 00000000 00000000 00000000
>> 00000000
>> bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000
>> 00000000
>> [<c0e63b80>] (skb_init) from [<c0e63a38>] (sock_init+0x28/0xc8)
>> [<c0e63a38>] (sock_init) from [<c0103080>] (do_one_initcall+0x54/0x1e8)
>> [<c0103080>] (do_one_initcall) from [<c0e011d8>]
>> (kernel_init_freeable+0x270/0x308)
>> [<c0e011d8>] (kernel_init_freeable) from [<c0989c70>]
>> (kernel_init+0x18/0x124)
>> [<c0989c70>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
>> Exception stack(0xdc11bfb0 to 0xdc11bff8)
>> bfa0: 00000000 00000000 00000000
>> 00000000
>> bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
>> Code: e58d3000 e3a010b8 e3a03a42 ebcf6033 (e5840000)
>> ---[ end trace fff84001ba23c9c9 ]---
>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>> [ 2.292924]
>> CPU1: stopping
>> CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.17.0 #564
>> Hardware name: Freescale i.MX7 Dual (Device Tree)
>> [<c01128a4>] (unwind_backtrace) from [<c010d868>] (show_stack+0x20/0x24)
>> [<c010d868>] (show_stack) from [<c0975590>] (dump_stack+0x90/0xa4)
>> [<c0975590>] (dump_stack) from [<c0110608>] (handle_IPI+0x2dc/0x2fc)
>> [<c0110608>] (handle_IPI) from [<c010233c>] (gic_handle_irq+0x9c/0xa0)
>> [<c010233c>] (gic_handle_irq) from [<c0101a0c>] (__irq_svc+0x6c/0x90)
>> Exception stack(0xdc14df18 to 0xdc14df60)
>> df00: 00000000
>> 00000324
>> df20: df957420 c011c4c0 ffffe000 c0f05d28 c0f05d6c 00000002 00000000
>> c0f05d80
>> df40: 00000000 dc14df74 dc14df78 dc14df68 c0109938 c010993c 60000013
>> ffffffff
>> [<c0101a0c>] (__irq_svc) from [<c010993c>] (arch_cpu_idle+0x48/0x4c)
>> [<c010993c>] (arch_cpu_idle) from [<c098f81c>]
>> (default_idle_call+0x30/0x3c)
>> [<c098f81c>] (default_idle_call) from [<c01566a4>] (do_idle+0x1bc/0x284)
>> [<c01566a4>] (do_idle) from [<c0156a18>] (cpu_startup_entry+0x28/0x30)
>> [<c0156a18>] (cpu_startup_entry) from [<c01100b0>]
>> (secondary_start_kernel+0x158/0x164)
>> [<c01100b0>] (secondary_start_kernel) from [<8010274c>] (0x8010274c)
>> ---[ end Kernel panic - not syncing: Attempted to kill init!
>> exitcode=0x0000000b
>> ]---
>>
>> I tested with imx_v6_v7_defconfig and enabled the following options:
>>
>> CONFIG_DYNAMIC_FTRACE=y
>>
>> CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
>>
>> CONFIG_FTRACE_MCOUNT_RECORD=y
>>
>> CONFIG_FTRACE_SELFTEST=y
>>
>> CONFIG_FTRACE_STARTUP_TEST=y
>>
>> I guess startup test should leave the kernel unencumbered?
>>
>>
>
> I'm guessing that it boots fine with CONFIG_FTRACE_STARTUP_TEST=n? Can
> you try disable the tracers to see if it's the function graph or
> function tracer that is causing the issue? That is, turn off
> CONFIG_FUNCTION_GRAPH_TRACER and test it again, and if that crashes,
> turn off CONFIG_FUNCTION_TRACER to make sure the crash goes away there
> too.
Without CONFIG_FTRACE_STARTUP_TEST the kernel boots fine.
CONFIG_FUNCTION_TRACER=y
# CONFIG_FUNCTION_GRAPH_TRACER is not set
# CONFIG_SCHED_TRACER is not set
CONFIG_FTRACE_STARTUP_TEST=y
Crashes with the same stack trace.
# CONFIG_FUNCTION_TRACER is not set
CONFIG_SCHED_TRACER=y
CONFIG_FTRACE_STARTUP_TEST=y
Runs tracer tests and boots fine.
--
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Dynamic ftrace self test broken on ARM
2018-06-19 8:16 ` Stefan Agner
@ 2018-06-19 13:17 ` Steven Rostedt
2018-06-20 13:51 ` Stefan Agner
0 siblings, 1 reply; 13+ messages in thread
From: Steven Rostedt @ 2018-06-19 13:17 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 19 Jun 2018 10:16:19 +0200
Stefan Agner <stefan@agner.ch> wrote:
> > I'm guessing that it boots fine with CONFIG_FTRACE_STARTUP_TEST=n? Can
> > you try disable the tracers to see if it's the function graph or
> > function tracer that is causing the issue? That is, turn off
> > CONFIG_FUNCTION_GRAPH_TRACER and test it again, and if that crashes,
> > turn off CONFIG_FUNCTION_TRACER to make sure the crash goes away there
> > too.
>
> Without CONFIG_FTRACE_STARTUP_TEST the kernel boots fine.
>
> CONFIG_FUNCTION_TRACER=y
> # CONFIG_FUNCTION_GRAPH_TRACER is not set
> # CONFIG_SCHED_TRACER is not set
> CONFIG_FTRACE_STARTUP_TEST=y
OK, so it's not a graph tracer issue, but a function tracer issue.
>
> Crashes with the same stack trace.
>
> # CONFIG_FUNCTION_TRACER is not set
> CONFIG_SCHED_TRACER=y
> CONFIG_FTRACE_STARTUP_TEST=y
>
> Runs tracer tests and boots fine.
Thanks. Did this ever work? And if so, perhaps you have time to perform
a bisect. If you have a ktest setup, you can have it run the bisect for
you (over night).
-- Steve
^ permalink raw reply [flat|nested] 13+ messages in thread
* Dynamic ftrace self test broken on ARM
2018-06-19 13:17 ` Steven Rostedt
@ 2018-06-20 13:51 ` Stefan Agner
2018-06-20 14:13 ` Steven Rostedt
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Agner @ 2018-06-20 13:51 UTC (permalink / raw)
To: linux-arm-kernel
On 19.06.2018 15:17, Steven Rostedt wrote:
> On Tue, 19 Jun 2018 10:16:19 +0200
> Stefan Agner <stefan@agner.ch> wrote:
>
>> > I'm guessing that it boots fine with CONFIG_FTRACE_STARTUP_TEST=n? Can
>> > you try disable the tracers to see if it's the function graph or
>> > function tracer that is causing the issue? That is, turn off
>> > CONFIG_FUNCTION_GRAPH_TRACER and test it again, and if that crashes,
>> > turn off CONFIG_FUNCTION_TRACER to make sure the crash goes away there
>> > too.
>>
>> Without CONFIG_FTRACE_STARTUP_TEST the kernel boots fine.
>>
>> CONFIG_FUNCTION_TRACER=y
>> # CONFIG_FUNCTION_GRAPH_TRACER is not set
>> # CONFIG_SCHED_TRACER is not set
>> CONFIG_FTRACE_STARTUP_TEST=y
>
> OK, so it's not a graph tracer issue, but a function tracer issue.
>
>>
>> Crashes with the same stack trace.
>>
>> # CONFIG_FUNCTION_TRACER is not set
>> CONFIG_SCHED_TRACER=y
>> CONFIG_FTRACE_STARTUP_TEST=y
>>
>> Runs tracer tests and boots fine.
>
> Thanks. Did this ever work? And if so, perhaps you have time to perform
> a bisect. If you have a ktest setup, you can have it run the bisect for
> you (over night).
v4.9 seems to work, so I started bisecting. It turned out that commit
6f05d0761af6 ("ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA
and !FRAME_POINTER") broke it, introduced during the v4.12 merge window.
I did not look closer into it yet.
Abel, maybe you see what is going on here?
--
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Dynamic ftrace self test broken on ARM
2018-06-20 13:51 ` Stefan Agner
@ 2018-06-20 14:13 ` Steven Rostedt
2018-06-20 19:06 ` Stefan Agner
0 siblings, 1 reply; 13+ messages in thread
From: Steven Rostedt @ 2018-06-20 14:13 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 20 Jun 2018 15:51:55 +0200
Stefan Agner <stefan@agner.ch> wrote:
> v4.9 seems to work, so I started bisecting. It turned out that commit
> 6f05d0761af6 ("ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA
> and !FRAME_POINTER") broke it, introduced during the v4.12 merge window.
That patch doesn't appear to be the cause. It could have been a failed
bisect. Does the commit before that commit work? Does that commit fail?
It may be due to some other RODATA change though. That is actually one
of my thoughts when looking at the bug.
-- Steve
^ permalink raw reply [flat|nested] 13+ messages in thread
* Dynamic ftrace self test broken on ARM
2018-06-20 14:13 ` Steven Rostedt
@ 2018-06-20 19:06 ` Stefan Agner
2018-06-20 21:32 ` Stefan Agner
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Agner @ 2018-06-20 19:06 UTC (permalink / raw)
To: linux-arm-kernel
On 20.06.2018 16:13, Steven Rostedt wrote:
> On Wed, 20 Jun 2018 15:51:55 +0200
> Stefan Agner <stefan@agner.ch> wrote:
>
>
>> v4.9 seems to work, so I started bisecting. It turned out that commit
>> 6f05d0761af6 ("ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA
>> and !FRAME_POINTER") broke it, introduced during the v4.12 merge window.
>
> That patch doesn't appear to be the cause. It could have been a failed
> bisect. Does the commit before that commit work? Does that commit fail?
Pretty sure it is that one. Reverting it on top of v4.18-rc1 fixes it...
>
> It may be due to some other RODATA change though. That is actually one
> of my thoughts when looking at the bug.
CONFIG_STRICT_KERNEL_RWX=y is set, will test without.
--
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Dynamic ftrace self test broken on ARM
2018-06-20 19:06 ` Stefan Agner
@ 2018-06-20 21:32 ` Stefan Agner
2018-06-20 22:45 ` Stefan Agner
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Agner @ 2018-06-20 21:32 UTC (permalink / raw)
To: linux-arm-kernel
On 20.06.2018 21:06, Stefan Agner wrote:
> On 20.06.2018 16:13, Steven Rostedt wrote:
>> On Wed, 20 Jun 2018 15:51:55 +0200
>> Stefan Agner <stefan@agner.ch> wrote:
>>
>>
>>> v4.9 seems to work, so I started bisecting. It turned out that commit
>>> 6f05d0761af6 ("ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA
>>> and !FRAME_POINTER") broke it, introduced during the v4.12 merge window.
>>
>> That patch doesn't appear to be the cause. It could have been a failed
>> bisect. Does the commit before that commit work? Does that commit fail?
>
> Pretty sure it is that one. Reverting it on top of v4.18-rc1 fixes it...
>
>>
>> It may be due to some other RODATA change though. That is actually one
>> of my thoughts when looking at the bug.
>
> CONFIG_STRICT_KERNEL_RWX=y is set, will test without.
Compiling without CONFIG_STRICT_KERNEL_RWX fixes the issue too. So seems
to be a RODATA issue...
--
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Dynamic ftrace self test broken on ARM
2018-06-20 21:32 ` Stefan Agner
@ 2018-06-20 22:45 ` Stefan Agner
2018-06-20 23:07 ` Russell King - ARM Linux
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Agner @ 2018-06-20 22:45 UTC (permalink / raw)
To: linux-arm-kernel
On 20.06.2018 23:32, Stefan Agner wrote:
> On 20.06.2018 21:06, Stefan Agner wrote:
>> On 20.06.2018 16:13, Steven Rostedt wrote:
>>> On Wed, 20 Jun 2018 15:51:55 +0200
>>> Stefan Agner <stefan@agner.ch> wrote:
>>>
>>>
>>>> v4.9 seems to work, so I started bisecting. It turned out that commit
>>>> 6f05d0761af6 ("ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA
>>>> and !FRAME_POINTER") broke it, introduced during the v4.12 merge window.
>>>
>>> That patch doesn't appear to be the cause. It could have been a failed
>>> bisect. Does the commit before that commit work? Does that commit fail?
>>
>> Pretty sure it is that one. Reverting it on top of v4.18-rc1 fixes it...
>>
>>>
>>> It may be due to some other RODATA change though. That is actually one
>>> of my thoughts when looking at the bug.
>>
>> CONFIG_STRICT_KERNEL_RWX=y is set, will test without.
>
> Compiling without CONFIG_STRICT_KERNEL_RWX fixes the issue too. So seems
> to be a RODATA issue...
Ok, I understand the issue now:
In ARM ftrace we set kernel text to RW and back to RO in
arch_ftrace_update_code.
ARM sets the kernel at free_initmem to RO. So using ftrace selftest sets
the kernel text to RO much earlier, which seems to cause issues.
Reverting the above commit actually fixes selftests during boot, but it
breaks ftrace at runtime...
This resolves the issue:
+static int __ftrace_modify_code_boot(void *data)
+{
+ int *command = data;
+
+ ftrace_modify_all_code(*command);
+
+ return 0;
+}
+
void arch_ftrace_update_code(int command)
{
- stop_machine(__ftrace_modify_code, &command, NULL);
+ if (system_state < SYSTEM_RUNNING)
+ stop_machine(__ftrace_modify_code_boot, &command, NULL);
+ else
+ stop_machine(__ftrace_modify_code, &command, NULL);
}
Using system_state to indicate whether fix_kernmem_perms has been called
is rather brittle...
Any input from ARM folks?
--
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Dynamic ftrace self test broken on ARM
2018-06-20 22:45 ` Stefan Agner
@ 2018-06-20 23:07 ` Russell King - ARM Linux
2018-06-21 1:29 ` Steven Rostedt
0 siblings, 1 reply; 13+ messages in thread
From: Russell King - ARM Linux @ 2018-06-20 23:07 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jun 21, 2018 at 12:45:04AM +0200, Stefan Agner wrote:
> On 20.06.2018 23:32, Stefan Agner wrote:
> > On 20.06.2018 21:06, Stefan Agner wrote:
> >> On 20.06.2018 16:13, Steven Rostedt wrote:
> >>> On Wed, 20 Jun 2018 15:51:55 +0200
> >>> Stefan Agner <stefan@agner.ch> wrote:
> >>>
> >>>
> >>>> v4.9 seems to work, so I started bisecting. It turned out that commit
> >>>> 6f05d0761af6 ("ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA
> >>>> and !FRAME_POINTER") broke it, introduced during the v4.12 merge window.
> >>>
> >>> That patch doesn't appear to be the cause. It could have been a failed
> >>> bisect. Does the commit before that commit work? Does that commit fail?
> >>
> >> Pretty sure it is that one. Reverting it on top of v4.18-rc1 fixes it...
> >>
> >>>
> >>> It may be due to some other RODATA change though. That is actually one
> >>> of my thoughts when looking at the bug.
> >>
> >> CONFIG_STRICT_KERNEL_RWX=y is set, will test without.
> >
> > Compiling without CONFIG_STRICT_KERNEL_RWX fixes the issue too. So seems
> > to be a RODATA issue...
>
> Ok, I understand the issue now:
>
> In ARM ftrace we set kernel text to RW and back to RO in
> arch_ftrace_update_code.
>
> ARM sets the kernel at free_initmem to RO. So using ftrace selftest sets
> the kernel text to RO much earlier, which seems to cause issues.
>
> Reverting the above commit actually fixes selftests during boot, but it
> breaks ftrace at runtime...
>
> This resolves the issue:
>
> +static int __ftrace_modify_code_boot(void *data)
> +{
> + int *command = data;
> +
> + ftrace_modify_all_code(*command);
> +
> + return 0;
> +}
> +
> void arch_ftrace_update_code(int command)
> {
> - stop_machine(__ftrace_modify_code, &command, NULL);
> + if (system_state < SYSTEM_RUNNING)
> + stop_machine(__ftrace_modify_code_boot, &command, NULL);
> + else
> + stop_machine(__ftrace_modify_code, &command, NULL);
> }
>
> Using system_state to indicate whether fix_kernmem_perms has been called
> is rather brittle...
>
> Any input from ARM folks?
The same issues must exist on other architectures as ARM is not the only
architecture to implement read-only kernel text and dynamic ftrace, so
surely this problem isn't unique to ARM.
It looks to me like x86 sets ARCH_HAS_STRICT_KERNEL_RWX, so surely the
kernel text there is protected against modification of the kernel text.
x86 seems to use probe_kernel_write() in the ftrace code, but I don't
see how that would succeed with ARCH_HAS_STRICT_KERNEL_RWX. Does
dynamic ftrace work on x86, if so, how?
It looks like powerpc also supports the combination, but again I don't
see anything obvious that suggests how it gets around the kernel text
read-only-ness.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply [flat|nested] 13+ messages in thread
* Dynamic ftrace self test broken on ARM
2018-06-20 23:07 ` Russell King - ARM Linux
@ 2018-06-21 1:29 ` Steven Rostedt
2018-06-21 7:25 ` Stefan Agner
0 siblings, 1 reply; 13+ messages in thread
From: Steven Rostedt @ 2018-06-21 1:29 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 21 Jun 2018 00:07:34 +0100
Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
> > Any input from ARM folks?
>
> The same issues must exist on other architectures as ARM is not the only
> architecture to implement read-only kernel text and dynamic ftrace, so
> surely this problem isn't unique to ARM.
Probably because of the way set_kernel_text_ro() is implemented in
other archs. For example, in x86, we have:
void set_kernel_text_ro(void)
{
unsigned long start = PFN_ALIGN(_text);
unsigned long end = PFN_ALIGN(__stop___ex_table);
if (!kernel_set_to_readonly)
return;
/*
* Set the kernel identity mapping for text RO.
*/
set_memory_ro(start, (end - start) >> PAGE_SHIFT);
}
and arm has:
void set_kernel_text_ro(void)
{
set_section_perms(ro_perms, ARRAY_SIZE(ro_perms), true,
current->active_mm);
}
Where x86's set_kernel_text_ro() is a nop until the
kernel_set_to_readonly is set.
Perhaps this may fix things?
[ Not even compiled tested ]
-- Steve
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index c186474422f3..0cc8e04295a4 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -736,20 +736,29 @@ static int __mark_rodata_ro(void *unused)
return 0;
}
+static int kernel_set_to_readonly __read_mostly;
+
void mark_rodata_ro(void)
{
+ kernel_set_to_readonly = 1;
stop_machine(__mark_rodata_ro, NULL, NULL);
debug_checkwx();
}
void set_kernel_text_rw(void)
{
+ if (!kernel_set_to_readonly)
+ return;
+
set_section_perms(ro_perms, ARRAY_SIZE(ro_perms), false,
current->active_mm);
}
void set_kernel_text_ro(void)
{
+ if (!kernel_set_to_readonly)
+ return;
+
set_section_perms(ro_perms, ARRAY_SIZE(ro_perms), true,
current->active_mm);
}
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Dynamic ftrace self test broken on ARM
2018-06-21 1:29 ` Steven Rostedt
@ 2018-06-21 7:25 ` Stefan Agner
2018-06-21 13:51 ` Steven Rostedt
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Agner @ 2018-06-21 7:25 UTC (permalink / raw)
To: linux-arm-kernel
On 21.06.2018 03:29, Steven Rostedt wrote:
> On Thu, 21 Jun 2018 00:07:34 +0100
> Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
>
>
>> > Any input from ARM folks?
>>
>> The same issues must exist on other architectures as ARM is not the only
>> architecture to implement read-only kernel text and dynamic ftrace, so
>> surely this problem isn't unique to ARM.
>
> Probably because of the way set_kernel_text_ro() is implemented in
> other archs. For example, in x86, we have:
>
> void set_kernel_text_ro(void)
> {
> unsigned long start = PFN_ALIGN(_text);
> unsigned long end = PFN_ALIGN(__stop___ex_table);
>
> if (!kernel_set_to_readonly)
> return;
>
> /*
> * Set the kernel identity mapping for text RO.
> */
> set_memory_ro(start, (end - start) >> PAGE_SHIFT);
> }
>
> and arm has:
>
> void set_kernel_text_ro(void)
> {
> set_section_perms(ro_perms, ARRAY_SIZE(ro_perms), true,
> current->active_mm);
> }
>
> Where x86's set_kernel_text_ro() is a nop until the
> kernel_set_to_readonly is set.
>
> Perhaps this may fix things?
>
> [ Not even compiled tested ]
>
> -- Steve
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index c186474422f3..0cc8e04295a4 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -736,20 +736,29 @@ static int __mark_rodata_ro(void *unused)
> return 0;
> }
>
> +static int kernel_set_to_readonly __read_mostly;
> +
> void mark_rodata_ro(void)
> {
> + kernel_set_to_readonly = 1;
> stop_machine(__mark_rodata_ro, NULL, NULL);
> debug_checkwx();
> }
>
> void set_kernel_text_rw(void)
> {
> + if (!kernel_set_to_readonly)
> + return;
> +
> set_section_perms(ro_perms, ARRAY_SIZE(ro_perms), false,
> current->active_mm);
> }
>
> void set_kernel_text_ro(void)
> {
> + if (!kernel_set_to_readonly)
> + return;
> +
> set_section_perms(ro_perms, ARRAY_SIZE(ro_perms), true,
> current->active_mm);
> }
This aligns nicely with how this has been solved with commit
162396309745 ("ftrace, x86: make kernel text writable only for
conversions") a while ago.
Reviewed-by: Stefan Agner <stefan@agner.ch>
Compiled and tested here, selftest as well as ftrace at runtime seems to
work fine.
Tested-by: Stefan Agner <stefan@agner.ch>
Thanks Steven! Can you send a patch or should I do it?
--
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Dynamic ftrace self test broken on ARM
2018-06-21 7:25 ` Stefan Agner
@ 2018-06-21 13:51 ` Steven Rostedt
0 siblings, 0 replies; 13+ messages in thread
From: Steven Rostedt @ 2018-06-21 13:51 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 21 Jun 2018 09:25:48 +0200
Stefan Agner <stefan@agner.ch> wrote:
> This aligns nicely with how this has been solved with commit
> 162396309745 ("ftrace, x86: make kernel text writable only for
> conversions") a while ago.
> Reviewed-by: Stefan Agner <stefan@agner.ch>
>
> Compiled and tested here, selftest as well as ftrace at runtime seems to
> work fine.
> Tested-by: Stefan Agner <stefan@agner.ch>
>
> Thanks Steven! Can you send a patch or should I do it?
I'll resend a proper patch. Thanks for looking into it!
-- Steve
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2018-06-21 13:51 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-18 21:09 Dynamic ftrace self test broken on ARM Stefan Agner
2018-06-18 21:54 ` Steven Rostedt
2018-06-19 8:16 ` Stefan Agner
2018-06-19 13:17 ` Steven Rostedt
2018-06-20 13:51 ` Stefan Agner
2018-06-20 14:13 ` Steven Rostedt
2018-06-20 19:06 ` Stefan Agner
2018-06-20 21:32 ` Stefan Agner
2018-06-20 22:45 ` Stefan Agner
2018-06-20 23:07 ` Russell King - ARM Linux
2018-06-21 1:29 ` Steven Rostedt
2018-06-21 7:25 ` Stefan Agner
2018-06-21 13:51 ` Steven Rostedt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).