Message ID | 20220630140108.129434-1-Jason@zx2c4.com (mailing list archive) |
---|---|
Headers | show |
Series | powerpc rng cleanups | expand |
> On 30-Jun-2022, at 7:31 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > These are two small cleanups for -next. > > I'm sending this v3 because very likely > https://lore.kernel.org/all/20220630121654.1939181-1-Jason@zx2c4.com/ > will land first, in which case this needs a small adjustment. > > Jason A. Donenfeld (2): > powerpc/powernv: rename remaining rng powernv_ functions to pnv_ > powerpc/kvm: don't crash on missing rng, and use darn > > arch/powerpc/include/asm/archrandom.h | 7 +-- > arch/powerpc/kvm/book3s_hv_builtin.c | 7 +-- > arch/powerpc/platforms/powernv/rng.c | 65 ++++++++++----------------- > drivers/char/hw_random/powernv-rng.c | 2 +- > 4 files changed, 30 insertions(+), 51 deletions(-) > I tried these 2 patches + previous one (to fix kobject warning) on top of 5.19.0-rc4-next-20220630 next on a Power8 server. 5.19.0-rc4-next-20220630 + powerpc/powernv: delay rng of node creation until later in boot + powerpc/powernv: rename remaining rng powernv_ functions to pnv_ + powerpc/kvm: don't crash on missing rng, and use darn Unfortunately it fails to boot with following crash [ 0.000000] ftrace: allocated 13 pages with 3 groups [ 0.000000] trace event string verifier disabled [ 0.000000] rcu: Hierarchical RCU implementation. [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=2048 to nr_cpu_ids=80. [ 0.000000] Rude variant of Tasks RCU enabled. [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=80 [ 0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 [ 0.000000] ICS OPAL backend registered [ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention. [ 0.000001] clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x761537d007, max_idle_ns: 440795202126 ns [ 0.000182] clocksource: timebase mult[1f40000] shift[24] registered [ 0.001905] BUG: Unable to handle kernel data access on read at 0x3ffff40000000 [ 0.002032] Faulting instruction address: 0xc0000000000d7990 [ 0.002132] Oops: Kernel access of bad area, sig: 7 [#1] [ 0.002226] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV [ 0.002338] Modules linked in: [ 0.002396] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc4-next-20220630-dirty #20 [ 0.002539] NIP: c0000000000d7990 LR: c00000000201fa74 CTR: c0000000000d7960 [ 0.002663] REGS: c000000002a0fa60 TRAP: 0300 Not tainted (5.19.0-rc4-next-20220630-dirty) [ 0.002812] MSR: 9000000002001033 <SF,HV,VEC,ME,IR,DR,RI,LE> CR: 44000228 XER: 20000000 [ 0.002979] CFAR: c00000000201fa70 DAR: 0003ffff40000000 DSISR: 00000002 IRQMASK: 1 [ 0.002979] GPR00: c00000000201fa74 c000000002a0fd00 c000000002a12000 c000000002a0fe90 [ 0.002979] GPR04: 0000000000000001 0000000000000000 c000000000deb578 000000000000006f [ 0.002979] GPR08: 0000000000000000 0003ffff40000000 c000000007040080 0000000000000000 [ 0.002979] GPR12: c0000000000d7960 c000000002d00000 0000000000000003 0000000000000000 [ 0.002979] GPR16: 0000000000000000 0000000000000000 0000000000000278 c000000002a4dfe0 [ 0.002979] GPR20: c000000002a52238 c000000002a52820 c0000000000d7960 c000000000fe6c50 [ 0.002979] GPR24: 0000000000000001 c000000002a0fe90 c000000000fe6c40 c000000002141ff8 [ 0.002979] GPR28: 0000000000000800 c0000000070400a0 c000000002ab0150 0000000000000000 [ 0.004279] NIP [c0000000000d7990] pnv_get_random_long+0x30/0xd0 [ 0.004390] LR [c00000000201fa74] pnv_get_random_long_early+0x268/0x2d0 [ 0.004509] Call Trace: [ 0.004553] [c000000002a0fd00] [c00000000201fa4c] pnv_get_random_long_early+0x240/0x2d0 (unreliable) [ 0.004718] [c000000002a0fe20] [c000000002060d5c] random_init+0xc0/0x214 [ 0.004844] [c000000002a0fec0] [c0000000020048c0] start_kernel+0x990/0xbf8 [ 0.004972] [c000000002a0ff90] [c00000000000d878] start_here_common+0x1c/0x24 [ 0.005102] Instruction dump: [ 0.005156] 3c4c0294 3842a6a0 7c0802a6 60000000 7d2000a6 71290010 41820048 e94d0030 [ 0.005309] 3d22ff73 3929fff8 7d4a482a e92a0008 <7d204eea> e8ea0010 7d2803f4 7ce94a78 [ 0.005465] ---[ end trace 0000000000000000 ]--- [ 0.005545] [ 1.005574] Kernel panic - not syncing: Fatal exception [ 1.005671] Rebooting in 10 seconds.. Reverting powerpc/kvm: don't crash on missing rng, and use darn helps to boot the server successfully. Thanks -Sachin
Hi Sachin, Michael, On Thu, Jun 30, 2022 at 6:12 PM Sachin Sant <sachinp@linux.ibm.com> wrote: > > On 30-Jun-2022, at 7:31 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > > > These are two small cleanups for -next. > > > > I'm sending this v3 because very likely > > https://lore.kernel.org/all/20220630121654.1939181-1-Jason@zx2c4.com/ > > will land first, in which case this needs a small adjustment. > > > > Jason A. Donenfeld (2): > > powerpc/powernv: rename remaining rng powernv_ functions to pnv_ > > powerpc/kvm: don't crash on missing rng, and use darn > > > > arch/powerpc/include/asm/archrandom.h | 7 +-- > > arch/powerpc/kvm/book3s_hv_builtin.c | 7 +-- > > arch/powerpc/platforms/powernv/rng.c | 65 ++++++++++----------------- > > drivers/char/hw_random/powernv-rng.c | 2 +- > > 4 files changed, 30 insertions(+), 51 deletions(-) > > > > I tried these 2 patches + previous one (to fix kobject warning) on > top of 5.19.0-rc4-next-20220630 next on a Power8 server. > > 5.19.0-rc4-next-20220630 + > powerpc/powernv: delay rng of node creation until later in boot + > powerpc/powernv: rename remaining rng powernv_ functions to pnv_ + > powerpc/kvm: don't crash on missing rng, and use darn > > Unfortunately it fails to boot with following crash > > [ 0.000000] ftrace: allocated 13 pages with 3 groups > [ 0.000000] trace event string verifier disabled > [ 0.000000] rcu: Hierarchical RCU implementation. > [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=2048 to nr_cpu_ids=80. > [ 0.000000] Rude variant of Tasks RCU enabled. > [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. > [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=80 > [ 0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 > [ 0.000000] ICS OPAL backend registered > [ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention. > [ 0.000001] clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x761537d007, max_idle_ns: 440795202126 ns > [ 0.000182] clocksource: timebase mult[1f40000] shift[24] registered > [ 0.001905] BUG: Unable to handle kernel data access on read at 0x3ffff40000000 > [ 0.002032] Faulting instruction address: 0xc0000000000d7990 > [ 0.002132] Oops: Kernel access of bad area, sig: 7 [#1] > [ 0.002226] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV > [ 0.002338] Modules linked in: > [ 0.002396] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc4-next-20220630-dirty #20 > [ 0.002539] NIP: c0000000000d7990 LR: c00000000201fa74 CTR: c0000000000d7960 > [ 0.002663] REGS: c000000002a0fa60 TRAP: 0300 Not tainted (5.19.0-rc4-next-20220630-dirty) > [ 0.002812] MSR: 9000000002001033 <SF,HV,VEC,ME,IR,DR,RI,LE> CR: 44000228 XER: 20000000 > [ 0.002979] CFAR: c00000000201fa70 DAR: 0003ffff40000000 DSISR: 00000002 IRQMASK: 1 > [ 0.002979] GPR00: c00000000201fa74 c000000002a0fd00 c000000002a12000 c000000002a0fe90 > [ 0.002979] GPR04: 0000000000000001 0000000000000000 c000000000deb578 000000000000006f > [ 0.002979] GPR08: 0000000000000000 0003ffff40000000 c000000007040080 0000000000000000 > [ 0.002979] GPR12: c0000000000d7960 c000000002d00000 0000000000000003 0000000000000000 > [ 0.002979] GPR16: 0000000000000000 0000000000000000 0000000000000278 c000000002a4dfe0 > [ 0.002979] GPR20: c000000002a52238 c000000002a52820 c0000000000d7960 c000000000fe6c50 > [ 0.002979] GPR24: 0000000000000001 c000000002a0fe90 c000000000fe6c40 c000000002141ff8 > [ 0.002979] GPR28: 0000000000000800 c0000000070400a0 c000000002ab0150 0000000000000000 > [ 0.004279] NIP [c0000000000d7990] pnv_get_random_long+0x30/0xd0 > [ 0.004390] LR [c00000000201fa74] pnv_get_random_long_early+0x268/0x2d0 > [ 0.004509] Call Trace: > [ 0.004553] [c000000002a0fd00] [c00000000201fa4c] pnv_get_random_long_early+0x240/0x2d0 (unreliable) > [ 0.004718] [c000000002a0fe20] [c000000002060d5c] random_init+0xc0/0x214 > [ 0.004844] [c000000002a0fec0] [c0000000020048c0] start_kernel+0x990/0xbf8 > [ 0.004972] [c000000002a0ff90] [c00000000000d878] start_here_common+0x1c/0x24 > [ 0.005102] Instruction dump: > [ 0.005156] 3c4c0294 3842a6a0 7c0802a6 60000000 7d2000a6 71290010 41820048 e94d0030 > [ 0.005309] 3d22ff73 3929fff8 7d4a482a e92a0008 <7d204eea> e8ea0010 7d2803f4 7ce94a78 > [ 0.005465] ---[ end trace 0000000000000000 ]--- > [ 0.005545] > [ 1.005574] Kernel panic - not syncing: Fatal exception > [ 1.005671] Rebooting in 10 seconds.. > > Reverting powerpc/kvm: don't crash on missing rng, and use darn helps to boot > the server successfully. Huh! Thanks for testing that so fast. That commit has this block in it: + if (mfmsr() & MSR_DR) { + rng = raw_cpu_read(pnv_rng); + *v = rng_whiten(rng, __raw_rm_readq(rng->regs_real)); The idea was that `mfmsr() & MSR_DR` would be true if we're in real mode. But I don't actually know what that's doing; mpe suggested it to me. Is it possible the condition is inverted and I should have done `!(mfmsr() & MSR_DR)`? Or maybe there's a better flag to check than the DR one? Jason
Le 30/06/2022 à 18:46, Jason A. Donenfeld a écrit : > Hi Sachin, Michael, > > On Thu, Jun 30, 2022 at 6:12 PM Sachin Sant <sachinp@linux.ibm.com> wrote: >>> On 30-Jun-2022, at 7:31 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote: >>> >>> These are two small cleanups for -next. >>> >>> I'm sending this v3 because very likely >>> https://lore.kernel.org/all/20220630121654.1939181-1-Jason@zx2c4.com/ >>> will land first, in which case this needs a small adjustment. >>> >>> Jason A. Donenfeld (2): >>> powerpc/powernv: rename remaining rng powernv_ functions to pnv_ >>> powerpc/kvm: don't crash on missing rng, and use darn >>> >>> arch/powerpc/include/asm/archrandom.h | 7 +-- >>> arch/powerpc/kvm/book3s_hv_builtin.c | 7 +-- >>> arch/powerpc/platforms/powernv/rng.c | 65 ++++++++++----------------- >>> drivers/char/hw_random/powernv-rng.c | 2 +- >>> 4 files changed, 30 insertions(+), 51 deletions(-) >>> >> >> I tried these 2 patches + previous one (to fix kobject warning) on >> top of 5.19.0-rc4-next-20220630 next on a Power8 server. >> >> 5.19.0-rc4-next-20220630 + >> powerpc/powernv: delay rng of node creation until later in boot + >> powerpc/powernv: rename remaining rng powernv_ functions to pnv_ + >> powerpc/kvm: don't crash on missing rng, and use darn >> >> Unfortunately it fails to boot with following crash >> >> [ 0.000000] ftrace: allocated 13 pages with 3 groups >> [ 0.000000] trace event string verifier disabled >> [ 0.000000] rcu: Hierarchical RCU implementation. >> [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=2048 to nr_cpu_ids=80. >> [ 0.000000] Rude variant of Tasks RCU enabled. >> [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. >> [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=80 >> [ 0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 >> [ 0.000000] ICS OPAL backend registered >> [ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention. >> [ 0.000001] clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x761537d007, max_idle_ns: 440795202126 ns >> [ 0.000182] clocksource: timebase mult[1f40000] shift[24] registered >> [ 0.001905] BUG: Unable to handle kernel data access on read at 0x3ffff40000000 >> [ 0.002032] Faulting instruction address: 0xc0000000000d7990 >> [ 0.002132] Oops: Kernel access of bad area, sig: 7 [#1] >> [ 0.002226] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV >> [ 0.002338] Modules linked in: >> [ 0.002396] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc4-next-20220630-dirty #20 >> [ 0.002539] NIP: c0000000000d7990 LR: c00000000201fa74 CTR: c0000000000d7960 >> [ 0.002663] REGS: c000000002a0fa60 TRAP: 0300 Not tainted (5.19.0-rc4-next-20220630-dirty) >> [ 0.002812] MSR: 9000000002001033 <SF,HV,VEC,ME,IR,DR,RI,LE> CR: 44000228 XER: 20000000 >> [ 0.002979] CFAR: c00000000201fa70 DAR: 0003ffff40000000 DSISR: 00000002 IRQMASK: 1 >> [ 0.002979] GPR00: c00000000201fa74 c000000002a0fd00 c000000002a12000 c000000002a0fe90 >> [ 0.002979] GPR04: 0000000000000001 0000000000000000 c000000000deb578 000000000000006f >> [ 0.002979] GPR08: 0000000000000000 0003ffff40000000 c000000007040080 0000000000000000 >> [ 0.002979] GPR12: c0000000000d7960 c000000002d00000 0000000000000003 0000000000000000 >> [ 0.002979] GPR16: 0000000000000000 0000000000000000 0000000000000278 c000000002a4dfe0 >> [ 0.002979] GPR20: c000000002a52238 c000000002a52820 c0000000000d7960 c000000000fe6c50 >> [ 0.002979] GPR24: 0000000000000001 c000000002a0fe90 c000000000fe6c40 c000000002141ff8 >> [ 0.002979] GPR28: 0000000000000800 c0000000070400a0 c000000002ab0150 0000000000000000 >> [ 0.004279] NIP [c0000000000d7990] pnv_get_random_long+0x30/0xd0 >> [ 0.004390] LR [c00000000201fa74] pnv_get_random_long_early+0x268/0x2d0 >> [ 0.004509] Call Trace: >> [ 0.004553] [c000000002a0fd00] [c00000000201fa4c] pnv_get_random_long_early+0x240/0x2d0 (unreliable) >> [ 0.004718] [c000000002a0fe20] [c000000002060d5c] random_init+0xc0/0x214 >> [ 0.004844] [c000000002a0fec0] [c0000000020048c0] start_kernel+0x990/0xbf8 >> [ 0.004972] [c000000002a0ff90] [c00000000000d878] start_here_common+0x1c/0x24 >> [ 0.005102] Instruction dump: >> [ 0.005156] 3c4c0294 3842a6a0 7c0802a6 60000000 7d2000a6 71290010 41820048 e94d0030 >> [ 0.005309] 3d22ff73 3929fff8 7d4a482a e92a0008 <7d204eea> e8ea0010 7d2803f4 7ce94a78 >> [ 0.005465] ---[ end trace 0000000000000000 ]--- >> [ 0.005545] >> [ 1.005574] Kernel panic - not syncing: Fatal exception >> [ 1.005671] Rebooting in 10 seconds.. >> >> Reverting powerpc/kvm: don't crash on missing rng, and use darn helps to boot >> the server successfully. > > Huh! Thanks for testing that so fast. > > That commit has this block in it: > > + if (mfmsr() & MSR_DR) { > + rng = raw_cpu_read(pnv_rng); > + *v = rng_whiten(rng, __raw_rm_readq(rng->regs_real)); > > The idea was that `mfmsr() & MSR_DR` would be true if we're in real > mode. But I don't actually know what that's doing; mpe suggested it to > me. Is it possible the condition is inverted and I should have done > `!(mfmsr() & MSR_DR)`? Or maybe there's a better flag to check than > the DR one? When DR is set you are in virtual mode When DR is unset you are in real mode Extract from documentation: DR Data address translation 0 Data address translation is disabled. 1 Data address translation is enabled. Christophe
On Fri, Jul 01, 2022 at 07:24:42AM +0000, Christophe Leroy wrote: > When DR is set you are in virtual mode > When DR is unset you are in real mode > > Extract from documentation: > > DR Data address translation > 0 Data address translation is disabled. > 1 Data address translation is enabled. Thanks! So I just had it backwards, no wonder. Jason > > > Christophe