[Question] RK3288 HW RNG code #86
Comments
|
I believe the manual for the RK3288 is located at Rockchip RK3288 Technical Reference Manual. It is more comprehensive than the datasheet. Also see Issue 87. |
rkchrome
pushed a commit
that referenced
this issue
Apr 29, 2019
…ster If system monitor is disabled or the driver is failed to probe, a NULL pointer deference will happen as follow. Unable to handle kernel NULL pointer dereference at virtual address 00000048 pgd = ffffff80096b9000 [00000048] *pgd=00000000f6ffe003, *pud=00000000f6ffe003, *pmd=0000000000000000 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.167 #86 Hardware name: Rockchip RK3399 Excavator Board edp avb (Android) (DT) task: ffffffc00a368000 task.stack: ffffffc00a344000 PC is at rockchip_system_monitor_register+0x618/0x838 LR is at rockchip_system_monitor_register+0x778/0x838 pc : [<ffffff8008447dec>] lr : [<ffffff8008447f4c>] pstate: 80400145 ... 7700: ffffffc0f13c4140 fffffffffffffffd 0101010101010101 000000000000000b 7720: 20303030353d7473 3d74696d696c5f6c [<ffffff8008447dec>] rockchip_system_monitor_register+0x618/0x838 [<ffffff800884f87c>] cpufreq_init+0x388/0x3d8 [<ffffff8008846ee4>] cpufreq_online+0x1b0/0x66c [<ffffff8008847440>] cpufreq_add_dev+0x3c/0x94 [<ffffff8008544810>] subsys_interface_register+0xd4/0xf8 [<ffffff8008847648>] cpufreq_register_driver+0x10c/0x1a8 [<ffffff800884f998>] dt_cpufreq_probe+0xcc/0xe8 [<ffffff8008547bf8>] platform_drv_probe+0x54/0xa8 [<ffffff8008545fb4>] driver_probe_device+0x188/0x26c [<ffffff80085461c8>] __device_attach_driver+0x60/0x9c [<ffffff80085444c0>] bus_for_each_drv+0x9c/0xbc [<ffffff8008545d90>] __device_attach+0xc4/0x12c [<ffffff800854633c>] device_initial_probe+0x10/0x18 [<ffffff80085453b8>] bus_probe_device+0x2c/0x8c [<ffffff800854356c>] device_add+0x424/0x51c [<ffffff80085479c0>] platform_device_add+0xa0/0x1e8 [<ffffff800854840c>] platform_device_register_full+0xa4/0xe4 [<ffffff8009218c50>] rockchip_cpufreq_driver_init+0xc4/0x328 [<ffffff800808356c>] do_one_initcall+0x188/0x1a4 [<ffffff80091e0e90>] kernel_init_freeable+0x228/0x22c [<ffffff8008c1d4e8>] kernel_init+0x10/0xf8 [<ffffff80080832a0>] ret_from_fork+0x10/0x30 Change-Id: I8743040d15d594dbef67439b18782e6f16e9683a Signed-off-by: Finley Xiao <[email protected]>
scpcom
pushed a commit
to scpcom/linux
that referenced
this issue
Apr 30, 2020
…ster If system monitor is disabled or the driver is failed to probe, a NULL pointer deference will happen as follow. Unable to handle kernel NULL pointer dereference at virtual address 00000048 pgd = ffffff80096b9000 [00000048] *pgd=00000000f6ffe003, *pud=00000000f6ffe003, *pmd=0000000000000000 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.167 rockchip-linux#86 Hardware name: Rockchip RK3399 Excavator Board edp avb (Android) (DT) task: ffffffc00a368000 task.stack: ffffffc00a344000 PC is at rockchip_system_monitor_register+0x618/0x838 LR is at rockchip_system_monitor_register+0x778/0x838 pc : [<ffffff8008447dec>] lr : [<ffffff8008447f4c>] pstate: 80400145 ... 7700: ffffffc0f13c4140 fffffffffffffffd 0101010101010101 000000000000000b 7720: 20303030353d7473 3d74696d696c5f6c [<ffffff8008447dec>] rockchip_system_monitor_register+0x618/0x838 [<ffffff800884f87c>] cpufreq_init+0x388/0x3d8 [<ffffff8008846ee4>] cpufreq_online+0x1b0/0x66c [<ffffff8008847440>] cpufreq_add_dev+0x3c/0x94 [<ffffff8008544810>] subsys_interface_register+0xd4/0xf8 [<ffffff8008847648>] cpufreq_register_driver+0x10c/0x1a8 [<ffffff800884f998>] dt_cpufreq_probe+0xcc/0xe8 [<ffffff8008547bf8>] platform_drv_probe+0x54/0xa8 [<ffffff8008545fb4>] driver_probe_device+0x188/0x26c [<ffffff80085461c8>] __device_attach_driver+0x60/0x9c [<ffffff80085444c0>] bus_for_each_drv+0x9c/0xbc [<ffffff8008545d90>] __device_attach+0xc4/0x12c [<ffffff800854633c>] device_initial_probe+0x10/0x18 [<ffffff80085453b8>] bus_probe_device+0x2c/0x8c [<ffffff800854356c>] device_add+0x424/0x51c [<ffffff80085479c0>] platform_device_add+0xa0/0x1e8 [<ffffff800854840c>] platform_device_register_full+0xa4/0xe4 [<ffffff8009218c50>] rockchip_cpufreq_driver_init+0xc4/0x328 [<ffffff800808356c>] do_one_initcall+0x188/0x1a4 [<ffffff80091e0e90>] kernel_init_freeable+0x228/0x22c [<ffffff8008c1d4e8>] kernel_init+0x10/0xf8 [<ffffff80080832a0>] ret_from_fork+0x10/0x30 Change-Id: I8743040d15d594dbef67439b18782e6f16e9683a Signed-off-by: Finley Xiao <[email protected]>
friendlyarm
pushed a commit
to friendlyarm/kernel-rockchip
that referenced
this issue
Aug 31, 2021
[ Upstream commit 6206b79 ] Liajian reported a bug_on hit on a ThunderX2 arm64 server with FastLinQ QL41000 ethernet controller: BUG: scheduling while atomic: kworker/0:4/531/0x00000200 [qed_probe:488()]hw prepare failed kernel BUG at mm/vmalloc.c:2355! Internal error: Oops - BUG: 0 [#1] SMP CPU: 0 PID: 531 Comm: kworker/0:4 Tainted: G W 5.4.0-77-generic rockchip-linux#86-Ubuntu pstate: 00400009 (nzcv daif +PAN -UAO) Call trace: vunmap+0x4c/0x50 iounmap+0x48/0x58 qed_free_pci+0x60/0x80 [qed] qed_probe+0x35c/0x688 [qed] __qede_probe+0x88/0x5c8 [qede] qede_probe+0x60/0xe0 [qede] local_pci_probe+0x48/0xa0 work_for_cpu_fn+0x24/0x38 process_one_work+0x1d0/0x468 worker_thread+0x238/0x4e0 kthread+0xf0/0x118 ret_from_fork+0x10/0x18 In this case, qed_hw_prepare() returns error due to hw/fw error, but in theory work queue should be in process context instead of interrupt. The root cause might be the unpaired spin_{un}lock_bh() in _qed_mcp_cmd_and_union(), which causes botton half is disabled incorrectly. Reported-by: Lijian Zhang <[email protected]> Signed-off-by: Jia He <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
friendlyarm
pushed a commit
to friendlyarm/kernel-rockchip
that referenced
this issue
Aug 31, 2021
[ Upstream commit a17ad09 ] In some cases skb head could be locked and entire header data is pulled from skb. When skb_zerocopy() called in such cases, following BUG is triggered. This patch fixes it by copying entire skb in such cases. This could be optimized incase this is performance bottleneck. ---8<--- kernel BUG at net/core/skbuff.c:2961! invalid opcode: 0000 [#1] SMP PTI CPU: 2 PID: 0 Comm: swapper/2 Tainted: G OE 5.4.0-77-generic rockchip-linux#86-Ubuntu Hardware name: OpenStack Foundation OpenStack Nova, BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:skb_zerocopy+0x37a/0x3a0 RSP: 0018:ffffbcc70013ca38 EFLAGS: 00010246 Call Trace: <IRQ> queue_userspace_packet+0x2af/0x5e0 [openvswitch] ovs_dp_upcall+0x3d/0x60 [openvswitch] ovs_dp_process_packet+0x125/0x150 [openvswitch] ovs_vport_receive+0x77/0xd0 [openvswitch] netdev_port_receive+0x87/0x130 [openvswitch] netdev_frame_hook+0x4b/0x60 [openvswitch] __netif_receive_skb_core+0x2b4/0xc90 __netif_receive_skb_one_core+0x3f/0xa0 __netif_receive_skb+0x18/0x60 process_backlog+0xa9/0x160 net_rx_action+0x142/0x390 __do_softirq+0xe1/0x2d6 irq_exit+0xae/0xb0 do_IRQ+0x5a/0xf0 common_interrupt+0xf/0xf Code that triggered BUG: int skb_zerocopy(struct sk_buff *to, struct sk_buff *from, int len, int hlen) { int i, j = 0; int plen = 0; /* length of skb->head fragment */ int ret; struct page *page; unsigned int offset; BUG_ON(!from->head_frag && !hlen); Signed-off-by: Pravin B Shelar <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
scpcom
pushed a commit
to scpcom/linux
that referenced
this issue
Jan 31, 2023
[ Upstream commit 031af50 ] The inline assembly for arm64's cmpxchg_double*() implementations use a +Q constraint to hazard against other accesses to the memory location being exchanged. However, the pointer passed to the constraint is a pointer to unsigned long, and thus the hazard only applies to the first 8 bytes of the location. GCC can take advantage of this, assuming that other portions of the location are unchanged, leading to a number of potential problems. This is similar to what we fixed back in commit: fee960b ("arm64: xchg: hazard against entire exchange variable") ... but we forgot to adjust cmpxchg_double*() similarly at the same time. The same problem applies, as demonstrated with the following test: | struct big { | u64 lo, hi; | } __aligned(128); | | unsigned long foo(struct big *b) | { | u64 hi_old, hi_new; | | hi_old = b->hi; | cmpxchg_double_local(&b->lo, &b->hi, 0x12, 0x34, 0x56, 0x78); | hi_new = b->hi; | | return hi_old ^ hi_new; | } ... which GCC 12.1.0 compiles as: | 0000000000000000 <foo>: | 0: d503233f paciasp | 4: aa0003e4 mov x4, x0 | 8: 1400000e b 40 <foo+0x40> | c: d2800240 mov x0, #0x12 // ayufan-rock64#18 | 10: d2800681 mov x1, #0x34 // ayufan-rock64#52 | 14: aa0003e5 mov x5, x0 | 18: aa0103e6 mov x6, x1 | 1c: d2800ac2 mov x2, #0x56 // rockchip-linux#86 | 20: d2800f03 mov x3, #0x78 // rockchip-linux#120 | 24: 48207c82 casp x0, x1, x2, x3, [x4] | 28: ca050000 eor x0, x0, x5 | 2c: ca060021 eor x1, x1, x6 | 30: aa010000 orr x0, x0, x1 | 34: d2800000 mov x0, #0x0 // #0 <--- BANG | 38: d50323bf autiasp | 3c: d65f03c0 ret | 40: d2800240 mov x0, #0x12 // ayufan-rock64#18 | 44: d2800681 mov x1, #0x34 // ayufan-rock64#52 | 48: d2800ac2 mov x2, #0x56 // rockchip-linux#86 | 4c: d2800f03 mov x3, #0x78 // rockchip-linux#120 | 50: f9800091 prfm pstl1strm, [x4] | 54: c87f1885 ldxp x5, x6, [x4] | 58: ca0000a5 eor x5, x5, x0 | 5c: ca0100c6 eor x6, x6, x1 | 60: aa0600a6 orr x6, x5, x6 | 64: b5000066 cbnz x6, 70 <foo+0x70> | 68: c8250c82 stxp w5, x2, x3, [x4] | 6c: 35ffff45 cbnz w5, 54 <foo+0x54> | 70: d2800000 mov x0, #0x0 // #0 <--- BANG | 74: d50323bf autiasp | 78: d65f03c0 ret Notice that at the lines with "BANG" comments, GCC has assumed that the higher 8 bytes are unchanged by the cmpxchg_double() call, and that `hi_old ^ hi_new` can be reduced to a constant zero, for both LSE and LL/SC versions of cmpxchg_double(). This patch fixes the issue by passing a pointer to __uint128_t into the +Q constraint, ensuring that the compiler hazards against the entire 16 bytes being modified. With this change, GCC 12.1.0 compiles the above test as: | 0000000000000000 <foo>: | 0: f9400407 ldr x7, [x0, ayufan-rock64#8] | 4: d503233f paciasp | 8: aa0003e4 mov x4, x0 | c: 1400000f b 48 <foo+0x48> | 10: d2800240 mov x0, #0x12 // ayufan-rock64#18 | 14: d2800681 mov x1, #0x34 // ayufan-rock64#52 | 18: aa0003e5 mov x5, x0 | 1c: aa0103e6 mov x6, x1 | 20: d2800ac2 mov x2, #0x56 // rockchip-linux#86 | 24: d2800f03 mov x3, #0x78 // rockchip-linux#120 | 28: 48207c82 casp x0, x1, x2, x3, [x4] | 2c: ca050000 eor x0, x0, x5 | 30: ca060021 eor x1, x1, x6 | 34: aa010000 orr x0, x0, x1 | 38: f9400480 ldr x0, [x4, ayufan-rock64#8] | 3c: d50323bf autiasp | 40: ca0000e0 eor x0, x7, x0 | 44: d65f03c0 ret | 48: d2800240 mov x0, #0x12 // ayufan-rock64#18 | 4c: d2800681 mov x1, #0x34 // ayufan-rock64#52 | 50: d2800ac2 mov x2, #0x56 // rockchip-linux#86 | 54: d2800f03 mov x3, #0x78 // rockchip-linux#120 | 58: f9800091 prfm pstl1strm, [x4] | 5c: c87f1885 ldxp x5, x6, [x4] | 60: ca0000a5 eor x5, x5, x0 | 64: ca0100c6 eor x6, x6, x1 | 68: aa0600a6 orr x6, x5, x6 | 6c: b5000066 cbnz x6, 78 <foo+0x78> | 70: c8250c82 stxp w5, x2, x3, [x4] | 74: 35ffff45 cbnz w5, 5c <foo+0x5c> | 78: f9400480 ldr x0, [x4, ayufan-rock64#8] | 7c: d50323bf autiasp | 80: ca0000e0 eor x0, x7, x0 | 84: d65f03c0 ret ... sampling the high 8 bytes before and after the cmpxchg, and performing an EOR, as we'd expect. For backporting, I've tested this atop linux-4.9.y with GCC 5.5.0. Note that linux-4.9.y is oldest currently supported stable release, and mandates GCC 5.1+. Unfortunately I couldn't get a GCC 5.1 binary to run on my machines due to library incompatibilities. I've also used a standalone test to check that we can use a __uint128_t pointer in a +Q constraint at least as far back as GCC 4.8.5 and LLVM 3.9.1. Fixes: 5284e1b ("arm64: xchg: Implement cmpxchg_double") Fixes: e9a4b79 ("arm64: cmpxchg_dbl: patch in lse instructions when supported by the CPU") Reported-by: Boqun Feng <[email protected]> Link: https://lore.kernel.org/lkml/Y6DEfQXymYVgL3oJ@boqun-archlinux/ Reported-by: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Mark Rutland <[email protected]> Cc: [email protected] Cc: Arnd Bergmann <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Steve Capper <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
scpcom
pushed a commit
to scpcom/linux
that referenced
this issue
Mar 4, 2023
[ Upstream commit 031af50 ] The inline assembly for arm64's cmpxchg_double*() implementations use a +Q constraint to hazard against other accesses to the memory location being exchanged. However, the pointer passed to the constraint is a pointer to unsigned long, and thus the hazard only applies to the first 8 bytes of the location. GCC can take advantage of this, assuming that other portions of the location are unchanged, leading to a number of potential problems. This is similar to what we fixed back in commit: fee960b ("arm64: xchg: hazard against entire exchange variable") ... but we forgot to adjust cmpxchg_double*() similarly at the same time. The same problem applies, as demonstrated with the following test: | struct big { | u64 lo, hi; | } __aligned(128); | | unsigned long foo(struct big *b) | { | u64 hi_old, hi_new; | | hi_old = b->hi; | cmpxchg_double_local(&b->lo, &b->hi, 0x12, 0x34, 0x56, 0x78); | hi_new = b->hi; | | return hi_old ^ hi_new; | } ... which GCC 12.1.0 compiles as: | 0000000000000000 <foo>: | 0: d503233f paciasp | 4: aa0003e4 mov x4, x0 | 8: 1400000e b 40 <foo+0x40> | c: d2800240 mov x0, #0x12 // ayufan-rock64#18 | 10: d2800681 mov x1, #0x34 // ayufan-rock64#52 | 14: aa0003e5 mov x5, x0 | 18: aa0103e6 mov x6, x1 | 1c: d2800ac2 mov x2, #0x56 // rockchip-linux#86 | 20: d2800f03 mov x3, #0x78 // rockchip-linux#120 | 24: 48207c82 casp x0, x1, x2, x3, [x4] | 28: ca050000 eor x0, x0, x5 | 2c: ca060021 eor x1, x1, x6 | 30: aa010000 orr x0, x0, x1 | 34: d2800000 mov x0, #0x0 // #0 <--- BANG | 38: d50323bf autiasp | 3c: d65f03c0 ret | 40: d2800240 mov x0, #0x12 // ayufan-rock64#18 | 44: d2800681 mov x1, #0x34 // ayufan-rock64#52 | 48: d2800ac2 mov x2, #0x56 // rockchip-linux#86 | 4c: d2800f03 mov x3, #0x78 // rockchip-linux#120 | 50: f9800091 prfm pstl1strm, [x4] | 54: c87f1885 ldxp x5, x6, [x4] | 58: ca0000a5 eor x5, x5, x0 | 5c: ca0100c6 eor x6, x6, x1 | 60: aa0600a6 orr x6, x5, x6 | 64: b5000066 cbnz x6, 70 <foo+0x70> | 68: c8250c82 stxp w5, x2, x3, [x4] | 6c: 35ffff45 cbnz w5, 54 <foo+0x54> | 70: d2800000 mov x0, #0x0 // #0 <--- BANG | 74: d50323bf autiasp | 78: d65f03c0 ret Notice that at the lines with "BANG" comments, GCC has assumed that the higher 8 bytes are unchanged by the cmpxchg_double() call, and that `hi_old ^ hi_new` can be reduced to a constant zero, for both LSE and LL/SC versions of cmpxchg_double(). This patch fixes the issue by passing a pointer to __uint128_t into the +Q constraint, ensuring that the compiler hazards against the entire 16 bytes being modified. With this change, GCC 12.1.0 compiles the above test as: | 0000000000000000 <foo>: | 0: f9400407 ldr x7, [x0, ayufan-rock64#8] | 4: d503233f paciasp | 8: aa0003e4 mov x4, x0 | c: 1400000f b 48 <foo+0x48> | 10: d2800240 mov x0, #0x12 // ayufan-rock64#18 | 14: d2800681 mov x1, #0x34 // ayufan-rock64#52 | 18: aa0003e5 mov x5, x0 | 1c: aa0103e6 mov x6, x1 | 20: d2800ac2 mov x2, #0x56 // rockchip-linux#86 | 24: d2800f03 mov x3, #0x78 // rockchip-linux#120 | 28: 48207c82 casp x0, x1, x2, x3, [x4] | 2c: ca050000 eor x0, x0, x5 | 30: ca060021 eor x1, x1, x6 | 34: aa010000 orr x0, x0, x1 | 38: f9400480 ldr x0, [x4, ayufan-rock64#8] | 3c: d50323bf autiasp | 40: ca0000e0 eor x0, x7, x0 | 44: d65f03c0 ret | 48: d2800240 mov x0, #0x12 // ayufan-rock64#18 | 4c: d2800681 mov x1, #0x34 // ayufan-rock64#52 | 50: d2800ac2 mov x2, #0x56 // rockchip-linux#86 | 54: d2800f03 mov x3, #0x78 // rockchip-linux#120 | 58: f9800091 prfm pstl1strm, [x4] | 5c: c87f1885 ldxp x5, x6, [x4] | 60: ca0000a5 eor x5, x5, x0 | 64: ca0100c6 eor x6, x6, x1 | 68: aa0600a6 orr x6, x5, x6 | 6c: b5000066 cbnz x6, 78 <foo+0x78> | 70: c8250c82 stxp w5, x2, x3, [x4] | 74: 35ffff45 cbnz w5, 5c <foo+0x5c> | 78: f9400480 ldr x0, [x4, ayufan-rock64#8] | 7c: d50323bf autiasp | 80: ca0000e0 eor x0, x7, x0 | 84: d65f03c0 ret ... sampling the high 8 bytes before and after the cmpxchg, and performing an EOR, as we'd expect. For backporting, I've tested this atop linux-4.9.y with GCC 5.5.0. Note that linux-4.9.y is oldest currently supported stable release, and mandates GCC 5.1+. Unfortunately I couldn't get a GCC 5.1 binary to run on my machines due to library incompatibilities. I've also used a standalone test to check that we can use a __uint128_t pointer in a +Q constraint at least as far back as GCC 4.8.5 and LLVM 3.9.1. Fixes: 5284e1b ("arm64: xchg: Implement cmpxchg_double") Fixes: e9a4b79 ("arm64: cmpxchg_dbl: patch in lse instructions when supported by the CPU") Reported-by: Boqun Feng <[email protected]> Link: https://lore.kernel.org/lkml/Y6DEfQXymYVgL3oJ@boqun-archlinux/ Reported-by: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Mark Rutland <[email protected]> Cc: [email protected] Cc: Arnd Bergmann <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Steve Capper <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi there,
The RK3288 datasheet states in the manual:
Does that mean that the RK3288 can expose a Hardware Random Number Generator through
/dev/hwrng? If so, where can I find the code? :-)Thanks a lot!!
The text was updated successfully, but these errors were encountered: