Re: [PATCH] powerpc/math_emu/efp: Include module.h
Le 31/08/2022 à 17:20, Nathan Chancellor a écrit :
> When building with a recent version of clang, there are a couple of
> errors around the call to module_init():
>
>arch/powerpc/math-emu/math_efp.c:927:1: error: type specifier missing,
> defaults to 'int'; ISO C99 and later do not support implicit int
> [-Wimplicit-int]
>module_init(spe_mathemu_init);
>^
>int
>arch/powerpc/math-emu/math_efp.c:927:13: error: a parameter list without
> types is only allowed in a function definition
>module_init(spe_mathemu_init);
>^
>2 errors generated.
>
> module_init() is a macro, which is not getting expanded because module.h
> is not included in this file. Add the include so that the macro can
> expand properly, clearing up the build failure.
>
> Reported-by: kernel test robot
> Signed-off-by: Nathan Chancellor
> ---
>
> No Fixes tag because it seems likely that this is a transient include
> issue (the code builds with GCC). The robot blamed commit e8c07082a810
> ("Kbuild: move to -std=gnu11") but I think that just exposed these
> errors, not caused them.
Well spoted.
Seems like a GCC bug. The code builds fine but silently ignores the
issue and the following section is missing:
8 .initcall6.init 0004 8b30 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
It means spe_mathemu_init() is never called.
I think it would be worth a GCC bug report.
And by the way:
Reviewed-by: Christophe Leroy
Fixes: ac6f120369ff ("powerpc/85xx: Workaroudn e500 CPU erratum A005")
>
> arch/powerpc/math-emu/math_efp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/math-emu/math_efp.c
> b/arch/powerpc/math-emu/math_efp.c
> index 39b84e7452e1..aa3bb8da1cb9 100644
> --- a/arch/powerpc/math-emu/math_efp.c
> +++ b/arch/powerpc/math-emu/math_efp.c
> @@ -17,6 +17,7 @@
>
> #include
> #include
> +#include
>
> #include
> #include
>
> base-commit: dcf8e5633e2e69ad60b730ab5905608b756a032f
Re: [PATCH v2] powerpc: Fix irq_soft_mask_set() and irq_soft_mask_return() with sanitizer
Le 01/09/2022 à 00:45, Segher Boessenkool a écrit :
> Hi!
>
> On Tue, Aug 30, 2022 at 09:10:02AM +, Christophe Leroy wrote:
>> Le 30/08/2022 à 11:01, Nicholas Piggin a écrit :
>>> On Tue Aug 30, 2022 at 3:24 PM AEST, Christophe Leroy wrote:
> This is still slightly concerning to me. Is there any guarantee that the
> compiler would not use a different sequence for the address here?
>
> Maybe explicit r13 is required.
>
local_paca is defined as:
register struct paca_struct *local_paca asm("r13");
>
> And this is in global scope, making it a global register variable.
>
Why would the compiler use another register ?
>>>
>>> Hopefully it doesn't. Is it guaranteed that it won't?
>
> Yes, this is guaranteed.
>
> For a local register variable this is guaranteed only for operands to an
> extended inline asm; any other access to the variable does not have to
> put it in the specified register.
>
> But this is a global register variable. The only thing that would make
> this crash and burn is if *any* translation unit did not see this
> declaration: it could then use r13 (if that was allowed by the ABI in
> effect, heh).
>
>>> I'm sure Segher will be delighted with the creative asm in __do_IRQ
>>> and call_do_irq :) *Grabs popcorn*
>
> All that %% is blinding, yes.
>
> Inline tabs are bad taste.
>
> Operand names instead of numbers are great for obfuscation, and nothing
> else -- unless you have more than four or five operands, in which case
> you have bigger problems already.
>
> Oh, this function is a good example of proper use of local register asm,
> btw.
>
> Comments like "// Inputs" are just harmful. As is the "creative"
> indentation here. Both harm readability and do not help understanding
> in any other way either.
>
> The thing about inline asm is the smallest details change meaning of the
> whole, it is a very harsh environment, you are programming both in C and
> directly assembler code as well, and things have to be valid for both,
> although on the other hand there is almost no error checking. Keeping
> it small, simple, readable is paramount.
>
> The rules for using inline asm:
>
> 0) Do no use inline asm.
> 1) Use extended asm, unless you know all differences with basic asm, and
> you know you want that. And if you answer "yes I do" to the latter,
> you answered wrong to the former.
> 2) Do not use toplevel asm.
> 3) Do no use inline asm.
> 4) Do no use inline asm.
> 5) Do no use inline asm.
>
> Inline asm is a very powerful escape hatch. Like all emergency exits,
> you should not use them if you do not need them! :-)
>
> But, you are talking about the function calling and the frame change I
> bet :-) Both of these are only okay because everything is back as it
> was when this (single!) asm is done, and the state created is perfectly
> fine (this is very dependent on exact ABI used, etc.)
>
> I would have used real assembler code here (in a .s file). But there
> probably are reasons to do things this way, performance probably?
We changed it to inline asm in order to ... inline it in the caller.
I also find that those operand names make it awull more difficult to
read that traditional numbering. I really dislike that new trend.
And same with those // comments, better use meaningfull C variable names.
Christophe
Re: [PATCH] powerpc/pci: Enable PCI domains in /proc when PCI bus numbers are not unique
Pali Rohár writes:
> On Thursday 25 August 2022 17:49:28 Michael Ellerman wrote:
>> Pali Rohár writes:
>> > On 32-bit powerpc systems with more PCIe controllers and more PCI domains,
>> > where on more PCI domains are same PCI numbers, when kernel is compiled
>> > with CONFIG_PROC_FS=y and CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT=y
>> > options, kernel prints "proc_dir_entry 'pci/01' already registered" error
>> > message.
>>
>> Thanks, I'll pick this up.
>>
>> > This regression started appearing after commit 566356813082 ("powerpc/pci:
>> > Add config option for using all 256 PCI buses") in case in each mPCIe slot
>> > is connected PCIe card and therefore PCI bus 1 is populated in for every
>> > PCIe controller / PCI domain.
>> >
>> > The reason is that PCI procfs code expects that when PCI bus numbers are
>> > not unique across all PCI domains, function pci_proc_domain() returns true
>> > for domain dependent buses.
>> >
>> > Fix this issue by setting PCI_ENABLE_PROC_DOMAINS and PCI_COMPAT_DOMAIN_0
>> > flags for 32-bit powerpc code when CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT
>> > is enabled. Same approach is already implemented for 64-bit powerpc code
>> > (where PCI bus numbers are always domain dependent).
>>
>> We also have the same in ppc4xx_pci_find_bridges().
>>
>> And if we can eventually make CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT
>> the standard behaviour on 32-bit then everything would behave the same
>> and we could simplify pci_proc_domain() to match what other arches do.
>
> I sent two patches which do another steps to achieve it:
> https://lore.kernel.org/linuxppc-dev/20220817163927.24453-1-p...@kernel.org/t/#u
>
> Main blocker is pci-OF-bus-map which is in direct conflict with
> CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT and which used on chrp and pmac.
> And I have no idea if pci-OF-bus-map is still needed or not.
Yeah thanks, I saw those patches.
I can't find any code that refers to pci-OF-bus-map, so I'm inclined to
remove it entirely.
But I'll do some more searching to see if I can find any references to
it in old code.
cheers
Re: [PATCH] Revert "powerpc/irq: Don't open code irq_soft_mask helpers"
Christophe Leroy writes:
> Le 31/08/2022 à 15:10, Michael Ellerman a écrit :
>> This reverts commit ef5b570d3700fbb8628a58da0487486ceeb713cd.
>>
>> Zhouyi reported that commit is causing crashes when running rcutorture
>> with KASAN enabled:
>>
>>BUG: using smp_processor_id() in preemptible [] code:
>> rcu_torture_rea/100
>>caller is rcu_preempt_deferred_qs_irqrestore+0x74/0xed0
>>CPU: 4 PID: 100 Comm: rcu_torture_rea Tainted: GW
>> 5.19.0-rc5-next-20220708-dirty #253
>>Call Trace:
>> dump_stack_lvl+0xbc/0x108 (unreliable)
>> check_preemption_disabled+0x154/0x160
>> rcu_preempt_deferred_qs_irqrestore+0x74/0xed0
>> __rcu_read_unlock+0x290/0x3b0
>> rcu_torture_read_unlock+0x30/0xb0
>> rcutorture_one_extend+0x198/0x810
>> rcu_torture_one_read+0x58c/0xc90
>> rcu_torture_reader+0x12c/0x360
>> kthread+0x1e8/0x220
>> ret_from_kernel_thread+0x5c/0x64
>>
>> KASAN will generate instrumentation instructions around the
>> WRITE_ONCE(local_paca->irq_soft_mask, mask):
>>
>> 0xc0295cb0 <+0>: addis r2,r12,774
>> 0xc0295cb4 <+4>: addir2,r2,16464
>> 0xc0295cb8 <+8>: mflrr0
>> 0xc0295cbc <+12>:bl 0xc008bb4c
>> 0xc0295cc0 <+16>:mflrr0
>> 0xc0295cc4 <+20>:std r31,-8(r1)
>> 0xc0295cc8 <+24>:addir3,r13,2354
>> 0xc0295ccc <+28>:mr r31,r13
>> 0xc0295cd0 <+32>:std r0,16(r1)
>> 0xc0295cd4 <+36>:stdur1,-48(r1)
>> 0xc0295cd8 <+40>:bl 0xc0609b98
>> <__asan_store1+8>
>> 0xc0295cdc <+44>:nop
>> 0xc0295ce0 <+48>:li r9,1
>> 0xc0295ce4 <+52>:stb r9,2354(r31)
>> 0xc0295ce8 <+56>:addir1,r1,48
>> 0xc0295cec <+60>:ld r0,16(r1)
>> 0xc0295cf0 <+64>:ld r31,-8(r1)
>> 0xc0295cf4 <+68>:mtlrr0
>>
>> If there is a context switch before "stb r9,2354(r31)", r31 may
>> not equal to r13, in such case, irq soft mask will not work.
>>
>> The usual solution of marking the code ineligible for instrumentation
>> forces the code out-of-line, which we would prefer to avoid. Christophe
>> proposed a partial revert, but Nick raised some concerns with that. So
>> for now do a full revert.
>>
>> Reported-by: Zhouyi Zhou
>> [mpe: Construct change log based on Zhouyi's original report]
>> Signed-off-by: Michael Ellerman
>> ---
>> arch/powerpc/include/asm/hw_irq.h | 43 ++-
>> 1 file changed, 36 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/hw_irq.h
>> b/arch/powerpc/include/asm/hw_irq.h
>> index 3c8cb48f88ae..983551859891 100644
>> --- a/arch/powerpc/include/asm/hw_irq.h
>> +++ b/arch/powerpc/include/asm/hw_irq.h
>> @@ -113,7 +113,14 @@ static inline void __hard_RI_enable(void)
>>
>> static inline notrace unsigned long irq_soft_mask_return(void)
>> {
>> -return READ_ONCE(local_paca->irq_soft_mask);
>> +unsigned long flags;
>> +
>> +asm volatile(
>> +"lbz %0,%1(13)"
>> +: "=r" (flags)
>> +: "i" (offsetof(struct paca_struct, irq_soft_mask)));
>> +
>> +return flags;
>> }
>>
>> /*
>> @@ -140,24 +147,46 @@ static inline notrace void irq_soft_mask_set(unsigned
>> long mask)
>> if (IS_ENABLED(CONFIG_PPC_IRQ_SOFT_MASK_DEBUG))
>> WARN_ON(mask && !(mask & IRQS_DISABLED));
>>
>> -WRITE_ONCE(local_paca->irq_soft_mask, mask);
>> -barrier();
>> +asm volatile(
>> +"stb %0,%1(13)"
>> +:
>> +: "r" (mask),
>> + "i" (offsetof(struct paca_struct, irq_soft_mask))
>> +: "memory");
>> }
>
> Only the above changes need to be reverted, below ones should remain as
> they are.
I agree, except that it's nearly rc4.
So I want to go back to code that's been well tested, and we can do any
further changes in next for v6.1.
cheers
Re: [PATCH v5] livepatch: Clear relocation targets on a module removal
Joe Lawrence writes: > On Thu, Sep 01, 2022 at 08:30:44AM +1000, Michael Ellerman wrote: >> Joe Lawrence writes: ... > > Hi Michael, > > While we're on the topic of klp-relocations and Power, I saw a similar > access problem when writing (late) relocations into > .data..ro_after_init. I'm not entirely convinced this should be allowed > (ie, is it really read-only after .init or ???), but it seems that other > arches currently allow it ... I guess that's because we didn't properly fix apply_relocate_add() in https://github.com/linuxppc/issues/issues/375 ? If other arches allow it then we don't want to be the odd one out :) So I guess we need to implement it. > $ ./tools/testing/selftests/livepatch/test-shadow-vars.sh > > = TEST: klp-convert data relocations (late module patching) = > % modprobe test_klp_convert_data > livepatch: enabling patch 'test_klp_convert_data' > livepatch: 'test_klp_convert_data': starting patching transition > livepatch: 'test_klp_convert_data': patching complete > % modprobe test_klp_convert_mod > ... > module_64: Applying ADD relocate section 54 to 20 > module_64: RELOC at 8482d02a: 38-type as > .klp.sym.test_klp_convert_mod.static_ro_after_init,0 (0xc008016d0084) + 0 > BUG: Unable to handle kernel data access on write at 0xc008021d > Faulting instruction address: 0xc0055f14 > Oops: Kernel access of bad area, sig: 11 [#1] > LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries > Modules linked in: test_klp_convert_mod(+) test_klp_convert_data(K) bonding > rfkill tls pseries_rng drm fuse drm_panel_orientation_quirks xfs libcrc32c > sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp vmx_crypto dm_mirror > dm_region_hash dm_log dm_mod [last unloaded: test_klp_convert_mod] > CPU: 0 PID: 17089 Comm: modprobe Kdump: loaded Tainted: G K > 5.19.0+ #1 > NIP: c0055f14 LR: c021ef28 CTR: c0055f14 > REGS: c000387af5a0 TRAP: 0300 Tainted: G K(5.19.0+) > MSR: 82009033 CR: 88228444 XER: > CFAR: c0055e04 DAR: c008021d DSISR: 4200 IRQMASK: 0 > GPR00: c021ef28 c000387af840 c2a68a00 c88b3000 > GPR04: c00802230084 0026 0036 c008021e0480 > GPR08: 7c426214 c0055f14 c0055e08 0d80 > GPR12: c021d9b0 c2d9 c88b3000 c008021f0810 > GPR16: c008021c0638 c88b3d80 c1181e38 > GPR20: c29dc088 c008021e0480 c008021f0870 aaab > GPR24: c88b3c40 c008021d c008021f > GPR28: c008021d c008021c0638 0810 > NIP [c0055f14] apply_relocate_add+0x474/0x9e0 > LR [c021ef28] klp_apply_section_relocs+0x208/0x2d0 > Call Trace: > [c000387af840] [c000387af920] 0xc000387af920 (unreliable) > [c000387af940] [c021ef28] klp_apply_section_relocs+0x208/0x2d0 > [c000387afa30] [c021f080] klp_init_object_loaded+0x90/0x1e0 > [c000387afac0] [c02200ac] klp_module_coming+0x3dc/0x5c0 > [c000387afb70] [c0231414] load_module+0xf64/0x13a0 > [c000387afc90] [c0231b8c] __do_sys_finit_module+0xdc/0x180 > [c000387afdb0] [c002f004] system_call_exception+0x164/0x340 > [c000387afe10] [c000be68] system_call_vectored_common+0xe8/0x278 > --- interrupt: 3000 at 0x7fffb6af4710 > NIP: 7fffb6af4710 LR: CTR: > REGS: c000387afe80 TRAP: 3000 Tainted: G K(5.19.0+) > MSR: 8000f033 CR: 48224244 XER: > > IRQMASK: 0 > GPR00: 0161 7fffe06f5550 7fffb6bf7200 0005 > GPR04: 000105f36ca0 0005 > GPR08: > GPR12: 7fffb738c540 0020 > GPR16: 010024d31de0 000105f37d50 010024d302f8 > GPR20: 0001 0908 010024d32020 010024d319b0 > GPR24: 010024d32040 010024d303f0 > GPR28: 010024d31e00 000105f36ca0 0004 010024d319b0 > NIP [7fffb6af4710] 0x7fffb6af4710 > LR [] 0x0 > --- interrupt: 3000 > Instruction dump: > 061c 061c 061c 061c 061c 061c 061c 061c > 0288 0248 6000 7c992050 <7c9ce92a> 6000 6000 e9310020 > ---[ end trace ]--- > > $ readelf --wide --sections lib/livepatch/test_klp_convert_data.ko | grep -e > '\[20\]' -e '\[54\]' > [20] .data..ro_after_init PROGBITS > 001a58 08 00 WA 0 0 8 > [54] .klp.rela.test_klp_convert_mod..data..ro_after_init RELA > 0426e8 18 18 Ao 49 20 8
[powerpc:merge] BUILD SUCCESS d30b91b37ef543f5eca88f7335374404c78a07ab
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: d30b91b37ef543f5eca88f7335374404c78a07ab Automatic merge of 'next' into merge (2022-09-01 00:09) elapsed time: 733m configs tested: 55 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arc randconfig-r043-20220830 um i386_defconfig um x86_64_defconfig powerpc allnoconfig x86_64 defconfig i386defconfig x86_64 rhel-8.3 i386 randconfig-a001 i386 randconfig-a003 x86_64 allyesconfig i386 randconfig-a005 arm defconfig x86_64randconfig-a004 x86_64randconfig-a002 i386 randconfig-a014 x86_64 rhel-8.3-kvm i386 randconfig-a012 arc randconfig-r043-20220831 m68k allmodconfig x86_64randconfig-a006 x86_64rhel-8.3-kselftests i386 allyesconfig x86_64 rhel-8.3-syz i386 randconfig-a016 x86_64 rhel-8.3-func riscvrandconfig-r042-20220831 x86_64 rhel-8.3-kunit arc allyesconfig s390 randconfig-r044-20220831 alphaallyesconfig m68k allyesconfig ia64 allmodconfig arm allyesconfig arm64allyesconfig x86_64randconfig-a015 mips allyesconfig powerpc allmodconfig sh allmodconfig x86_64randconfig-a011 x86_64randconfig-a013 clang tested configs: hexagon randconfig-r045-20220830 hexagon randconfig-r041-20220830 i386 randconfig-a002 hexagon randconfig-r041-20220831 i386 randconfig-a006 i386 randconfig-a013 i386 randconfig-a015 i386 randconfig-a004 x86_64randconfig-a005 i386 randconfig-a011 x86_64randconfig-a001 hexagon randconfig-r045-20220831 x86_64randconfig-a003 x86_64randconfig-a016 x86_64randconfig-a014 -- 0-DAY CI Kernel Test Service https://01.org/lkp
[powerpc:next-test] BUILD SUCCESS 3fe3a16489c3d45bdd9d5a7e2d13f2fbbd236cbf
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test branch HEAD: 3fe3a16489c3d45bdd9d5a7e2d13f2fbbd236cbf powerpc/code-patching: Speed up page mapping/unmapping elapsed time: 722m configs tested: 74 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arc randconfig-r043-20220830 um i386_defconfig um x86_64_defconfig arc allyesconfig x86_64 defconfig i386defconfig alphaallyesconfig m68k allyesconfig m68k allmodconfig x86_64 rhel-8.3 x86_64 allyesconfig i386 allyesconfig i386 randconfig-a001 i386 randconfig-a003 x86_64 rhel-8.3-func x86_64 rhel-8.3-kunit x86_64rhel-8.3-kselftests i386 randconfig-a005 x86_64 rhel-8.3-syz x86_64randconfig-a013 x86_64 rhel-8.3-kvm x86_64randconfig-a011 arm defconfig x86_64randconfig-a015 arc randconfig-r043-20220831 x86_64randconfig-a002 arm allyesconfig arm64allyesconfig x86_64randconfig-a004 s390 randconfig-r044-20220831 x86_64randconfig-a006 riscvrandconfig-r042-20220831 i386 randconfig-a014 i386 randconfig-a012 i386 randconfig-a016 ia64 allmodconfig powerpc allnoconfig mips allyesconfig powerpc allmodconfig sh allmodconfig csky allnoconfig alpha allnoconfig arc allnoconfig riscv allnoconfig arcnsim_700_defconfig pariscgeneric-32bit_defconfig riscv nommu_k210_sdcard_defconfig sh lboxre2_defconfig xtensa virt_defconfig powerpcwarp_defconfig armmulti_v7_defconfig arm64alldefconfig loongarch defconfig loongarch allnoconfig clang tested configs: hexagon randconfig-r045-20220830 hexagon randconfig-r041-20220830 s390 randconfig-r044-20220830 riscvrandconfig-r042-20220830 i386 randconfig-a002 i386 randconfig-a004 i386 randconfig-a006 x86_64randconfig-a012 x86_64randconfig-a016 x86_64randconfig-a014 hexagon randconfig-r041-20220831 x86_64randconfig-a001 x86_64randconfig-a003 x86_64randconfig-a005 hexagon randconfig-r045-20220831 i386 randconfig-a013 i386 randconfig-a011 i386 randconfig-a015 powerpc allyesconfig arm pxa255-idp_defconfig -- 0-DAY CI Kernel Test Service https://01.org/lkp
[powerpc:fixes-test] BUILD SUCCESS 10da3c652aed277864100a16e8c9d0fc89b484cc
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test branch HEAD: 10da3c652aed277864100a16e8c9d0fc89b484cc powerpc/papr_scm: Ensure rc is always initialized in papr_scm_pmu_register() elapsed time: 723m configs tested: 58 configs skipped: 111 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: powerpc allnoconfig powerpc allmodconfig um x86_64_defconfig um i386_defconfig i386 allyesconfig i386defconfig mips allyesconfig sh allmodconfig csky allnoconfig alpha allnoconfig arc allnoconfig riscv allnoconfig m68k allyesconfig m68k allmodconfig arc allyesconfig alphaallyesconfig x86_64 defconfig x86_64 allyesconfig x86_64 rhel-8.3 arm64allyesconfig arm defconfig arm allyesconfig x86_64 rhel-8.3-kvm x86_64 rhel-8.3-syz x86_64rhel-8.3-kselftests x86_64 rhel-8.3-kunit arcnsim_700_defconfig pariscgeneric-32bit_defconfig riscv nommu_k210_sdcard_defconfig sh lboxre2_defconfig xtensa virt_defconfig powerpcwarp_defconfig armmulti_v7_defconfig arm64alldefconfig s390 randconfig-r044-20220831 arc randconfig-r043-20220831 riscvrandconfig-r042-20220831 loongarch defconfig i386 randconfig-a012 i386 randconfig-a014 i386 randconfig-a016 x86_64randconfig-a011 x86_64randconfig-a013 x86_64randconfig-a015 i386 randconfig-c001 clang tested configs: powerpc allyesconfig arm pxa255-idp_defconfig hexagon randconfig-r045-20220831 hexagon randconfig-r041-20220831 x86_64randconfig-a012 x86_64randconfig-a014 x86_64randconfig-a016 i386 randconfig-a002 i386 randconfig-a006 i386 randconfig-a004 x86_64randconfig-a005 x86_64randconfig-a003 x86_64randconfig-a001 -- 0-DAY CI Kernel Test Service https://01.org/lkp
Re: [PATCH v5] livepatch: Clear relocation targets on a module removal
On Thu, Sep 01, 2022 at 08:30:44AM +1000, Michael Ellerman wrote: > Joe Lawrence writes: > > On Tue, Aug 30, 2022 at 11:53:13AM -0700, Song Liu wrote: > >> From: Miroslav Benes > >> > >> Josh reported a bug: > >> > >> When the object to be patched is a module, and that module is > >> rmmod'ed and reloaded, it fails to load with: > >> > >> module: x86/modules: Skipping invalid relocation target, existing value > >> is nonzero for type 2, loc ba0302e9, val a03e293c > >> livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd' > >> (-8) > >> livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to > >> load module 'nfsd' > >> > >> The livepatch module has a relocation which references a symbol > >> in the _previous_ loading of nfsd. When apply_relocate_add() > >> tries to replace the old relocation with a new one, it sees that > >> the previous one is nonzero and it errors out. > >> > >> On ppc64le, we have a similar issue: > >> > >> module_64: livepatch_nfsd: Expected nop after call, got e8410018 at > >> e_show+0x60/0x548 [livepatch_nfsd] > >> livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd' > >> (-8) > >> livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to > >> load module 'nfsd' > ... > >> > > > > Hi Song, > > > > Applying your patch on top of my latest klp-convert-tree branch [1], I > > modified a few of its late module patching tests > > (tools/testing/selftests/livepatch/test-song.sh) such that: > > > > 1 - A livepatch module is loaded > >- this module contains klp-relocations to objects in (2) > > 2 - A target test module is loaded > > 3 - Unload the test target module > >- Clear klp-relocations in (1) > > 4 - Repeat target module load (2) / unload (3) a few times > > 5 - Unload livepatch module > > If you push that test code somewhere I could test it on ppc64le. > > > The results: > > > > x86_64 : pass > > s390x : pass > > ppc64le : crash > > > > I suspect Power 32-bit would suffer the same fate, but I don't have > > hardware to verify. See the kernel log from the crash below... > > > > > > = TEST: klp-convert symbols (late module patching) = > > % modprobe test_klp_convert1 > > test_klp_convert1: tainting kernel with TAINT_LIVEPATCH > > livepatch: enabling patch 'test_klp_convert1' > > livepatch: 'test_klp_convert1': starting patching transition > > livepatch: 'test_klp_convert1': patching complete > > % modprobe test_klp_convert_mod > > livepatch: applying patch 'test_klp_convert1' to loading module > > 'test_klp_convert_mod' > > test_klp_convert1: saved_command_line, 0: > > BOOT_IMAGE=(ieee1275//vdevice/v-scsi@3003/disk@8100,msdos2)/vmlinuz-5.19.0+ > > root=/dev/mapper/rhel_ibm--p9z--18--lp7-root ro > > crashkernel=2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G > > rd.lvm.lv=rhel_ibm-p9z-18-lp7/root rd.lvm.lv=rhel_ibm-p9z-18-lp7/swap > > test_klp_convert1: driver_name, 0: test_klp_convert_mod > > test_klp_convert1: test_klp_get_driver_name(), 0: test_klp_convert_mod > > test_klp_convert1: homonym_string, 1: homonym string A > > test_klp_convert1: get_homonym_string(), 1: homonym string A > > test_klp_convert1: klp_string.12345 = > > lib/livepatch/test_klp_convert_mod_a.c static string > > test_klp_convert1: klp_string.67890 = > > lib/livepatch/test_klp_convert_mod_b.c static string > > % rmmod test_klp_convert_mod > > livepatch: reverting patch 'test_klp_convert1' on unloading module > > 'test_klp_convert_mod' > > module_64: Clearing ADD relocate section 48 to 6 > > BUG: Unable to handle kernel data access on write at 0xc00802140150 > > Faulting instruction address: 0xc005659c > > Oops: Kernel access of bad area, sig: 11 [#1] > > LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries > > Modules linked in: test_klp_convert_mod(-) test_klp_convert1(K) bonding tls > > rfkill pseries_rng drm fuse drm_panel_orientation_quirks xfs libcrc32c > > sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp vmx_crypto dm_mirror > > dm_region_hash dm_log dm_mod > > CPU: 6 PID: 4766 Comm: rmmod Kdump: loaded Tainted: G K > > 5.19.0+ #1 > > NIP: c005659c LR: c0056590 CTR: 0024 > > REGS: c7223840 TRAP: 0300 Tainted: G K(5.19.0+) > > MSR: 80009033 CR: 48008282 XER: 000a > > CFAR: c00a87e0 DAR: c00802140150 DSISR: 0a00 IRQMASK: 0 > > This is saying you don't have permissions to write at that address. > > > GPR00: c0056568 c7223ae0 c2a68a00 0001 > > GPR04: c008021706f0 002d > > GPR08: 0066 00120010 8000 > > GPR12: cffca080 > > GPR16: 010005bf1810 00010c0f7370 c11b7e50 c11b7e68 > > GPR20:
Re: [PATCH v5] livepatch: Clear relocation targets on a module removal
On Wed, Aug 31, 2022 at 03:48:26PM -0700, Song Liu wrote: > On Wed, Aug 31, 2022 at 3:30 PM Michael Ellerman wrote: > > > > Joe Lawrence writes: > > > On Tue, Aug 30, 2022 at 11:53:13AM -0700, Song Liu wrote: > > >> From: Miroslav Benes > > >> > > >> Josh reported a bug: > > >> > > >> When the object to be patched is a module, and that module is > > >> rmmod'ed and reloaded, it fails to load with: > > >> > > >> module: x86/modules: Skipping invalid relocation target, existing > > >> value is nonzero for type 2, loc ba0302e9, val a03e293c > > >> livepatch: failed to initialize patch 'livepatch_nfsd' for module > > >> 'nfsd' (-8) > > >> livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing > > >> to load module 'nfsd' > > >> > > >> The livepatch module has a relocation which references a symbol > > >> in the _previous_ loading of nfsd. When apply_relocate_add() > > >> tries to replace the old relocation with a new one, it sees that > > >> the previous one is nonzero and it errors out. > > >> > > >> On ppc64le, we have a similar issue: > > >> > > >> module_64: livepatch_nfsd: Expected nop after call, got e8410018 at > > >> e_show+0x60/0x548 [livepatch_nfsd] > > >> livepatch: failed to initialize patch 'livepatch_nfsd' for module > > >> 'nfsd' (-8) > > >> livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing > > >> to load module 'nfsd' > > ... > > >> > > > > > > Hi Song, > > > > > > Applying your patch on top of my latest klp-convert-tree branch [1], I > > > modified a few of its late module patching tests > > > (tools/testing/selftests/livepatch/test-song.sh) such that: > > > > > > 1 - A livepatch module is loaded > > >- this module contains klp-relocations to objects in (2) > > > 2 - A target test module is loaded > > > 3 - Unload the test target module > > >- Clear klp-relocations in (1) > > > 4 - Repeat target module load (2) / unload (3) a few times > > > 5 - Unload livepatch module > > > > If you push that test code somewhere I could test it on ppc64le. > > > > > The results: > > > > > > x86_64 : pass > > > s390x : pass > > > ppc64le : crash > > > > > > I suspect Power 32-bit would suffer the same fate, but I don't have > > > hardware to verify. See the kernel log from the crash below... > > > > > > > > > = TEST: klp-convert symbols (late module patching) = > > > % modprobe test_klp_convert1 > > > test_klp_convert1: tainting kernel with TAINT_LIVEPATCH > > > livepatch: enabling patch 'test_klp_convert1' > > > livepatch: 'test_klp_convert1': starting patching transition > > > livepatch: 'test_klp_convert1': patching complete > > > % modprobe test_klp_convert_mod > > > livepatch: applying patch 'test_klp_convert1' to loading module > > > 'test_klp_convert_mod' > > > test_klp_convert1: saved_command_line, 0: > > > BOOT_IMAGE=(ieee1275//vdevice/v-scsi@3003/disk@8100,msdos2)/vmlinuz-5.19.0+ > > > root=/dev/mapper/rhel_ibm--p9z--18--lp7-root ro > > > crashkernel=2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G > > > rd.lvm.lv=rhel_ibm-p9z-18-lp7/root rd.lvm.lv=rhel_ibm-p9z-18-lp7/swap > > > test_klp_convert1: driver_name, 0: test_klp_convert_mod > > > test_klp_convert1: test_klp_get_driver_name(), 0: test_klp_convert_mod > > > test_klp_convert1: homonym_string, 1: homonym string A > > > test_klp_convert1: get_homonym_string(), 1: homonym string A > > > test_klp_convert1: klp_string.12345 = > > > lib/livepatch/test_klp_convert_mod_a.c static string > > > test_klp_convert1: klp_string.67890 = > > > lib/livepatch/test_klp_convert_mod_b.c static string > > > % rmmod test_klp_convert_mod > > > livepatch: reverting patch 'test_klp_convert1' on unloading module > > > 'test_klp_convert_mod' > > > module_64: Clearing ADD relocate section 48 to 6 > > > BUG: Unable to handle kernel data access on write at 0xc00802140150 > > > Faulting instruction address: 0xc005659c > > > Oops: Kernel access of bad area, sig: 11 [#1] > > > LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries > > > Modules linked in: test_klp_convert_mod(-) test_klp_convert1(K) bonding > > > tls rfkill pseries_rng drm fuse drm_panel_orientation_quirks xfs > > > libcrc32c sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp vmx_crypto > > > dm_mirror dm_region_hash dm_log dm_mod > > > CPU: 6 PID: 4766 Comm: rmmod Kdump: loaded Tainted: G K > > > 5.19.0+ #1 > > > NIP: c005659c LR: c0056590 CTR: 0024 > > > REGS: c7223840 TRAP: 0300 Tainted: G K(5.19.0+) > > > MSR: 80009033 CR: 48008282 XER: 000a > > > CFAR: c00a87e0 DAR: c00802140150 DSISR: 0a00 IRQMASK: 0 > > > > This is saying you don't have permissions to write at that address. > > > > > GPR00: c0056568 c7223ae0 c2a68a00 0001 > > > GPR04: c008021706f0 002d > > >
[PATCH] selftests/powerpc: Skip 4PB test on 4K PAGE_SIZE systems
Systems using the hash MMU with a 4K page size don't support 4PB address space, so skip the test because the bug it tests for can't be triggered. Signed-off-by: Michael Ellerman --- tools/testing/selftests/powerpc/mm/large_vm_gpr_corruption.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/testing/selftests/powerpc/mm/large_vm_gpr_corruption.c b/tools/testing/selftests/powerpc/mm/large_vm_gpr_corruption.c index 927bfae99ed9..7da515f1da72 100644 --- a/tools/testing/selftests/powerpc/mm/large_vm_gpr_corruption.c +++ b/tools/testing/selftests/powerpc/mm/large_vm_gpr_corruption.c @@ -112,6 +112,8 @@ static int test(void) // This tests a hash MMU specific bug. FAIL_IF(using_hash_mmu(_mmu)); SKIP_IF(!hash_mmu); + // 4K kernels don't support 4PB address space + SKIP_IF(sysconf(_SC_PAGESIZE) < 65536); page_size = sysconf(_SC_PAGESIZE); -- 2.37.2
[PATCH] powerpc/configs: Properly enable PAPR_SCM in pseries_defconfig
My commit to add PAPR_SCM to pseries_defconfig failed to add the
required dependencies, meaning the driver doesn't get built.
Add the required LIBNVDIMM=m.
Fixes: d6481a7195df ("powerpc/configs: Add PAPR_SCM to pseries_defconfig")
Signed-off-by: Michael Ellerman
---
arch/powerpc/configs/pseries_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/configs/pseries_defconfig
b/arch/powerpc/configs/pseries_defconfig
index b571d084c148..c05e37af9f1e 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -40,6 +40,7 @@ CONFIG_PPC_SPLPAR=y
CONFIG_DTL=y
CONFIG_PPC_SMLPAR=y
CONFIG_IBMEBUS=y
+CONFIG_LIBNVDIMM=m
CONFIG_PAPR_SCM=m
CONFIG_PPC_SVM=y
# CONFIG_PPC_PMAC is not set
--
2.37.2
Re: [PATCH linux-next] crypto: nx: remove redundant variable rc
On Wed, Aug 31, 2022 at 02:02:48PM +, cgel@gmail.com wrote:
> From: Jinpeng Cui
>
> Return value directly from set_msg_len() instead of
> getting value from redundant variable rc.
>
> Reported-by: Zeal Robot
> Signed-off-by: Jinpeng Cui
Reviewed-by: Breno Leitao
> ---
> drivers/crypto/nx/nx-aes-ccm.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/crypto/nx/nx-aes-ccm.c b/drivers/crypto/nx/nx-aes-ccm.c
> index 3793885f928d..c843f4c6f684 100644
> --- a/drivers/crypto/nx/nx-aes-ccm.c
> +++ b/drivers/crypto/nx/nx-aes-ccm.c
> @@ -134,7 +134,6 @@ static int generate_b0(u8 *iv, unsigned int assoclen,
> unsigned int authsize,
> unsigned int cryptlen, u8 *b0)
> {
> unsigned int l, lp, m = authsize;
> - int rc;
>
> memcpy(b0, iv, 16);
>
> @@ -148,9 +147,7 @@ static int generate_b0(u8 *iv, unsigned int assoclen,
> unsigned int authsize,
> if (assoclen)
> *b0 |= 64;
>
> - rc = set_msg_len(b0 + 16 - l, cryptlen, l);
> -
> - return rc;
> + return set_msg_len(b0 + 16 - l, cryptlen, l);
> }
>
> static int generate_pat(u8 *iv,
> --
> 2.25.1
>
Re: [PATCH v5] livepatch: Clear relocation targets on a module removal
On Wed, Aug 31, 2022 at 3:30 PM Michael Ellerman wrote: > > Joe Lawrence writes: > > On Tue, Aug 30, 2022 at 11:53:13AM -0700, Song Liu wrote: > >> From: Miroslav Benes > >> > >> Josh reported a bug: > >> > >> When the object to be patched is a module, and that module is > >> rmmod'ed and reloaded, it fails to load with: > >> > >> module: x86/modules: Skipping invalid relocation target, existing value > >> is nonzero for type 2, loc ba0302e9, val a03e293c > >> livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd' > >> (-8) > >> livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to > >> load module 'nfsd' > >> > >> The livepatch module has a relocation which references a symbol > >> in the _previous_ loading of nfsd. When apply_relocate_add() > >> tries to replace the old relocation with a new one, it sees that > >> the previous one is nonzero and it errors out. > >> > >> On ppc64le, we have a similar issue: > >> > >> module_64: livepatch_nfsd: Expected nop after call, got e8410018 at > >> e_show+0x60/0x548 [livepatch_nfsd] > >> livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd' > >> (-8) > >> livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to > >> load module 'nfsd' > ... > >> > > > > Hi Song, > > > > Applying your patch on top of my latest klp-convert-tree branch [1], I > > modified a few of its late module patching tests > > (tools/testing/selftests/livepatch/test-song.sh) such that: > > > > 1 - A livepatch module is loaded > >- this module contains klp-relocations to objects in (2) > > 2 - A target test module is loaded > > 3 - Unload the test target module > >- Clear klp-relocations in (1) > > 4 - Repeat target module load (2) / unload (3) a few times > > 5 - Unload livepatch module > > If you push that test code somewhere I could test it on ppc64le. > > > The results: > > > > x86_64 : pass > > s390x : pass > > ppc64le : crash > > > > I suspect Power 32-bit would suffer the same fate, but I don't have > > hardware to verify. See the kernel log from the crash below... > > > > > > = TEST: klp-convert symbols (late module patching) = > > % modprobe test_klp_convert1 > > test_klp_convert1: tainting kernel with TAINT_LIVEPATCH > > livepatch: enabling patch 'test_klp_convert1' > > livepatch: 'test_klp_convert1': starting patching transition > > livepatch: 'test_klp_convert1': patching complete > > % modprobe test_klp_convert_mod > > livepatch: applying patch 'test_klp_convert1' to loading module > > 'test_klp_convert_mod' > > test_klp_convert1: saved_command_line, 0: > > BOOT_IMAGE=(ieee1275//vdevice/v-scsi@3003/disk@8100,msdos2)/vmlinuz-5.19.0+ > > root=/dev/mapper/rhel_ibm--p9z--18--lp7-root ro > > crashkernel=2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G > > rd.lvm.lv=rhel_ibm-p9z-18-lp7/root rd.lvm.lv=rhel_ibm-p9z-18-lp7/swap > > test_klp_convert1: driver_name, 0: test_klp_convert_mod > > test_klp_convert1: test_klp_get_driver_name(), 0: test_klp_convert_mod > > test_klp_convert1: homonym_string, 1: homonym string A > > test_klp_convert1: get_homonym_string(), 1: homonym string A > > test_klp_convert1: klp_string.12345 = > > lib/livepatch/test_klp_convert_mod_a.c static string > > test_klp_convert1: klp_string.67890 = > > lib/livepatch/test_klp_convert_mod_b.c static string > > % rmmod test_klp_convert_mod > > livepatch: reverting patch 'test_klp_convert1' on unloading module > > 'test_klp_convert_mod' > > module_64: Clearing ADD relocate section 48 to 6 > > BUG: Unable to handle kernel data access on write at 0xc00802140150 > > Faulting instruction address: 0xc005659c > > Oops: Kernel access of bad area, sig: 11 [#1] > > LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries > > Modules linked in: test_klp_convert_mod(-) test_klp_convert1(K) bonding tls > > rfkill pseries_rng drm fuse drm_panel_orientation_quirks xfs libcrc32c > > sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp vmx_crypto dm_mirror > > dm_region_hash dm_log dm_mod > > CPU: 6 PID: 4766 Comm: rmmod Kdump: loaded Tainted: G K > > 5.19.0+ #1 > > NIP: c005659c LR: c0056590 CTR: 0024 > > REGS: c7223840 TRAP: 0300 Tainted: G K(5.19.0+) > > MSR: 80009033 CR: 48008282 XER: 000a > > CFAR: c00a87e0 DAR: c00802140150 DSISR: 0a00 IRQMASK: 0 > > This is saying you don't have permissions to write at that address. > > > GPR00: c0056568 c7223ae0 c2a68a00 0001 > > GPR04: c008021706f0 002d > > GPR08: 0066 00120010 8000 > > GPR12: cffca080 > > GPR16: 010005bf1810 00010c0f7370 c11b7e50 c11b7e68 > > GPR20: c008021501c8
Re: [PATCH v2] powerpc: Fix irq_soft_mask_set() and irq_soft_mask_return() with sanitizer
Hi!
On Tue, Aug 30, 2022 at 09:10:02AM +, Christophe Leroy wrote:
> Le 30/08/2022 à 11:01, Nicholas Piggin a écrit :
> > On Tue Aug 30, 2022 at 3:24 PM AEST, Christophe Leroy wrote:
> >>> This is still slightly concerning to me. Is there any guarantee that the
> >>> compiler would not use a different sequence for the address here?
> >>>
> >>> Maybe explicit r13 is required.
> >>>
> >>
> >> local_paca is defined as:
> >>
> >>register struct paca_struct *local_paca asm("r13");
And this is in global scope, making it a global register variable.
> >> Why would the compiler use another register ?
> >
> > Hopefully it doesn't. Is it guaranteed that it won't?
Yes, this is guaranteed.
For a local register variable this is guaranteed only for operands to an
extended inline asm; any other access to the variable does not have to
put it in the specified register.
But this is a global register variable. The only thing that would make
this crash and burn is if *any* translation unit did not see this
declaration: it could then use r13 (if that was allowed by the ABI in
effect, heh).
> > I'm sure Segher will be delighted with the creative asm in __do_IRQ
> > and call_do_irq :) *Grabs popcorn*
All that %% is blinding, yes.
Inline tabs are bad taste.
Operand names instead of numbers are great for obfuscation, and nothing
else -- unless you have more than four or five operands, in which case
you have bigger problems already.
Oh, this function is a good example of proper use of local register asm,
btw.
Comments like "// Inputs" are just harmful. As is the "creative"
indentation here. Both harm readability and do not help understanding
in any other way either.
The thing about inline asm is the smallest details change meaning of the
whole, it is a very harsh environment, you are programming both in C and
directly assembler code as well, and things have to be valid for both,
although on the other hand there is almost no error checking. Keeping
it small, simple, readable is paramount.
The rules for using inline asm:
0) Do no use inline asm.
1) Use extended asm, unless you know all differences with basic asm, and
you know you want that. And if you answer "yes I do" to the latter,
you answered wrong to the former.
2) Do not use toplevel asm.
3) Do no use inline asm.
4) Do no use inline asm.
5) Do no use inline asm.
Inline asm is a very powerful escape hatch. Like all emergency exits,
you should not use them if you do not need them! :-)
But, you are talking about the function calling and the frame change I
bet :-) Both of these are only okay because everything is back as it
was when this (single!) asm is done, and the state created is perfectly
fine (this is very dependent on exact ABI used, etc.)
I would have used real assembler code here (in a .s file). But there
probably are reasons to do things this way, performance probably?
Segher
Re: [PATCH v5] livepatch: Clear relocation targets on a module removal
Joe Lawrence writes: > On Tue, Aug 30, 2022 at 11:53:13AM -0700, Song Liu wrote: >> From: Miroslav Benes >> >> Josh reported a bug: >> >> When the object to be patched is a module, and that module is >> rmmod'ed and reloaded, it fails to load with: >> >> module: x86/modules: Skipping invalid relocation target, existing value is >> nonzero for type 2, loc ba0302e9, val a03e293c >> livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd' >> (-8) >> livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to >> load module 'nfsd' >> >> The livepatch module has a relocation which references a symbol >> in the _previous_ loading of nfsd. When apply_relocate_add() >> tries to replace the old relocation with a new one, it sees that >> the previous one is nonzero and it errors out. >> >> On ppc64le, we have a similar issue: >> >> module_64: livepatch_nfsd: Expected nop after call, got e8410018 at >> e_show+0x60/0x548 [livepatch_nfsd] >> livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd' >> (-8) >> livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to >> load module 'nfsd' ... >> > > Hi Song, > > Applying your patch on top of my latest klp-convert-tree branch [1], I > modified a few of its late module patching tests > (tools/testing/selftests/livepatch/test-song.sh) such that: > > 1 - A livepatch module is loaded >- this module contains klp-relocations to objects in (2) > 2 - A target test module is loaded > 3 - Unload the test target module >- Clear klp-relocations in (1) > 4 - Repeat target module load (2) / unload (3) a few times > 5 - Unload livepatch module If you push that test code somewhere I could test it on ppc64le. > The results: > > x86_64 : pass > s390x : pass > ppc64le : crash > > I suspect Power 32-bit would suffer the same fate, but I don't have > hardware to verify. See the kernel log from the crash below... > > > = TEST: klp-convert symbols (late module patching) = > % modprobe test_klp_convert1 > test_klp_convert1: tainting kernel with TAINT_LIVEPATCH > livepatch: enabling patch 'test_klp_convert1' > livepatch: 'test_klp_convert1': starting patching transition > livepatch: 'test_klp_convert1': patching complete > % modprobe test_klp_convert_mod > livepatch: applying patch 'test_klp_convert1' to loading module > 'test_klp_convert_mod' > test_klp_convert1: saved_command_line, 0: > BOOT_IMAGE=(ieee1275//vdevice/v-scsi@3003/disk@8100,msdos2)/vmlinuz-5.19.0+ > root=/dev/mapper/rhel_ibm--p9z--18--lp7-root ro > crashkernel=2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G > rd.lvm.lv=rhel_ibm-p9z-18-lp7/root rd.lvm.lv=rhel_ibm-p9z-18-lp7/swap > test_klp_convert1: driver_name, 0: test_klp_convert_mod > test_klp_convert1: test_klp_get_driver_name(), 0: test_klp_convert_mod > test_klp_convert1: homonym_string, 1: homonym string A > test_klp_convert1: get_homonym_string(), 1: homonym string A > test_klp_convert1: klp_string.12345 = lib/livepatch/test_klp_convert_mod_a.c > static string > test_klp_convert1: klp_string.67890 = lib/livepatch/test_klp_convert_mod_b.c > static string > % rmmod test_klp_convert_mod > livepatch: reverting patch 'test_klp_convert1' on unloading module > 'test_klp_convert_mod' > module_64: Clearing ADD relocate section 48 to 6 > BUG: Unable to handle kernel data access on write at 0xc00802140150 > Faulting instruction address: 0xc005659c > Oops: Kernel access of bad area, sig: 11 [#1] > LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries > Modules linked in: test_klp_convert_mod(-) test_klp_convert1(K) bonding tls > rfkill pseries_rng drm fuse drm_panel_orientation_quirks xfs libcrc32c sd_mod > t10_pi sg ibmvscsi ibmveth scsi_transport_srp vmx_crypto dm_mirror > dm_region_hash dm_log dm_mod > CPU: 6 PID: 4766 Comm: rmmod Kdump: loaded Tainted: G K > 5.19.0+ #1 > NIP: c005659c LR: c0056590 CTR: 0024 > REGS: c7223840 TRAP: 0300 Tainted: G K(5.19.0+) > MSR: 80009033 CR: 48008282 XER: 000a > CFAR: c00a87e0 DAR: c00802140150 DSISR: 0a00 IRQMASK: 0 This is saying you don't have permissions to write at that address. > GPR00: c0056568 c7223ae0 c2a68a00 0001 > GPR04: c008021706f0 002d > GPR08: 0066 00120010 8000 > GPR12: cffca080 > GPR16: 010005bf1810 00010c0f7370 c11b7e50 c11b7e68 > GPR20: c008021501c8 c00802150228 0030 6000 > GPR24: c00802160380 c00056b43000 ff20 c00056b43c00 > GPR28: aaab c00056b43b40 c0080214014c > NIP [c005659c] clear_relocate_add+0x11c/0x1c0 >
Re: [PATCH v5] livepatch: Clear relocation targets on a module removal
On Wed, Aug 31, 2022 at 10:05:43AM -0700, Song Liu wrote:
> On Wed, Aug 31, 2022 at 1:01 AM Christophe Leroy
> wrote:
> >
> >
> >
> > Le 30/08/2022 à 20:53, Song Liu a écrit :
> > > From: Miroslav Benes
> > >
> > > Josh reported a bug:
> > >
> > >When the object to be patched is a module, and that module is
> > >rmmod'ed and reloaded, it fails to load with:
> > >
> > >module: x86/modules: Skipping invalid relocation target, existing
> > > value is nonzero for type 2, loc ba0302e9, val a03e293c
> > >livepatch: failed to initialize patch 'livepatch_nfsd' for module
> > > 'nfsd' (-8)
> > >livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing
> > > to load module 'nfsd'
> > >
> > >The livepatch module has a relocation which references a symbol
> > >in the _previous_ loading of nfsd. When apply_relocate_add()
> > >tries to replace the old relocation with a new one, it sees that
> > >the previous one is nonzero and it errors out.
> > >
> > >On ppc64le, we have a similar issue:
> > >
> > >module_64: livepatch_nfsd: Expected nop after call, got e8410018 at
> > > e_show+0x60/0x548 [livepatch_nfsd]
> > >livepatch: failed to initialize patch 'livepatch_nfsd' for module
> > > 'nfsd' (-8)
> > >livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing
> > > to load module 'nfsd'
> > >
> > > He also proposed three different solutions. We could remove the error
> > > check in apply_relocate_add() introduced by commit eda9cec4c9a1
> > > ("x86/module: Detect and skip invalid relocations"). However the check
> > > is useful for detecting corrupted modules.
> > >
> > > We could also deny the patched modules to be removed. If it proved to be
> > > a major drawback for users, we could still implement a different
> > > approach. The solution would also complicate the existing code a lot.
> > >
> > > We thus decided to reverse the relocation patching (clear all relocation
> > > targets on x86_64). The solution is not
> > > universal and is too much arch-specific, but it may prove to be simpler
> > > in the end.
> > >
> > > Reported-by: Josh Poimboeuf
> > > Signed-off-by: Miroslav Benes
> > > Signed-off-by: Song Liu
> > >
> > > ---
> > >
> > > NOTE: powerpc code has not be tested.
> > >
> > > Changes v4 = v5:
> > > 1. Fix compile with powerpc.
> >
> > Not completely it seems.
> >
> >CC kernel/livepatch/core.o
> > kernel/livepatch/core.c: In function 'klp_clear_object_relocations':
> > kernel/livepatch/core.c:352:50: error: passing argument 1 of
> > 'clear_relocate_add' from incompatible pointer type
> > [-Werror=incompatible-pointer-types]
> >352 | clear_relocate_add(pmod->klp_info->sechdrs,
> >|~~^
> >| |
> >| Elf32_Shdr *
> > {aka struct elf32_shdr *}
> > In file included from kernel/livepatch/core.c:19:
> > ./include/linux/moduleloader.h:76:37: note: expected 'Elf64_Shdr *' {aka
> > 'struct elf64_shdr *'} but argument is of type 'Elf32_Shdr *' {aka
> > 'struct elf32_shdr *'}
> > 76 | void clear_relocate_add(Elf64_Shdr *sechdrs,
> >| ^~~
> > cc1: some warnings being treated as errors
> >
> >
> > Fixup:
> >
> > diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
> > index d22b36b84b4b..958e6da7f475 100644
> > --- a/include/linux/moduleloader.h
> > +++ b/include/linux/moduleloader.h
> > @@ -73,7 +73,7 @@ int apply_relocate_add(Elf_Shdr *sechdrs,
> >unsigned int relsec,
> >struct module *mod);
> > #ifdef CONFIG_LIVEPATCH
> > -void clear_relocate_add(Elf64_Shdr *sechdrs,
> > +void clear_relocate_add(Elf_Shdr *sechdrs,
> >const char *strtab,
> >unsigned int symindex,
> >unsigned int relsec,
> >
> >
> > But then the link fails.
> >
> >LD .tmp_vmlinux.kallsyms1
> > powerpc64-linux-ld: kernel/livepatch/core.o: in function
> > `klp_cleanup_module_patches_limited':
> > core.c:(.text+0xdb4): undefined reference to `clear_relocate_add'
>
> Hmm.. I am not seeing either error. Could you please share your .config file?
>
> Thanks,
> Song
>
If it's any help, I see the same build error Christophe reported using
the 'cross-dev' script that's in my klp-convert-tree [1].
$ BUILD_ARCHES="ppc32" ./cross-dev config
$ BUILD_ARCHES="ppc32" ./cross-dev build -j$(nproc)
(The kernel will be built in /tmp/klp-convert-ppc32 btw.)
Applying the header file fix results in the same linker error, too.
[1]
https://github.com/joe-lawrence/klp-convert-tree/tree/klp-convert-v7-devel+song
-- Joe
Re: [RFC PATCH 2/2] fs/xattr: wire up syscalls
On 2022-08-30 17:28, Christian Göttsche wrote: > Enable the new added extended attribute related syscalls. > > Signed-off-by: Christian Göttsche I can't speak to the completeness of the arch list, but I'm glad to see the audit attr change bits in there. > --- > TODO: > - deprecate traditional syscalls (setxattr, ...)? > - resolve possible conflicts with proposed readfile syscall > --- > arch/alpha/kernel/syscalls/syscall.tbl | 4 > arch/arm/tools/syscall.tbl | 4 > arch/arm64/include/asm/unistd.h | 2 +- > arch/arm64/include/asm/unistd32.h | 8 > arch/ia64/kernel/syscalls/syscall.tbl | 4 > arch/m68k/kernel/syscalls/syscall.tbl | 4 > arch/microblaze/kernel/syscalls/syscall.tbl | 4 > arch/mips/kernel/syscalls/syscall_n32.tbl | 4 > arch/mips/kernel/syscalls/syscall_n64.tbl | 4 > arch/mips/kernel/syscalls/syscall_o32.tbl | 4 > arch/parisc/kernel/syscalls/syscall.tbl | 4 > arch/powerpc/kernel/syscalls/syscall.tbl| 4 > arch/s390/kernel/syscalls/syscall.tbl | 4 > arch/sh/kernel/syscalls/syscall.tbl | 4 > arch/sparc/kernel/syscalls/syscall.tbl | 4 > arch/x86/entry/syscalls/syscall_32.tbl | 4 > arch/x86/entry/syscalls/syscall_64.tbl | 4 > arch/xtensa/kernel/syscalls/syscall.tbl | 4 > include/asm-generic/audit_change_attr.h | 6 ++ > include/linux/syscalls.h| 8 > include/uapi/asm-generic/unistd.h | 12 +++- > 21 files changed, 98 insertions(+), 2 deletions(-) > > diff --git a/arch/alpha/kernel/syscalls/syscall.tbl > b/arch/alpha/kernel/syscalls/syscall.tbl > index 3515bc4f16a4..826a8a36da81 100644 > --- a/arch/alpha/kernel/syscalls/syscall.tbl > +++ b/arch/alpha/kernel/syscalls/syscall.tbl > @@ -490,3 +490,7 @@ > 558 common process_mreleasesys_process_mrelease > 559 common futex_waitv sys_futex_waitv > 560 common set_mempolicy_home_node sys_ni_syscall > +561 common setxattrat sys_setxattrat > +562 common getxattrat sys_getxattrat > +563 common listxattrat sys_listxattrat > +564 common removexattrat sys_removexattrat > diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl > index ac964612d8b0..f0e9d9d487f0 100644 > --- a/arch/arm/tools/syscall.tbl > +++ b/arch/arm/tools/syscall.tbl > @@ -464,3 +464,7 @@ > 448 common process_mreleasesys_process_mrelease > 449 common futex_waitv sys_futex_waitv > 450 common set_mempolicy_home_node sys_set_mempolicy_home_node > +451 common setxattrat sys_setxattrat > +452 common getxattrat sys_getxattrat > +453 common listxattrat sys_listxattrat > +454 common removexattrat sys_removexattrat > diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h > index 037feba03a51..63a8a9c4abc1 100644 > --- a/arch/arm64/include/asm/unistd.h > +++ b/arch/arm64/include/asm/unistd.h > @@ -39,7 +39,7 @@ > #define __ARM_NR_compat_set_tls (__ARM_NR_COMPAT_BASE + 5) > #define __ARM_NR_COMPAT_END (__ARM_NR_COMPAT_BASE + 0x800) > > -#define __NR_compat_syscalls 451 > +#define __NR_compat_syscalls 455 > #endif > > #define __ARCH_WANT_SYS_CLONE > diff --git a/arch/arm64/include/asm/unistd32.h > b/arch/arm64/include/asm/unistd32.h > index 604a2053d006..cd6ac63376d1 100644 > --- a/arch/arm64/include/asm/unistd32.h > +++ b/arch/arm64/include/asm/unistd32.h > @@ -907,6 +907,14 @@ __SYSCALL(__NR_process_mrelease, sys_process_mrelease) > __SYSCALL(__NR_futex_waitv, sys_futex_waitv) > #define __NR_set_mempolicy_home_node 450 > __SYSCALL(__NR_set_mempolicy_home_node, sys_set_mempolicy_home_node) > +#define __NR_setxattrat 451 > +__SYSCALL(__NR_setxattrat, sys_setxattrat) > +#define __NR_getxattrat 452 > +__SYSCALL(__NR_getxattrat, sys_getxattrat) > +#define __NR_listxattrat 453 > +__SYSCALL(__NR_listxattrat, sys_listxattrat) > +#define __NR_removexattrat 454 > +__SYSCALL(__NR_removexattrat, sys_removexattrat) > > /* > * Please add new compat syscalls above this comment and update > diff --git a/arch/ia64/kernel/syscalls/syscall.tbl > b/arch/ia64/kernel/syscalls/syscall.tbl > index 78b1d03e86e1..6e942a935a27 100644 > --- a/arch/ia64/kernel/syscalls/syscall.tbl > +++ b/arch/ia64/kernel/syscalls/syscall.tbl > @@ -371,3 +371,7 @@ > 448 common process_mreleasesys_process_mrelease > 449 common futex_waitv sys_futex_waitv > 450 common set_mempolicy_home_node sys_set_mempolicy_home_node > +451 common setxattrat sys_setxattrat > +452 common getxattrat sys_getxattrat > +453
Re: [PATCH v5] livepatch: Clear relocation targets on a module removal
On Tue, Aug 30, 2022 at 11:53:13AM -0700, Song Liu wrote:
> From: Miroslav Benes
>
> Josh reported a bug:
>
> When the object to be patched is a module, and that module is
> rmmod'ed and reloaded, it fails to load with:
>
> module: x86/modules: Skipping invalid relocation target, existing value is
> nonzero for type 2, loc ba0302e9, val a03e293c
> livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd'
> (-8)
> livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to
> load module 'nfsd'
>
> The livepatch module has a relocation which references a symbol
> in the _previous_ loading of nfsd. When apply_relocate_add()
> tries to replace the old relocation with a new one, it sees that
> the previous one is nonzero and it errors out.
>
> On ppc64le, we have a similar issue:
>
> module_64: livepatch_nfsd: Expected nop after call, got e8410018 at
> e_show+0x60/0x548 [livepatch_nfsd]
> livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd'
> (-8)
> livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to
> load module 'nfsd'
>
> He also proposed three different solutions. We could remove the error
> check in apply_relocate_add() introduced by commit eda9cec4c9a1
> ("x86/module: Detect and skip invalid relocations"). However the check
> is useful for detecting corrupted modules.
>
> We could also deny the patched modules to be removed. If it proved to be
> a major drawback for users, we could still implement a different
> approach. The solution would also complicate the existing code a lot.
>
> We thus decided to reverse the relocation patching (clear all relocation
> targets on x86_64). The solution is not
> universal and is too much arch-specific, but it may prove to be simpler
> in the end.
>
> Reported-by: Josh Poimboeuf
> Signed-off-by: Miroslav Benes
> Signed-off-by: Song Liu
>
> ---
>
> NOTE: powerpc code has not be tested.
>
> Changes v4 = v5:
> 1. Fix compile with powerpc.
>
> Changes v3 = v4:
> 1. Reuse __apply_relocate_add to make it more reliable in long term.
>(Josh Poimboeuf)
> 2. Add back ppc64 logic from v2, with changes to match current code.
>(Josh Poimboeuf)
>
> Changes v2 => v3:
> 1. Rewrite x86 changes to match current code style.
> 2. Remove powerpc changes as there is no test coverage in v3.
> 3. Only keep 1/3 of v2.
>
> v2: https://lore.kernel.org/all/20190905124514.8944-1-mbe...@suse.cz/T/#u
> ---
> arch/powerpc/kernel/module_64.c | 49 +++
> arch/s390/kernel/module.c | 8 +++
> arch/x86/kernel/module.c| 102 +++-
> include/linux/moduleloader.h| 7 +++
> kernel/livepatch/core.c | 41 -
> 5 files changed, 179 insertions(+), 28 deletions(-)
>
> diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
> index 7e45dc98df8a..6aaf5720070d 100644
> --- a/arch/powerpc/kernel/module_64.c
> +++ b/arch/powerpc/kernel/module_64.c
> @@ -739,6 +739,55 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
> return 0;
> }
>
> +#ifdef CONFIG_LIVEPATCH
> +void clear_relocate_add(Elf64_Shdr *sechdrs,
> +const char *strtab,
> +unsigned int symindex,
> +unsigned int relsec,
> +struct module *me)
> +{
> + unsigned int i;
> + Elf64_Rela *rela = (void *)sechdrs[relsec].sh_addr;
> + Elf64_Sym *sym;
> + unsigned long *location;
> + const char *symname;
> + u32 *instruction;
> +
> + pr_debug("Clearing ADD relocate section %u to %u\n", relsec,
> + sechdrs[relsec].sh_info);
> +
> + for (i = 0; i < sechdrs[relsec].sh_size / sizeof(*rela); i++) {
> + location = (void *)sechdrs[sechdrs[relsec].sh_info].sh_addr
> + + rela[i].r_offset;
> + sym = (Elf64_Sym *)sechdrs[symindex].sh_addr
> + + ELF64_R_SYM(rela[i].r_info);
> + symname = me->core_kallsyms.strtab
> + + sym->st_name;
> +
> + if (ELF64_R_TYPE(rela[i].r_info) != R_PPC_REL24)
> + continue;
> + /*
> + * reverse the operations in apply_relocate_add() for case
> + * R_PPC_REL24.
> + */
> + if (sym->st_shndx != SHN_UNDEF &&
> + sym->st_shndx != SHN_LIVEPATCH)
> + continue;
> +
> + instruction = (u32 *)location;
> + if (is_mprofile_ftrace_call(symname))
> + continue;
> +
> + if (!instr_is_relative_link_branch(ppc_inst(*instruction)))
> + continue;
> +
> + instruction += 1;
> + *instruction = PPC_RAW_NOP();
> + }
> +
> +}
> +#endif
> +
> #ifdef CONFIG_DYNAMIC_FTRACE
> int module_trampoline_target(struct module *mod, unsigned long addr,
>unsigned
Re: [PATCH] cpuidle: move from strlcpy with unused retval to strscpy
On Thu, Aug 18, 2022 at 11:00 PM Wolfram Sang
wrote:
>
> Follow the advice of the below link and prefer 'strscpy' in this
> subsystem. Conversion is 1:1 because the return value is not used.
> Generated by a coccinelle script.
>
> Link:
> https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
> Signed-off-by: Wolfram Sang
> ---
> drivers/cpuidle/cpuidle-powernv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle-powernv.c
> b/drivers/cpuidle/cpuidle-powernv.c
> index c32c600b3cf8..0b5461b3d7dd 100644
> --- a/drivers/cpuidle/cpuidle-powernv.c
> +++ b/drivers/cpuidle/cpuidle-powernv.c
> @@ -233,8 +233,8 @@ static inline void add_powernv_state(int index, const
> char *name,
> unsigned int exit_latency,
> u64 psscr_val, u64 psscr_mask)
> {
> - strlcpy(powernv_states[index].name, name, CPUIDLE_NAME_LEN);
> - strlcpy(powernv_states[index].desc, name, CPUIDLE_NAME_LEN);
> + strscpy(powernv_states[index].name, name, CPUIDLE_NAME_LEN);
> + strscpy(powernv_states[index].desc, name, CPUIDLE_NAME_LEN);
> powernv_states[index].flags = flags;
> powernv_states[index].target_residency = target_residency;
> powernv_states[index].exit_latency = exit_latency;
> --
Applied as 6.1 material, thanks!
Re: [PATCH v2 16/16] objtool/powerpc: Add --mcount specific implementation
On Wed, Aug 31, 2022 at 12:50:07PM +, Christophe Leroy wrote:
> Le 29/08/2022 à 07:52, Sathvika Vasireddy a écrit :
> > + opcode = insn >> 26;
> > +
> > + switch (opcode) {
> > + case 18: /* bl */
>
> case 18 is more than 'bl', it includes also 'b'.
> In both cases, the calculation of *immediate is the same.
It also is "ba" and "bla", sometimes written as "b[l][a]".
> It would therefore be more correct to perform the calculation and setup
> of *immediate outside the 'if ((insn & 3) == 1)', that would avoid
> unnecessary churn the day we add support for branches without link.
>
> > + if ((insn & 3) == 1) {
> > + *type = INSN_CALL;
> > + *immediate = insn & 0x3fc;
> > + if (*immediate & 0x200)
> > + *immediate -= 0x400;
> > + }
> > + break;
> > + }
Does this handle AA=1 correctly at all? That is valid both with and
without relocations, just like AA=0. Same for AA=1 LK=0 btw.
If you only handle AA=0, the code should explicitly test for that.
Segher
Re: [PATCH v5] livepatch: Clear relocation targets on a module removal
Le 31/08/2022 à 19:05, Song Liu a écrit :
> On Wed, Aug 31, 2022 at 1:01 AM Christophe Leroy
> wrote:
>>
>>
>>
>> Le 30/08/2022 à 20:53, Song Liu a écrit :
>>> From: Miroslav Benes
>>>
>>> Josh reported a bug:
>>>
>>> When the object to be patched is a module, and that module is
>>> rmmod'ed and reloaded, it fails to load with:
>>>
>>> module: x86/modules: Skipping invalid relocation target, existing value
>>> is nonzero for type 2, loc ba0302e9, val a03e293c
>>> livepatch: failed to initialize patch 'livepatch_nfsd' for module
>>> 'nfsd' (-8)
>>> livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to
>>> load module 'nfsd'
>>>
>>> The livepatch module has a relocation which references a symbol
>>> in the _previous_ loading of nfsd. When apply_relocate_add()
>>> tries to replace the old relocation with a new one, it sees that
>>> the previous one is nonzero and it errors out.
>>>
>>> On ppc64le, we have a similar issue:
>>>
>>> module_64: livepatch_nfsd: Expected nop after call, got e8410018 at
>>> e_show+0x60/0x548 [livepatch_nfsd]
>>> livepatch: failed to initialize patch 'livepatch_nfsd' for module
>>> 'nfsd' (-8)
>>> livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to
>>> load module 'nfsd'
>>>
>>> He also proposed three different solutions. We could remove the error
>>> check in apply_relocate_add() introduced by commit eda9cec4c9a1
>>> ("x86/module: Detect and skip invalid relocations"). However the check
>>> is useful for detecting corrupted modules.
>>>
>>> We could also deny the patched modules to be removed. If it proved to be
>>> a major drawback for users, we could still implement a different
>>> approach. The solution would also complicate the existing code a lot.
>>>
>>> We thus decided to reverse the relocation patching (clear all relocation
>>> targets on x86_64). The solution is not
>>> universal and is too much arch-specific, but it may prove to be simpler
>>> in the end.
>>>
>>> Reported-by: Josh Poimboeuf
>>> Signed-off-by: Miroslav Benes
>>> Signed-off-by: Song Liu
>>>
>>> ---
>>>
>>> NOTE: powerpc code has not be tested.
>>>
>>> Changes v4 = v5:
>>> 1. Fix compile with powerpc.
>>
>> Not completely it seems.
>>
>> CC kernel/livepatch/core.o
>> kernel/livepatch/core.c: In function 'klp_clear_object_relocations':
>> kernel/livepatch/core.c:352:50: error: passing argument 1 of
>> 'clear_relocate_add' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
>> 352 | clear_relocate_add(pmod->klp_info->sechdrs,
>> |~~^
>> | |
>> | Elf32_Shdr *
>> {aka struct elf32_shdr *}
>> In file included from kernel/livepatch/core.c:19:
>> ./include/linux/moduleloader.h:76:37: note: expected 'Elf64_Shdr *' {aka
>> 'struct elf64_shdr *'} but argument is of type 'Elf32_Shdr *' {aka
>> 'struct elf32_shdr *'}
>> 76 | void clear_relocate_add(Elf64_Shdr *sechdrs,
>> | ^~~
>> cc1: some warnings being treated as errors
>>
>>
>> Fixup:
>>
>> diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
>> index d22b36b84b4b..958e6da7f475 100644
>> --- a/include/linux/moduleloader.h
>> +++ b/include/linux/moduleloader.h
>> @@ -73,7 +73,7 @@ int apply_relocate_add(Elf_Shdr *sechdrs,
>> unsigned int relsec,
>> struct module *mod);
>>#ifdef CONFIG_LIVEPATCH
>> -void clear_relocate_add(Elf64_Shdr *sechdrs,
>> +void clear_relocate_add(Elf_Shdr *sechdrs,
>> const char *strtab,
>> unsigned int symindex,
>> unsigned int relsec,
>>
>>
>> But then the link fails.
>>
>> LD .tmp_vmlinux.kallsyms1
>> powerpc64-linux-ld: kernel/livepatch/core.o: in function
>> `klp_cleanup_module_patches_limited':
>> core.c:(.text+0xdb4): undefined reference to `clear_relocate_add'
>
> Hmm.. I am not seeing either error. Could you please share your .config file?
>
defconfig follows:
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_BLK_DEV_INITRD=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PROFILING=y
CONFIG_ALTIVEC=y
# CONFIG_PPC_CHRP is not set
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_PMAC=y
CONFIG_GEN_RTC=y
CONFIG_HIGHMEM=y
CONFIG_HIBERNATION=y
CONFIG_PM_DEBUG=y
CONFIG_APM_EMULATION=y
CONFIG_LIVEPATCH=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_BINFMT_MISC=m
# CONFIG_COMPAT_BRK is not set
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM_USER=y
CONFIG_NET_KEY=y
CONFIG_INET=y
Re: [PATCH v5] livepatch: Clear relocation targets on a module removal
On Wed, Aug 31, 2022 at 1:01 AM Christophe Leroy
wrote:
>
>
>
> Le 30/08/2022 à 20:53, Song Liu a écrit :
> > From: Miroslav Benes
> >
> > Josh reported a bug:
> >
> >When the object to be patched is a module, and that module is
> >rmmod'ed and reloaded, it fails to load with:
> >
> >module: x86/modules: Skipping invalid relocation target, existing value
> > is nonzero for type 2, loc ba0302e9, val a03e293c
> >livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd'
> > (-8)
> >livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to
> > load module 'nfsd'
> >
> >The livepatch module has a relocation which references a symbol
> >in the _previous_ loading of nfsd. When apply_relocate_add()
> >tries to replace the old relocation with a new one, it sees that
> >the previous one is nonzero and it errors out.
> >
> >On ppc64le, we have a similar issue:
> >
> >module_64: livepatch_nfsd: Expected nop after call, got e8410018 at
> > e_show+0x60/0x548 [livepatch_nfsd]
> >livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd'
> > (-8)
> >livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to
> > load module 'nfsd'
> >
> > He also proposed three different solutions. We could remove the error
> > check in apply_relocate_add() introduced by commit eda9cec4c9a1
> > ("x86/module: Detect and skip invalid relocations"). However the check
> > is useful for detecting corrupted modules.
> >
> > We could also deny the patched modules to be removed. If it proved to be
> > a major drawback for users, we could still implement a different
> > approach. The solution would also complicate the existing code a lot.
> >
> > We thus decided to reverse the relocation patching (clear all relocation
> > targets on x86_64). The solution is not
> > universal and is too much arch-specific, but it may prove to be simpler
> > in the end.
> >
> > Reported-by: Josh Poimboeuf
> > Signed-off-by: Miroslav Benes
> > Signed-off-by: Song Liu
> >
> > ---
> >
> > NOTE: powerpc code has not be tested.
> >
> > Changes v4 = v5:
> > 1. Fix compile with powerpc.
>
> Not completely it seems.
>
>CC kernel/livepatch/core.o
> kernel/livepatch/core.c: In function 'klp_clear_object_relocations':
> kernel/livepatch/core.c:352:50: error: passing argument 1 of
> 'clear_relocate_add' from incompatible pointer type
> [-Werror=incompatible-pointer-types]
>352 | clear_relocate_add(pmod->klp_info->sechdrs,
>|~~^
>| |
>| Elf32_Shdr *
> {aka struct elf32_shdr *}
> In file included from kernel/livepatch/core.c:19:
> ./include/linux/moduleloader.h:76:37: note: expected 'Elf64_Shdr *' {aka
> 'struct elf64_shdr *'} but argument is of type 'Elf32_Shdr *' {aka
> 'struct elf32_shdr *'}
> 76 | void clear_relocate_add(Elf64_Shdr *sechdrs,
>| ^~~
> cc1: some warnings being treated as errors
>
>
> Fixup:
>
> diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
> index d22b36b84b4b..958e6da7f475 100644
> --- a/include/linux/moduleloader.h
> +++ b/include/linux/moduleloader.h
> @@ -73,7 +73,7 @@ int apply_relocate_add(Elf_Shdr *sechdrs,
>unsigned int relsec,
>struct module *mod);
> #ifdef CONFIG_LIVEPATCH
> -void clear_relocate_add(Elf64_Shdr *sechdrs,
> +void clear_relocate_add(Elf_Shdr *sechdrs,
>const char *strtab,
>unsigned int symindex,
>unsigned int relsec,
>
>
> But then the link fails.
>
>LD .tmp_vmlinux.kallsyms1
> powerpc64-linux-ld: kernel/livepatch/core.o: in function
> `klp_cleanup_module_patches_limited':
> core.c:(.text+0xdb4): undefined reference to `clear_relocate_add'
Hmm.. I am not seeing either error. Could you please share your .config file?
Thanks,
Song
[PATCH] powerpc/math_emu/efp: Include module.h
When building with a recent version of clang, there are a couple of
errors around the call to module_init():
arch/powerpc/math-emu/math_efp.c:927:1: error: type specifier missing,
defaults to 'int'; ISO C99 and later do not support implicit int
[-Wimplicit-int]
module_init(spe_mathemu_init);
^
int
arch/powerpc/math-emu/math_efp.c:927:13: error: a parameter list without
types is only allowed in a function definition
module_init(spe_mathemu_init);
^
2 errors generated.
module_init() is a macro, which is not getting expanded because module.h
is not included in this file. Add the include so that the macro can
expand properly, clearing up the build failure.
Reported-by: kernel test robot
Signed-off-by: Nathan Chancellor
---
No Fixes tag because it seems likely that this is a transient include
issue (the code builds with GCC). The robot blamed commit e8c07082a810
("Kbuild: move to -std=gnu11") but I think that just exposed these
errors, not caused them.
arch/powerpc/math-emu/math_efp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/math-emu/math_efp.c b/arch/powerpc/math-emu/math_efp.c
index 39b84e7452e1..aa3bb8da1cb9 100644
--- a/arch/powerpc/math-emu/math_efp.c
+++ b/arch/powerpc/math-emu/math_efp.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
base-commit: dcf8e5633e2e69ad60b730ab5905608b756a032f
--
2.37.3
[PATCH linux-next] crypto: nx: remove redundant variable rc
From: Jinpeng Cui
Return value directly from set_msg_len() instead of
getting value from redundant variable rc.
Reported-by: Zeal Robot
Signed-off-by: Jinpeng Cui
---
drivers/crypto/nx/nx-aes-ccm.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-ccm.c b/drivers/crypto/nx/nx-aes-ccm.c
index 3793885f928d..c843f4c6f684 100644
--- a/drivers/crypto/nx/nx-aes-ccm.c
+++ b/drivers/crypto/nx/nx-aes-ccm.c
@@ -134,7 +134,6 @@ static int generate_b0(u8 *iv, unsigned int assoclen,
unsigned int authsize,
unsigned int cryptlen, u8 *b0)
{
unsigned int l, lp, m = authsize;
- int rc;
memcpy(b0, iv, 16);
@@ -148,9 +147,7 @@ static int generate_b0(u8 *iv, unsigned int assoclen,
unsigned int authsize,
if (assoclen)
*b0 |= 64;
- rc = set_msg_len(b0 + 16 - l, cryptlen, l);
-
- return rc;
+ return set_msg_len(b0 + 16 - l, cryptlen, l);
}
static int generate_pat(u8 *iv,
--
2.25.1
Re: [PATCH] powerpc/64s: add pte_needs_flush and huge_pmd_needs_flush
Le 31/08/2022 à 14:26, Nicholas Piggin a écrit :
> Allow PTE changes to avoid flushing the TLB when access permissions are
> being relaxed, the dirty bit is being set, and the accessed bit is being
> changed.
>
> Relaxing access permissions and setting dirty and accessed bits do not
> require a flush because the MMU will re-load the PTE and notice the
> updates (it may also cause a spurious fault).
>
> Clearing the accessed bit does not require a flush because of the
> imprecise PTE accessed bit accounting that is already performed, as
> documented in ptep_clear_flush_young().
>
> This reduces TLB flushing for some mprotect(2) calls.
>
> Signed-off-by: Nicholas Piggin
> ---
>
> arch/powerpc/include/asm/book3s/64/pgtable.h | 3 ++
> arch/powerpc/include/asm/book3s/64/tlbflush.h | 53 +++
> arch/powerpc/mm/book3s64/hash_tlb.c | 1 +
> arch/powerpc/mm/book3s64/pgtable.c| 1 +
> 4 files changed, 58 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
> b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index cb9d5fd39d7f..a5042bb9a30c 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> @@ -411,6 +411,9 @@ static inline int __ptep_test_and_clear_young(struct
> mm_struct *mm,
>* event of it not getting flushed for a long time the delay
>* shouldn't really matter because there's no real memory
>* pressure for swapout to react to. ]
> + *
> + * Note: this optimisation also exists in pte_needs_flush() and
> + * huge_pmd_needs_flush().
>*/
> #define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
> #define ptep_clear_flush_young ptep_test_and_clear_young
> diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h
> b/arch/powerpc/include/asm/book3s/64/tlbflush.h
> index d2e80f178b6d..bcd7cb585d17 100644
> --- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
> +++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
> @@ -143,6 +143,59 @@ static inline void flush_tlb_fix_spurious_fault(struct
> vm_area_struct *vma,
> flush_tlb_page(vma, address);
> }
>
> +static inline bool __pte_flags_need_flush(unsigned long oldval, unsigned
> long newval)
> +{
> + unsigned long delta = oldval ^ newval;
> +
> + /*
> + * The return value of this function doesn't matter for hash,
> + * ptep_modify_prot_start() does a pte_update() which does or schedules
> + * any necessary hash table update and flush.
> + */
> + if (!radix_enabled())
> + return true;
> +
> + /*
> + * In theory some changed software bits could be tolerated, in practice
> + * those should rarely if ever matter.
> + */
> +
> + /* Don't deal with kernel mappings or non-PTEs or not-present PTEs */
> + VM_BUG_ON((oldval | newval) & _PAGE_PRIVILEGED);
> + VM_BUG_ON(!((oldval | newval) & _PAGE_PTE));
> + VM_BUG_ON(!((oldval | newval) & _PAGE_PRESENT));
No new VM_BUG_ON() should be added, refer latests discussion on the
subject at
https://lore.kernel.org/all/CAHk-=wg40eazofo16eviaj7mfqdhz2gvebvfsmf6gyzsprj...@mail.gmail.com/
> +
> + /* Must flush on any change except READ, WRITE, EXEC, DIRTY, ACCESSED */
> + if (delta & ~(_PAGE_RWX | _PAGE_DIRTY | _PAGE_ACCESSED))
> + return true;
> +
> + /*
> + * If any of the above was present in old but cleared in new, flush.
> + * With the exception of _PAGE_ACCESSED, don't worry about flushing
> + * if that was cleared (see the comment in ptep_clear_flush_young()).
> + */
> + if ((delta & ~_PAGE_ACCESSED) & oldval)
> + return true;
> +
> + return false;
> +}
> +
> +#ifndef pte_needs_flush
Why that #ifndef ? I can't see it defined anywhere in powerpc at the
time being.
> +static inline bool pte_needs_flush(pte_t oldpte, pte_t newpte)
> +{
> + return __pte_flags_need_flush(pte_val(oldpte), pte_val(newpte));
> +}
> +#define pte_needs_flush pte_needs_flush
> +#endif
> +
> +#ifndef huge_pmd_needs_flush
Same
> +static inline bool huge_pmd_needs_flush(pmd_t oldpmd, pmd_t newpmd)
> +{
> + return __pte_flags_need_flush(pmd_val(oldpmd), pmd_val(newpmd));
> +}
> +#define huge_pmd_needs_flush huge_pmd_needs_flush
> +#endif
> +
> extern bool tlbie_capable;
> extern bool tlbie_enabled;
>
Re: [PATCH] powerpc: move from strlcpy with unused retval to strscpy
On Thu, 18 Aug 2022 22:59:46 +0200, Wolfram Sang wrote: > Follow the advice of the below link and prefer 'strscpy' in this > subsystem. Conversion is 1:1 because the return value is not used. > Generated by a coccinelle script. > > Applied to powerpc/next. [1/1] powerpc: move from strlcpy with unused retval to strscpy https://git.kernel.org/powerpc/c/14be375634c3f8ff750bdce0c10036c2fbfcb282 cheers
Re: [PATCH] macintosh: move from strlcpy with unused retval to strscpy
On Thu, 18 Aug 2022 23:00:26 +0200, Wolfram Sang wrote: > Follow the advice of the below link and prefer 'strscpy' in this > subsystem. Conversion is 1:1 because the return value is not used. > Generated by a coccinelle script. > > Applied to powerpc/next. [1/1] macintosh: move from strlcpy with unused retval to strscpy https://git.kernel.org/powerpc/c/4c14d7a3fa097c4ccb6323dd8f0f7746bfebb053 cheers
Re: [PATCH 0/2] spi: remove "spidev" nodes from DTs
On Wed, 24 Aug 2022 10:21:27 +0200, Wolfram Sang wrote: > There were two DTs left specifying "spidev" directly. Remove them. > > Wolfram Sang (2): > ARM: dts: stm32: argon: remove spidev node > powerpc/82xx: remove spidev node from mgcoge > > arch/arm/boot/dts/stm32mp157c-emstamp-argon.dtsi | 6 -- > arch/powerpc/boot/dts/mgcoge.dts | 7 --- > 2 files changed, 13 deletions(-) > > [...] Patch 2 applied to powerpc/next. [2/2] powerpc/82xx: remove spidev node from mgcoge https://git.kernel.org/powerpc/c/fd20b60aea6a37788f2f761af405b41c6c34473b cheers
Re: [PATCH v4 1/2] powerpc/mm: Support execute-only memory on the Radix MMU
On Wed, 17 Aug 2022 15:06:39 +1000, Russell Currey wrote: > Add support for execute-only memory (XOM) for the Radix MMU by using an > execute-only mapping, as opposed to the RX mapping used by powerpc's > other MMUs. > > The Hash MMU already supports XOM through the execute-only pkey, > which is a separate mechanism shared with x86. A PROT_EXEC-only mapping > will map to RX, and then the pkey will be applied on top of it. > > [...] Applied to powerpc/next. [1/2] powerpc/mm: Support execute-only memory on the Radix MMU https://git.kernel.org/powerpc/c/395cac7752b905318ae454a8b859d4c190485510 [2/2] selftests/powerpc: Add a test for execute-only memory https://git.kernel.org/powerpc/c/98acee3f8db451eaab9fbd422e523c228aacf08c cheers
Re: [PATCH] powerpc: Update ISA versions to mention e5500/e6500
On Wed, 3 Aug 2022 16:32:28 +1000, Michael Ellerman wrote: > Add the NXP (nee Freescale) e5500 and e6500 to the ISA versions > documentation. > > Applied to powerpc/next. [1/1] powerpc: Update ISA versions to mention e5500/e6500 https://git.kernel.org/powerpc/c/9e1b45fdf25caed521d6851136a0e3213c676656 cheers
Re: [PATCH] powerpc: Move patch sites out of asm-prototypes.h
On Thu, 18 Aug 2022 15:06:59 +1000, Michael Ellerman wrote: > The definitions for the patch sites etc. don't belong in > asm-prototypes.h, they are not EXPORT'ed asm symbols. > > Move them into sections.h which is traditionally used for asm symbols. > > Applied to powerpc/next. [1/1] powerpc: Move patch sites out of asm-prototypes.h https://git.kernel.org/powerpc/c/eb316ae798b36b280ef9e6a79d3aa34d146aa0e4 cheers
Re: [PATCH] powerpc/boot: Drop unused dummy.c
On Fri, 19 Aug 2022 21:05:56 +1000, Michael Ellerman wrote:
> The last use of dummy.c was dropped in commit 2bf118197cb4 ("[POWERPC]
> Create a "wrapper" script and use it in arch/powerpc/boot").
>
>
Applied to powerpc/next.
[1/1] powerpc/boot: Drop unused dummy.c
https://git.kernel.org/powerpc/c/7a26c952902d1f29b09237b1698a30084f6a3074
cheers
Re: [PATCH] powerpc/boot: Convert more files to use SPDX tags
On Fri, 19 Aug 2022 21:04:30 +1000, Michael Ellerman wrote:
> These files are all plain GPL 2.0, with a second sentence about being
> licensed as-is.
>
> Similar to the rule in commit 577b61cee5b2 ("treewide: Replace GPLv2
> boilerplate/reference with SPDX - gpl-2.0_398.RULE").
>
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/boot: Convert more files to use SPDX tags
https://git.kernel.org/powerpc/c/e01432baf6618296f4d2d557e6b4c3245a5cc3c2
cheers
Re: [PATCH] powerpc/microwatt: Add LiteX MMC driver
On Thu, 4 Aug 2022 11:27:08 +0930, Joel Stanley wrote: > Enable the LiteX MMC device and it's dependency the common clock > framework. > > Applied to powerpc/next. [1/1] powerpc/microwatt: Add LiteX MMC driver https://git.kernel.org/powerpc/c/0b9e534fcbf0a45e2ba08467de08a848a99ba2d6 cheers
Re: [PATCH] powerpc/vdso: Don't map VDSO at a fixed address on PPC32
On Thu, 18 Aug 2022 19:31:25 +0200, Christophe Leroy wrote:
> PPC64 removed default mapping address from VDSO in
> commit 30d0b3682887 ("powerpc: Move 64bit VDSO to improve context
> switch performance").
>
> Do like PPC64 and let get_unmapped_area() place the VDSO mapping
> at the address it wants, don't force a default address.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/vdso: Don't map VDSO at a fixed address on PPC32
https://git.kernel.org/powerpc/c/8a8f783588b162031a5348c24e42161461cd
cheers
Re: [PATCH] powerpc: Remove stale declarations in mmu_decl.h
On Fri, 19 Aug 2022 16:23:43 +0200, Christophe Leroy wrote:
> rtas_size and rtas_data are not used anymore since at least
> commit 7c8c6b9776fb ("powerpc: Merge lmb.c and make MM initialization
> use it.")
>
> Remove them.
>
> Since commit 4b74a35fc7e9 ("powerpc/32s: Make Hash var static")
> the forward declaration of struct hash_pte is unneeded.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Remove stale declarations in mmu_decl.h
https://git.kernel.org/powerpc/c/e38cd72c17fa7d7710088365251feb6c52b501c8
cheers
Re: [PATCH] powerpc/fsl_booke: Make calc_cam_sz() static
On Fri, 19 Aug 2022 16:26:49 +0200, Christophe Leroy wrote: > calc_cam_sz() is used only in fsl_book3e.c, make it static. > > Applied to powerpc/next. [1/1] powerpc/fsl_booke: Make calc_cam_sz() static https://git.kernel.org/powerpc/c/f7d5f00702e2da656b2a8f975fdaa0d48329de36 cheers
Re: [PATCH] Revert "powerpc/irq: Don't open code irq_soft_mask helpers"
Le 31/08/2022 à 15:10, Michael Ellerman a écrit :
> This reverts commit ef5b570d3700fbb8628a58da0487486ceeb713cd.
>
> Zhouyi reported that commit is causing crashes when running rcutorture
> with KASAN enabled:
>
>BUG: using smp_processor_id() in preemptible [] code:
> rcu_torture_rea/100
>caller is rcu_preempt_deferred_qs_irqrestore+0x74/0xed0
>CPU: 4 PID: 100 Comm: rcu_torture_rea Tainted: GW
> 5.19.0-rc5-next-20220708-dirty #253
>Call Trace:
> dump_stack_lvl+0xbc/0x108 (unreliable)
> check_preemption_disabled+0x154/0x160
> rcu_preempt_deferred_qs_irqrestore+0x74/0xed0
> __rcu_read_unlock+0x290/0x3b0
> rcu_torture_read_unlock+0x30/0xb0
> rcutorture_one_extend+0x198/0x810
> rcu_torture_one_read+0x58c/0xc90
> rcu_torture_reader+0x12c/0x360
> kthread+0x1e8/0x220
> ret_from_kernel_thread+0x5c/0x64
>
> KASAN will generate instrumentation instructions around the
> WRITE_ONCE(local_paca->irq_soft_mask, mask):
>
> 0xc0295cb0 <+0>: addis r2,r12,774
> 0xc0295cb4 <+4>: addir2,r2,16464
> 0xc0295cb8 <+8>: mflrr0
> 0xc0295cbc <+12>: bl 0xc008bb4c
> 0xc0295cc0 <+16>: mflrr0
> 0xc0295cc4 <+20>: std r31,-8(r1)
> 0xc0295cc8 <+24>: addir3,r13,2354
> 0xc0295ccc <+28>: mr r31,r13
> 0xc0295cd0 <+32>: std r0,16(r1)
> 0xc0295cd4 <+36>: stdur1,-48(r1)
> 0xc0295cd8 <+40>: bl 0xc0609b98 <__asan_store1+8>
> 0xc0295cdc <+44>: nop
> 0xc0295ce0 <+48>: li r9,1
> 0xc0295ce4 <+52>: stb r9,2354(r31)
> 0xc0295ce8 <+56>: addir1,r1,48
> 0xc0295cec <+60>: ld r0,16(r1)
> 0xc0295cf0 <+64>: ld r31,-8(r1)
> 0xc0295cf4 <+68>: mtlrr0
>
> If there is a context switch before "stb r9,2354(r31)", r31 may
> not equal to r13, in such case, irq soft mask will not work.
>
> The usual solution of marking the code ineligible for instrumentation
> forces the code out-of-line, which we would prefer to avoid. Christophe
> proposed a partial revert, but Nick raised some concerns with that. So
> for now do a full revert.
>
> Reported-by: Zhouyi Zhou
> [mpe: Construct change log based on Zhouyi's original report]
> Signed-off-by: Michael Ellerman
> ---
> arch/powerpc/include/asm/hw_irq.h | 43 ++-
> 1 file changed, 36 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/hw_irq.h
> b/arch/powerpc/include/asm/hw_irq.h
> index 3c8cb48f88ae..983551859891 100644
> --- a/arch/powerpc/include/asm/hw_irq.h
> +++ b/arch/powerpc/include/asm/hw_irq.h
> @@ -113,7 +113,14 @@ static inline void __hard_RI_enable(void)
>
> static inline notrace unsigned long irq_soft_mask_return(void)
> {
> - return READ_ONCE(local_paca->irq_soft_mask);
> + unsigned long flags;
> +
> + asm volatile(
> + "lbz %0,%1(13)"
> + : "=r" (flags)
> + : "i" (offsetof(struct paca_struct, irq_soft_mask)));
> +
> + return flags;
> }
>
> /*
> @@ -140,24 +147,46 @@ static inline notrace void irq_soft_mask_set(unsigned
> long mask)
> if (IS_ENABLED(CONFIG_PPC_IRQ_SOFT_MASK_DEBUG))
> WARN_ON(mask && !(mask & IRQS_DISABLED));
>
> - WRITE_ONCE(local_paca->irq_soft_mask, mask);
> - barrier();
> + asm volatile(
> + "stb %0,%1(13)"
> + :
> + : "r" (mask),
> + "i" (offsetof(struct paca_struct, irq_soft_mask))
> + : "memory");
> }
Only the above changes need to be reverted, below ones should remain as
they are.
>
> static inline notrace unsigned long irq_soft_mask_set_return(unsigned long
> mask)
> {
> - unsigned long flags = irq_soft_mask_return();
> + unsigned long flags;
>
> - irq_soft_mask_set(mask);
> +#ifdef CONFIG_PPC_IRQ_SOFT_MASK_DEBUG
> + WARN_ON(mask && !(mask & IRQS_DISABLED));
> +#endif
> +
> + asm volatile(
> + "lbz %0,%1(13); stb %2,%1(13)"
> + : "=" (flags)
> + : "i" (offsetof(struct paca_struct, irq_soft_mask)),
> + "r" (mask)
> + : "memory");
>
> return flags;
> }
>
> static inline notrace unsigned long irq_soft_mask_or_return(unsigned long
> mask)
> {
> - unsigned long flags = irq_soft_mask_return();
> + unsigned long flags, tmp;
> +
> + asm volatile(
> + "lbz %0,%2(13); or %1,%0,%3; stb %1,%2(13)"
> + : "=" (flags), "=r" (tmp)
> + : "i" (offsetof(struct paca_struct, irq_soft_mask)),
> + "r" (mask)
> + : "memory");
>
> - irq_soft_mask_set(flags | mask);
> +#ifdef CONFIG_PPC_IRQ_SOFT_MASK_DEBUG
> + WARN_ON((mask | flags) && !((mask | flags) & IRQS_DISABLED));
> +#endif
>
>
Re: [PATCH] powerpc: align syscall table for ppc32
On Sun, 21 Aug 2022 01:51:29 +0900, Masahiro Yamada wrote:
> Christophe Leroy reported that commit 7b4537199a4a ("kbuild: link
> symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS") broke
> mpc85xx_defconfig + CONFIG_RELOCATABLE=y.
>
> LD vmlinux
> SYSMAP System.map
> SORTTAB vmlinux
> CHKREL vmlinux
> WARNING: 451 bad relocations
> c0b312a9 R_PPC_UADDR32 .head.text-0x3ff9ed54
> c0b312ad R_PPC_UADDR32 .head.text-0x3ffac224
> c0b312b1 R_PPC_UADDR32 .head.text-0x3ffb09f4
> c0b312b5 R_PPC_UADDR32 .head.text-0x3fe184dc
> c0b312b9 R_PPC_UADDR32 .head.text-0x3fe183a8
> ...
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc: align syscall table for ppc32
https://git.kernel.org/powerpc/c/c7acee3d2f128a38b68fb7af85dbbd91bfd0b4ad
cheers
Re: [PATCH 1/2] Revert "powerpc: Remove unused FW_FEATURE_NATIVE references"
On Tue, 23 Aug 2022 21:59:51 +1000, Michael Ellerman wrote: > This reverts commit 79b74a68486765a4fe685ac4069bc71366c538f5. > > It broke booting on IBM Cell machines when the kernel is also built with > CONFIG_PPC_PS3=y. > > That's because FW_FEATURE_NATIVE_ALWAYS = 0 does have an important > effect, which is to clear the PS3 ALWAYS features from > FW_FEATURE_ALWAYS. > > [...] Applied to powerpc/fixes. [1/2] Revert "powerpc: Remove unused FW_FEATURE_NATIVE references" https://git.kernel.org/powerpc/c/310d1344e3c58cc2d625aa4e52cfcb7d8a26fcbf [2/2] powerpc/rtas: Fix RTAS MSR[HV] handling for Cell https://git.kernel.org/powerpc/c/91926d8b7e71aaf5f84f0cf208fc5a8b7a761050 cheers
Re: [PATCH] powerpc/pci: Enable PCI domains in /proc when PCI bus numbers are not unique
On Sat, 20 Aug 2022 13:51:13 +0200, Pali Rohár wrote: > On 32-bit powerpc systems with more PCIe controllers and more PCI domains, > where on more PCI domains are same PCI numbers, when kernel is compiled > with CONFIG_PROC_FS=y and CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT=y > options, kernel prints "proc_dir_entry 'pci/01' already registered" error > message. > > [1.708861] [ cut here ] > [1.713429] proc_dir_entry 'pci/01' already registered > [1.718595] WARNING: CPU: 0 PID: 1 at fs/proc/generic.c:377 > proc_register+0x1a8/0x1ac > [1.726361] Modules linked in: > [1.729404] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW > 5.19.0-rc5-0caacb197b677410bdac81bc34f05235+ #109 > [1.740183] NIP: c02846e8 LR: c02846e8 CTR: c0015154 > [1.745225] REGS: c146fc90 TRAP: 0700 Tainted: GW > (5.19.0-rc5-0caacb197b677410bdac81bc34f05235+) > [1.755657] MSR: 00029000 CR: 28000822 XER: > [1.761829] > [1.761829] GPR00: c02846e8 c146fd80 c14a8000 002a 3fffefff c146fc40 > c146fc38 > [1.761829] GPR08: 3fffefff c10ac04c 24000824 > c0004548 > [1.761829] GPR16: > 0007 > [1.761829] GPR24: c1d0 c167da54 c167da00 c112 c167dd6c c10b4abc > c167dc58 c167dd00 > [1.796707] NIP [c02846e8] proc_register+0x1a8/0x1ac > [1.801663] LR [c02846e8] proc_register+0x1a8/0x1ac > [1.806532] Call Trace: > [1.808966] [c146fd80] [c02846e8] proc_register+0x1a8/0x1ac (unreliable) > [1.815659] [c146fdb0] [c028481c] _proc_mkdir+0x78/0xa4 > [1.820875] [c146fdd0] [c05a92e4] pci_proc_attach_device+0x11c/0x168 > [1.827221] [c146fe10] [c101f7a4] pci_proc_init+0x80/0x98 > [1.832611] [c146fe30] [c0004150] do_one_initcall+0x80/0x284 > [1.838262] [c146fea0] [c10011a8] kernel_init_freeable+0x1f4/0x2a0 > [1.844434] [c146fee0] [c000456c] kernel_init+0x24/0x150 > [1.849737] [c146ff00] [c001326c] ret_from_kernel_thread+0x5c/0x64 > [1.855910] Instruction dump: > [1.858866] 83810020 83a10024 83c10028 83e1002c 38210030 4e800020 > 809a0064 3c60c0a8 > [1.866602] 7f85e378 3863af28 4cc63182 4bdb8155 <0fe0> 9421ffe0 > 3920 7c0802a6 > [1.874513] ---[ end trace ]--- > > [...] Applied to powerpc/fixes. [1/1] powerpc/pci: Enable PCI domains in /proc when PCI bus numbers are not unique https://git.kernel.org/powerpc/c/0382a35bef70ecc074db67192ff8d37737d02b21 cheers
Re: [PATCH v3] powerpc/papr_scm: Fix nvdimm event mappings
On Thu, 4 Aug 2022 13:18:52 +0530, Kajol Jain wrote:
> Commit 4c08d4bbc089 ("powerpc/papr_scm: Add perf interface support")
> added performance monitoring support for papr-scm nvdimm devices via
> perf interface. Commit also added an array in papr_scm_priv
> structure called "nvdimm_events_map", which got filled based on the
> result of H_SCM_PERFORMANCE_STATS hcall.
>
> Currently there is an assumption that the order of events in the
> stats buffer, returned by the hypervisor is same. And order also
> happens to matches with the events specified in nvdimm driver code.
> But this assumption is not documented in Power Architecture
> Platform Requirements (PAPR) document. Although the order
> of events happens to be same on current generation od system, but
> it might not be true in future generation systems. Fix the issue, by
> adding a static mapping for nvdimm events to corresponding stat-id,
> and removing the dynamic map from papr_scm_priv structure. Also
> remove the function papr_scm_pmu_check_events from papr_scm.c file,
> as we no longer need to copy stat-ids dynamically.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/papr_scm: Fix nvdimm event mappings
https://git.kernel.org/powerpc/c/9b1ac04698a4bfec146322502cdcd9904c1777fa
cheers
[PATCH] Revert "powerpc/irq: Don't open code irq_soft_mask helpers"
This reverts commit ef5b570d3700fbb8628a58da0487486ceeb713cd.
Zhouyi reported that commit is causing crashes when running rcutorture
with KASAN enabled:
BUG: using smp_processor_id() in preemptible [] code:
rcu_torture_rea/100
caller is rcu_preempt_deferred_qs_irqrestore+0x74/0xed0
CPU: 4 PID: 100 Comm: rcu_torture_rea Tainted: GW
5.19.0-rc5-next-20220708-dirty #253
Call Trace:
dump_stack_lvl+0xbc/0x108 (unreliable)
check_preemption_disabled+0x154/0x160
rcu_preempt_deferred_qs_irqrestore+0x74/0xed0
__rcu_read_unlock+0x290/0x3b0
rcu_torture_read_unlock+0x30/0xb0
rcutorture_one_extend+0x198/0x810
rcu_torture_one_read+0x58c/0xc90
rcu_torture_reader+0x12c/0x360
kthread+0x1e8/0x220
ret_from_kernel_thread+0x5c/0x64
KASAN will generate instrumentation instructions around the
WRITE_ONCE(local_paca->irq_soft_mask, mask):
0xc0295cb0 <+0>: addis r2,r12,774
0xc0295cb4 <+4>: addir2,r2,16464
0xc0295cb8 <+8>: mflrr0
0xc0295cbc <+12>:bl 0xc008bb4c
0xc0295cc0 <+16>:mflrr0
0xc0295cc4 <+20>:std r31,-8(r1)
0xc0295cc8 <+24>:addir3,r13,2354
0xc0295ccc <+28>:mr r31,r13
0xc0295cd0 <+32>:std r0,16(r1)
0xc0295cd4 <+36>:stdur1,-48(r1)
0xc0295cd8 <+40>:bl 0xc0609b98 <__asan_store1+8>
0xc0295cdc <+44>:nop
0xc0295ce0 <+48>:li r9,1
0xc0295ce4 <+52>:stb r9,2354(r31)
0xc0295ce8 <+56>:addir1,r1,48
0xc0295cec <+60>:ld r0,16(r1)
0xc0295cf0 <+64>:ld r31,-8(r1)
0xc0295cf4 <+68>:mtlrr0
If there is a context switch before "stb r9,2354(r31)", r31 may
not equal to r13, in such case, irq soft mask will not work.
The usual solution of marking the code ineligible for instrumentation
forces the code out-of-line, which we would prefer to avoid. Christophe
proposed a partial revert, but Nick raised some concerns with that. So
for now do a full revert.
Reported-by: Zhouyi Zhou
[mpe: Construct change log based on Zhouyi's original report]
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/hw_irq.h | 43 ++-
1 file changed, 36 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/hw_irq.h
b/arch/powerpc/include/asm/hw_irq.h
index 3c8cb48f88ae..983551859891 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -113,7 +113,14 @@ static inline void __hard_RI_enable(void)
static inline notrace unsigned long irq_soft_mask_return(void)
{
- return READ_ONCE(local_paca->irq_soft_mask);
+ unsigned long flags;
+
+ asm volatile(
+ "lbz %0,%1(13)"
+ : "=r" (flags)
+ : "i" (offsetof(struct paca_struct, irq_soft_mask)));
+
+ return flags;
}
/*
@@ -140,24 +147,46 @@ static inline notrace void irq_soft_mask_set(unsigned
long mask)
if (IS_ENABLED(CONFIG_PPC_IRQ_SOFT_MASK_DEBUG))
WARN_ON(mask && !(mask & IRQS_DISABLED));
- WRITE_ONCE(local_paca->irq_soft_mask, mask);
- barrier();
+ asm volatile(
+ "stb %0,%1(13)"
+ :
+ : "r" (mask),
+ "i" (offsetof(struct paca_struct, irq_soft_mask))
+ : "memory");
}
static inline notrace unsigned long irq_soft_mask_set_return(unsigned long
mask)
{
- unsigned long flags = irq_soft_mask_return();
+ unsigned long flags;
- irq_soft_mask_set(mask);
+#ifdef CONFIG_PPC_IRQ_SOFT_MASK_DEBUG
+ WARN_ON(mask && !(mask & IRQS_DISABLED));
+#endif
+
+ asm volatile(
+ "lbz %0,%1(13); stb %2,%1(13)"
+ : "=" (flags)
+ : "i" (offsetof(struct paca_struct, irq_soft_mask)),
+ "r" (mask)
+ : "memory");
return flags;
}
static inline notrace unsigned long irq_soft_mask_or_return(unsigned long mask)
{
- unsigned long flags = irq_soft_mask_return();
+ unsigned long flags, tmp;
+
+ asm volatile(
+ "lbz %0,%2(13); or %1,%0,%3; stb %1,%2(13)"
+ : "=" (flags), "=r" (tmp)
+ : "i" (offsetof(struct paca_struct, irq_soft_mask)),
+ "r" (mask)
+ : "memory");
- irq_soft_mask_set(flags | mask);
+#ifdef CONFIG_PPC_IRQ_SOFT_MASK_DEBUG
+ WARN_ON((mask | flags) && !((mask | flags) & IRQS_DISABLED));
+#endif
return flags;
}
--
2.37.2
Re: [PATCH v2 16/16] objtool/powerpc: Add --mcount specific implementation
Le 29/08/2022 à 07:52, Sathvika Vasireddy a écrit :
> This patch enables objtool --mcount on powerpc, and
> adds implementation specific to powerpc.
>
> Signed-off-by: Sathvika Vasireddy
> ---
> arch/powerpc/Kconfig | 1 +
> tools/objtool/arch/powerpc/decode.c | 22 +++
> tools/objtool/arch/powerpc/include/arch/elf.h | 2 ++
> 3 files changed, 25 insertions(+)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index dc05cd23c233..6be2e68fa9eb 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -238,6 +238,7 @@ config PPC
> select HAVE_NMI if PERF_EVENTS || (PPC64 &&
> PPC_BOOK3S)
> select HAVE_OPTPROBES
> select HAVE_OBJTOOL if PPC32 || MPROFILE_KERNEL
> + select HAVE_OBJTOOL_MCOUNT if HAVE_OBJTOOL
> select HAVE_PERF_EVENTS
> select HAVE_PERF_EVENTS_NMI if PPC64
> select HAVE_PERF_REGS
> diff --git a/tools/objtool/arch/powerpc/decode.c
> b/tools/objtool/arch/powerpc/decode.c
> index 8b6a14680da7..b71c265ed503 100644
> --- a/tools/objtool/arch/powerpc/decode.c
> +++ b/tools/objtool/arch/powerpc/decode.c
> @@ -9,6 +9,14 @@
> #include
> #include
>
> +bool arch_ftrace_match(char *name)
> +{
> + if (!strcmp(name, "_mcount"))
> + return true;
> +
> + return false;
> +}
> +
> unsigned long arch_dest_reloc_offset(int addend)
> {
> return addend;
> @@ -41,12 +49,26 @@ int arch_decode_instruction(struct objtool_file *file,
> const struct section *sec
> struct list_head *ops_list)
> {
> u32 insn;
> + unsigned int opcode;
>
> *immediate = 0;
> insn = bswap_if_needed(file->elf, *(u32 *)(sec->data->d_buf + offset));
> *len = 4;
> *type = INSN_OTHER;
>
> + opcode = insn >> 26;
> +
> + switch (opcode) {
> + case 18: /* bl */
case 18 is more than 'bl', it includes also 'b'.
In both cases, the calculation of *immediate is the same.
It would therefore be more correct to perform the calculation and setup
of *immediate outside the 'if ((insn & 3) == 1)', that would avoid
unnecessary churn the day we add support for branches without link.
> + if ((insn & 3) == 1) {
> + *type = INSN_CALL;
> + *immediate = insn & 0x3fc;
> + if (*immediate & 0x200)
> + *immediate -= 0x400;
> + }
> + break;
> + }
> +
> return 0;
> }
>
> diff --git a/tools/objtool/arch/powerpc/include/arch/elf.h
> b/tools/objtool/arch/powerpc/include/arch/elf.h
> index 3c8ebb7d2a6b..73f9ae172fe5 100644
> --- a/tools/objtool/arch/powerpc/include/arch/elf.h
> +++ b/tools/objtool/arch/powerpc/include/arch/elf.h
> @@ -4,5 +4,7 @@
> #define _OBJTOOL_ARCH_ELF
>
> #define R_NONE R_PPC_NONE
> +#define R_ABS64 R_PPC64_ADDR64
> +#define R_ABS32 R_PPC_ADDR32
>
> #endif /* _OBJTOOL_ARCH_ELF */
[PATCH] powerpc/64s: add pte_needs_flush and huge_pmd_needs_flush
Allow PTE changes to avoid flushing the TLB when access permissions are
being relaxed, the dirty bit is being set, and the accessed bit is being
changed.
Relaxing access permissions and setting dirty and accessed bits do not
require a flush because the MMU will re-load the PTE and notice the
updates (it may also cause a spurious fault).
Clearing the accessed bit does not require a flush because of the
imprecise PTE accessed bit accounting that is already performed, as
documented in ptep_clear_flush_young().
This reduces TLB flushing for some mprotect(2) calls.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/book3s/64/pgtable.h | 3 ++
arch/powerpc/include/asm/book3s/64/tlbflush.h | 53 +++
arch/powerpc/mm/book3s64/hash_tlb.c | 1 +
arch/powerpc/mm/book3s64/pgtable.c| 1 +
4 files changed, 58 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index cb9d5fd39d7f..a5042bb9a30c 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -411,6 +411,9 @@ static inline int __ptep_test_and_clear_young(struct
mm_struct *mm,
* event of it not getting flushed for a long time the delay
* shouldn't really matter because there's no real memory
* pressure for swapout to react to. ]
+ *
+ * Note: this optimisation also exists in pte_needs_flush() and
+ * huge_pmd_needs_flush().
*/
#define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
#define ptep_clear_flush_young ptep_test_and_clear_young
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h
b/arch/powerpc/include/asm/book3s/64/tlbflush.h
index d2e80f178b6d..bcd7cb585d17 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
@@ -143,6 +143,59 @@ static inline void flush_tlb_fix_spurious_fault(struct
vm_area_struct *vma,
flush_tlb_page(vma, address);
}
+static inline bool __pte_flags_need_flush(unsigned long oldval, unsigned long
newval)
+{
+ unsigned long delta = oldval ^ newval;
+
+ /*
+* The return value of this function doesn't matter for hash,
+* ptep_modify_prot_start() does a pte_update() which does or schedules
+* any necessary hash table update and flush.
+*/
+ if (!radix_enabled())
+ return true;
+
+ /*
+* In theory some changed software bits could be tolerated, in practice
+* those should rarely if ever matter.
+*/
+
+ /* Don't deal with kernel mappings or non-PTEs or not-present PTEs */
+ VM_BUG_ON((oldval | newval) & _PAGE_PRIVILEGED);
+ VM_BUG_ON(!((oldval | newval) & _PAGE_PTE));
+ VM_BUG_ON(!((oldval | newval) & _PAGE_PRESENT));
+
+ /* Must flush on any change except READ, WRITE, EXEC, DIRTY, ACCESSED */
+ if (delta & ~(_PAGE_RWX | _PAGE_DIRTY | _PAGE_ACCESSED))
+ return true;
+
+ /*
+* If any of the above was present in old but cleared in new, flush.
+* With the exception of _PAGE_ACCESSED, don't worry about flushing
+* if that was cleared (see the comment in ptep_clear_flush_young()).
+*/
+ if ((delta & ~_PAGE_ACCESSED) & oldval)
+ return true;
+
+ return false;
+}
+
+#ifndef pte_needs_flush
+static inline bool pte_needs_flush(pte_t oldpte, pte_t newpte)
+{
+ return __pte_flags_need_flush(pte_val(oldpte), pte_val(newpte));
+}
+#define pte_needs_flush pte_needs_flush
+#endif
+
+#ifndef huge_pmd_needs_flush
+static inline bool huge_pmd_needs_flush(pmd_t oldpmd, pmd_t newpmd)
+{
+ return __pte_flags_need_flush(pmd_val(oldpmd), pmd_val(newpmd));
+}
+#define huge_pmd_needs_flush huge_pmd_needs_flush
+#endif
+
extern bool tlbie_capable;
extern bool tlbie_enabled;
--
2.37.2
Re: [PATCH] KVM: fix repeated words in comments
Le 31/08/2022 à 02:44, Jilin Yuan a écrit : > Delete the redundant word 'that'. > > Signed-off-by: Jilin Yuan This change was already proposed and rejected here : https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20220724062920.1551-1-wangjia...@cdjrlc.com/ Please study history before submitting such low-value changes. > --- > arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c > b/arch/powerpc/kvm/book3s_64_mmu_hv.c > index e9744b41a226..8e4b42b5f37f 100644 > --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c > +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c > @@ -1601,7 +1601,7 @@ long kvm_vm_ioctl_resize_hpt_commit(struct kvm *kvm, >* is valid, it is written to the HPT as if an H_ENTER with the >* exact flag set was done. When the invalid count is non-zero >* in the header written to the stream, the kernel will make > - * sure that that many HPTEs are invalid, and invalidate them > + * sure that many HPTEs are invalid, and invalidate them >* if not. >*/ >
[PATCH 3/3] powerpc/32: Remove wii_memory_fixups()
wii_memory_fixups() is not called anymore, remove it.
Also remove left-overs in mmu_decl.h which were forgotten by
commit 160985f3025b ("powerpc/wii: remove wii_mmu_mapin_mem2()")
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/mmu_decl.h | 8
arch/powerpc/platforms/embedded6xx/wii.c | 15 ---
2 files changed, 23 deletions(-)
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 6dd4744cc56a..0e3528aec49e 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -102,14 +102,6 @@ extern phys_addr_t total_lowmem;
extern phys_addr_t memstart_addr;
extern phys_addr_t lowmem_end_addr;
-#ifdef CONFIG_WII
-extern unsigned long wii_hole_start;
-extern unsigned long wii_hole_size;
-
-extern unsigned long wii_mmu_mapin_mem2(unsigned long top);
-extern void wii_memory_fixups(void);
-#endif
-
/* ...and now those things that may be slightly different between processor
* architectures. -- Dan
*/
diff --git a/arch/powerpc/platforms/embedded6xx/wii.c
b/arch/powerpc/platforms/embedded6xx/wii.c
index 9e03ff8f631c..f4e654a9d4ff 100644
--- a/arch/powerpc/platforms/embedded6xx/wii.c
+++ b/arch/powerpc/platforms/embedded6xx/wii.c
@@ -15,8 +15,6 @@
#include
#include
#include
-#include
-#include
#include
#include
@@ -49,19 +47,6 @@
static void __iomem *hw_ctrl;
static void __iomem *hw_gpio;
-static int __init page_aligned(unsigned long x)
-{
- return !(x & (PAGE_SIZE-1));
-}
-
-void __init wii_memory_fixups(void)
-{
- struct memblock_region *p = memblock.memory.regions;
-
- BUG_ON(memblock.memory.cnt != 2);
- BUG_ON(!page_aligned(p[0].base) || !page_aligned(p[1].base));
-}
-
static void __noreturn wii_spin(void)
{
local_irq_disable();
--
2.37.1
[PATCH 1/3] powerpc/32: Drop a stale comment about reservation of gigantic pages
A comment about the reservation of gigantic pages was left in MMU_init()
after commit 79cc38ded1e1 ("powerpc/mm/hugetlb: Add support for
reserving gigantic huge pages via kernel command line")
Remove it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/init_32.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 62d9af6606cd..50de41042c0a 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -82,10 +82,6 @@ void __init MMU_init(void)
if (ppc_md.progress)
ppc_md.progress("MMU:enter", 0x111);
- /*
-* Reserve gigantic pages for hugetlb. This MUST occur before
-* lowmem_end_addr is initialized below.
-*/
if (memblock.memory.cnt > 1) {
#ifndef CONFIG_WII
memblock_enforce_memory_limit(memblock.memory.regions[0].size);
--
2.37.1
[PATCH 2/3] powerpc/32: Allow fragmented physical memory
Since commit 9e849f231c3c ("powerpc/mm/32s: use generic mmu_mapin_ram()
for all blocks.") it is possible to map all blocks as RAM on any PPC32.
Remove related restrictions.
And remove call to wii_memory_fixups() which doesn't do anything else
than checks since commit 160985f3025b ("powerpc/wii: remove
wii_mmu_mapin_mem2()")
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/init_32.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 50de41042c0a..3142d7617412 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -82,15 +82,6 @@ void __init MMU_init(void)
if (ppc_md.progress)
ppc_md.progress("MMU:enter", 0x111);
- if (memblock.memory.cnt > 1) {
-#ifndef CONFIG_WII
- memblock_enforce_memory_limit(memblock.memory.regions[0].size);
- pr_warn("Only using first contiguous memory region\n");
-#else
- wii_memory_fixups();
-#endif
- }
-
total_lowmem = total_memory = memblock_end_of_DRAM() - memstart_addr;
lowmem_end_addr = memstart_addr + total_lowmem;
--
2.37.1
[PATCH] USB: FHCI: Switch to GPIO descriptors
This driver for the PPC Freescale SoC is using device tree
accessors and imperative GPIO semantics control using the old
GPIO API, switch it over to use GPIO descriptors.
Cc: Li Yang
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Zhao Qiang
Cc: Guilherme Maciel Ferreira
Signed-off-by: Linus Walleij
---
drivers/usb/host/fhci-hcd.c | 63 +++--
drivers/usb/host/fhci-hub.c | 15 +
drivers/usb/host/fhci.h | 4 +--
3 files changed, 27 insertions(+), 55 deletions(-)
diff --git a/drivers/usb/host/fhci-hcd.c b/drivers/usb/host/fhci-hcd.c
index 2ba09c3fbc2f..95a44462bed0 100644
--- a/drivers/usb/host/fhci-hcd.c
+++ b/drivers/usb/host/fhci-hcd.c
@@ -25,8 +25,8 @@
#include
#include
#include
-#include
#include
+#include
#include
#include
#include "fhci.h"
@@ -150,15 +150,15 @@ int fhci_ioports_check_bus_state(struct fhci_hcd *fhci)
u8 bits = 0;
/* check USBOE,if transmitting,exit */
- if (!gpio_get_value(fhci->gpios[GPIO_USBOE]))
+ if (!gpiod_get_value(fhci->gpiods[GPIO_USBOE]))
return -1;
/* check USBRP */
- if (gpio_get_value(fhci->gpios[GPIO_USBRP]))
+ if (gpiod_get_value(fhci->gpiods[GPIO_USBRP]))
bits |= 0x2;
/* check USBRN */
- if (gpio_get_value(fhci->gpios[GPIO_USBRN]))
+ if (gpiod_get_value(fhci->gpiods[GPIO_USBRN]))
bits |= 0x1;
return bits;
@@ -630,40 +630,23 @@ static int of_fhci_probe(struct platform_device *ofdev)
/* GPIOs and pins */
for (i = 0; i < NUM_GPIOS; i++) {
- int gpio;
- enum of_gpio_flags flags;
-
- gpio = of_get_gpio_flags(node, i, );
- fhci->gpios[i] = gpio;
- fhci->alow_gpios[i] = flags & OF_GPIO_ACTIVE_LOW;
-
- if (!gpio_is_valid(gpio)) {
- if (i < GPIO_SPEED) {
- dev_err(dev, "incorrect GPIO%d: %d\n",
- i, gpio);
- goto err_gpios;
- } else {
- dev_info(dev, "assuming board doesn't have "
- "%s gpio\n", i == GPIO_SPEED ?
- "speed" : "power");
- continue;
- }
- }
+ if (i < GPIO_SPEED)
+ fhci->gpiods[i] = devm_gpiod_get_index(dev,
+ NULL, i, GPIOD_IN);
+
+ else
+ fhci->gpiods[i] = devm_gpiod_get_index_optional(dev,
+ NULL, i, GPIOD_OUT_LOW);
- ret = gpio_request(gpio, dev_name(dev));
- if (ret) {
- dev_err(dev, "failed to request gpio %d", i);
+ if (IS_ERR(fhci->gpiods[i])) {
+ dev_err(dev, "incorrect GPIO%d: %ld\n",
+ i, PTR_ERR(fhci->gpiods[i]));
goto err_gpios;
}
-
- if (i >= GPIO_SPEED) {
- ret = gpio_direction_output(gpio, 0);
- if (ret) {
- dev_err(dev, "failed to set gpio %d as "
- "an output\n", i);
- i++;
- goto err_gpios;
- }
+ if (!fhci->gpiods[i]) {
+ dev_info(dev, "assuming board doesn't have "
+"%s gpio\n", i == GPIO_SPEED ?
+"speed" : "power");
}
}
@@ -766,10 +749,6 @@ static int of_fhci_probe(struct platform_device *ofdev)
while (--j >= 0)
qe_pin_free(fhci->pins[j]);
err_gpios:
- while (--i >= 0) {
- if (gpio_is_valid(fhci->gpios[i]))
- gpio_free(fhci->gpios[i]);
- }
cpm_muram_free(pram_addr);
err_pram:
iounmap(hcd->regs);
@@ -782,18 +761,12 @@ static int fhci_remove(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct fhci_hcd *fhci = hcd_to_fhci(hcd);
- int i;
int j;
usb_remove_hcd(hcd);
free_irq(fhci->timer->irq, hcd);
gtm_put_timer16(fhci->timer);
cpm_muram_free(cpm_muram_offset(fhci->pram));
- for (i = 0; i < NUM_GPIOS; i++) {
- if (!gpio_is_valid(fhci->gpios[i]))
- continue;
- gpio_free(fhci->gpios[i]);
- }
for (j = 0; j < NUM_PINS; j++)
qe_pin_free(fhci->pins[j]);
fhci_dfs_destroy(fhci);
diff --git a/drivers/usb/host/fhci-hub.c b/drivers/usb/host/fhci-hub.c
index c359dcdb9b13..5f48660ebdfa 100644
--- a/drivers/usb/host/fhci-hub.c
+++ b/drivers/usb/host/fhci-hub.c
@@ -19,7 +19,7 @@
[PATCH v3 1/3] dt-bindings: reset: syscon-reboot: Add priority property
This new optional priority property allows to specify custom priority level of reset device. Prior this change priority level was hardcoded to 192 and not possible to specify or change. Specifying other value is needed for some boards. Default level when not specified stays at 192 as before. Signed-off-by: Pali Rohár --- Changes in v3: * Add explanation into commit message Changes in v2: * Change sint32 to int32 * Add default --- .../devicetree/bindings/power/reset/syscon-reboot.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml index da2509724812..4c8b0d0a0111 100644 --- a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml @@ -42,6 +42,11 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 description: The reset value written to the reboot register (32 bit access). + priority: +$ref: /schemas/types.yaml#/definitions/int32 +description: Priority level of this syscon reset device. +default: 192 + required: - compatible - offset -- 2.20.1
[PATCH v3 2/3] power: reset: syscon-reboot: Add support for specifying priority
Read new optional device tree property priority for specifying priority level of reset handler. Default value is 192 as before. Signed-off-by: Pali Rohár --- drivers/power/reset/syscon-reboot.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/power/reset/syscon-reboot.c b/drivers/power/reset/syscon-reboot.c index 510e363381ca..45e34e6885f7 100644 --- a/drivers/power/reset/syscon-reboot.c +++ b/drivers/power/reset/syscon-reboot.c @@ -44,6 +44,7 @@ static int syscon_reboot_probe(struct platform_device *pdev) struct syscon_reboot_context *ctx; struct device *dev = >dev; int mask_err, value_err; + int priority; int err; ctx = devm_kzalloc(>dev, sizeof(*ctx), GFP_KERNEL); @@ -57,6 +58,9 @@ static int syscon_reboot_probe(struct platform_device *pdev) return PTR_ERR(ctx->map); } + if (of_property_read_s32(pdev->dev.of_node, "priority", )) + priority = 192; + if (of_property_read_u32(pdev->dev.of_node, "offset", >offset)) return -EINVAL; @@ -77,7 +81,7 @@ static int syscon_reboot_probe(struct platform_device *pdev) } ctx->restart_handler.notifier_call = syscon_restart_handle; - ctx->restart_handler.priority = 192; + ctx->restart_handler.priority = priority; err = register_restart_handler(>restart_handler); if (err) dev_err(dev, "can't register restart notifier (err=%d)\n", err); -- 2.20.1
[PATCH v3 3/3] powerpc: dts: turris1x.dts: Set lower priority for CPLD syscon-reboot
Due to CPLD firmware bugs, set CPLD syscon-reboot priority level to 64
(between rstcr and watchdog) to ensure that rstcr's global-utilities reset
method which is preferred stay as default one, and to ensure that CPLD
syscon-reboot is more preferred than watchdog reset method.
Fixes: 0531a4abd1c6 ("powerpc: dts: turris1x.dts: Add CPLD reboot node")
Signed-off-by: Pali Rohár
---
arch/powerpc/boot/dts/turris1x.dts | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/powerpc/boot/dts/turris1x.dts
b/arch/powerpc/boot/dts/turris1x.dts
index 69c38ed8a3a5..c189293d5a1e 100644
--- a/arch/powerpc/boot/dts/turris1x.dts
+++ b/arch/powerpc/boot/dts/turris1x.dts
@@ -353,11 +353,34 @@
};
reboot@d {
+ /*
+* CPLD firmware which manages system reset and
+* watchdog registers has bugs. It does not
+* autoclear system reset register after change
+* and watchdog ignores reset line on immediate
+* succeeding reset cycle triggered by watchdog.
+* These bugs have to be workarounded in U-Boot
+* bootloader. So use system reset via syscon as
+* a last resort because older U-Boot versions
+* do not have workaround for watchdog.
+*
+* Reset method via rstcr's global-utilities
+* (the preferred one) has priority level 128,
+* watchdog has priority level 0 and default
+* syscon-reboot priority level is 192.
+*
+* So define syscon-reboot with custom priority
+* level 64 (between rstcr and watchdog) because
+* rstcr should stay as default preferred reset
+* method and reset via watchdog is more broken
+* than system reset via syscon.
+*/
compatible = "syscon-reboot";
reg = <0x0d 0x01>;
offset = <0x0d>;
mask = <0x01>;
value = <0x01>;
+ priority = <64>;
};
led-controller@13 {
--
2.20.1
Re: [PATCH v5] livepatch: Clear relocation targets on a module removal
Le 30/08/2022 à 20:53, Song Liu a écrit :
> From: Miroslav Benes
>
> Josh reported a bug:
>
>When the object to be patched is a module, and that module is
>rmmod'ed and reloaded, it fails to load with:
>
>module: x86/modules: Skipping invalid relocation target, existing value is
> nonzero for type 2, loc ba0302e9, val a03e293c
>livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd'
> (-8)
>livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to
> load module 'nfsd'
>
>The livepatch module has a relocation which references a symbol
>in the _previous_ loading of nfsd. When apply_relocate_add()
>tries to replace the old relocation with a new one, it sees that
>the previous one is nonzero and it errors out.
>
>On ppc64le, we have a similar issue:
>
>module_64: livepatch_nfsd: Expected nop after call, got e8410018 at
> e_show+0x60/0x548 [livepatch_nfsd]
>livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd'
> (-8)
>livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to
> load module 'nfsd'
>
> He also proposed three different solutions. We could remove the error
> check in apply_relocate_add() introduced by commit eda9cec4c9a1
> ("x86/module: Detect and skip invalid relocations"). However the check
> is useful for detecting corrupted modules.
>
> We could also deny the patched modules to be removed. If it proved to be
> a major drawback for users, we could still implement a different
> approach. The solution would also complicate the existing code a lot.
>
> We thus decided to reverse the relocation patching (clear all relocation
> targets on x86_64). The solution is not
> universal and is too much arch-specific, but it may prove to be simpler
> in the end.
>
> Reported-by: Josh Poimboeuf
> Signed-off-by: Miroslav Benes
> Signed-off-by: Song Liu
>
> ---
>
> NOTE: powerpc code has not be tested.
>
> Changes v4 = v5:
> 1. Fix compile with powerpc.
Not completely it seems.
CC kernel/livepatch/core.o
kernel/livepatch/core.c: In function 'klp_clear_object_relocations':
kernel/livepatch/core.c:352:50: error: passing argument 1 of
'clear_relocate_add' from incompatible pointer type
[-Werror=incompatible-pointer-types]
352 | clear_relocate_add(pmod->klp_info->sechdrs,
|~~^
| |
| Elf32_Shdr *
{aka struct elf32_shdr *}
In file included from kernel/livepatch/core.c:19:
./include/linux/moduleloader.h:76:37: note: expected 'Elf64_Shdr *' {aka
'struct elf64_shdr *'} but argument is of type 'Elf32_Shdr *' {aka
'struct elf32_shdr *'}
76 | void clear_relocate_add(Elf64_Shdr *sechdrs,
| ^~~
cc1: some warnings being treated as errors
Fixup:
diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
index d22b36b84b4b..958e6da7f475 100644
--- a/include/linux/moduleloader.h
+++ b/include/linux/moduleloader.h
@@ -73,7 +73,7 @@ int apply_relocate_add(Elf_Shdr *sechdrs,
unsigned int relsec,
struct module *mod);
#ifdef CONFIG_LIVEPATCH
-void clear_relocate_add(Elf64_Shdr *sechdrs,
+void clear_relocate_add(Elf_Shdr *sechdrs,
const char *strtab,
unsigned int symindex,
unsigned int relsec,
But then the link fails.
LD .tmp_vmlinux.kallsyms1
powerpc64-linux-ld: kernel/livepatch/core.o: in function
`klp_cleanup_module_patches_limited':
core.c:(.text+0xdb4): undefined reference to `clear_relocate_add'
Christophe
>
> Changes v3 = v4:
> 1. Reuse __apply_relocate_add to make it more reliable in long term.
> (Josh Poimboeuf)
> 2. Add back ppc64 logic from v2, with changes to match current code.
> (Josh Poimboeuf)
>
> Changes v2 => v3:
> 1. Rewrite x86 changes to match current code style.
> 2. Remove powerpc changes as there is no test coverage in v3.
> 3. Only keep 1/3 of v2.
>
> v2: https://lore.kernel.org/all/20190905124514.8944-1-mbe...@suse.cz/T/#u
> ---
> arch/powerpc/kernel/module_64.c | 49 +++
> arch/s390/kernel/module.c | 8 +++
> arch/x86/kernel/module.c| 102 +++-
> include/linux/moduleloader.h| 7 +++
> kernel/livepatch/core.c | 41 -
> 5 files changed, 179 insertions(+), 28 deletions(-)
>
> diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
> index 7e45dc98df8a..6aaf5720070d 100644
> --- a/arch/powerpc/kernel/module_64.c
> +++ b/arch/powerpc/kernel/module_64.c
> @@ -739,6 +739,55 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
> return 0;
> }
>
> +#ifdef CONFIG_LIVEPATCH
> +void clear_relocate_add(Elf64_Shdr *sechdrs,
> +
Re: [PATCH v2 1/3] dt-bindings: reset: syscon-reboot: Add priority property
On 31/08/2022 10:36, Pali Rohár wrote: > On Wednesday 31 August 2022 10:31:22 Krzysztof Kozlowski wrote: >> On 31/08/2022 02:00, Pali Rohár wrote: >>> This new optional priority property allows to specify custom priority level >>> of reset device. Default level was always 192. >> >> You still did not explain why do we need this. You only explained what >> you did here, which is obvious and visible from the diff. What you >> should explain is why you are doing it, what problem you are solving. >> >> Best regards, >> Krzysztof > > Look at patch 3/3, thanks. This commit should explain it why you add new property. Some other commits going via different trees/branches and ending up in entirely different time/place in history do not really count. Best regards, Krzysztof
Re: [PATCH v2 1/3] dt-bindings: reset: syscon-reboot: Add priority property
On Wednesday 31 August 2022 10:31:22 Krzysztof Kozlowski wrote: > On 31/08/2022 02:00, Pali Rohár wrote: > > This new optional priority property allows to specify custom priority level > > of reset device. Default level was always 192. > > You still did not explain why do we need this. You only explained what > you did here, which is obvious and visible from the diff. What you > should explain is why you are doing it, what problem you are solving. > > Best regards, > Krzysztof Look at patch 3/3, thanks.
Re: [PATCH v2 1/3] dt-bindings: reset: syscon-reboot: Add priority property
On Wed, Aug 31, 2022, at 1:00 AM, Pali Rohár wrote: > a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml > b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml > index da2509724812..4c8b0d0a0111 100644 > --- a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml > +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml > @@ -42,6 +42,11 @@ properties: > $ref: /schemas/types.yaml#/definitions/uint32 > description: The reset value written to the reboot register (32 > bit access). > > + priority: > +$ref: /schemas/types.yaml#/definitions/int32 > +description: Priority level of this syscon reset device. > +default: 192 > + My first thought was that this is looks very Linux specific and probably should be documented as such. However I see there is already precedent in Documentation/devicetree/bindings/power/reset/gpio-restart.yaml, which defines the same thing with a more detailed description. Since this is an optional property for both, and it has the same meaning here, is it possible to move the description to a common place where it either gets included from both, or from all reboot bindings? Arnd
Re: [PATCH v2 1/3] dt-bindings: reset: syscon-reboot: Add priority property
On 31/08/2022 02:00, Pali Rohár wrote: > This new optional priority property allows to specify custom priority level > of reset device. Default level was always 192. You still did not explain why do we need this. You only explained what you did here, which is obvious and visible from the diff. What you should explain is why you are doing it, what problem you are solving. Best regards, Krzysztof
Re: [PATCH v2 02/16] powerpc: override __ALIGN() and __ALIGN_STR() macros
"Nicholas Piggin" writes: > On Mon Aug 29, 2022 at 3:52 PM AEST, Sathvika Vasireddy wrote: >> Powerpc instructions must be word-aligned. Currently, >> there is an alignment of 16 bytes (by default), and it is >> much more than what is required for powerpc (4 bytes). >> >> The default expansion of __ALIGN() macro is: >> #define __ALIGN .align 4,0x90 >> >> Since Powerpc Linux does not require a 16 byte alignment, >> override __ALIGN() and __ALIGN_STR() macros to use required >> 4 byte alignment. > > Alignment can be desirable beyond the minimum requirement, for > example 16 byte alignment for functions could be helpful for > instruction fetch. So it should be explained why possible > benefits of the larger alignment are not worth it. Using ".align 2" matches what our existing _GLOBAL macro does. So this change basically just propagates that existing alignment into this new macro, which is used for similar purposes. So if we want to increase the alignment we should do that explicitly, and update _GLOBAL at the same time. The change log should probably just say ~= "use the same alignment as the existing _GLOBAL macro". What's more important, but not mentioned in the change log, is that we don't want to pad with 0x90, because repeated 0x90s are not a nop or trap on powerpc. cheers
