[PATCH] powerpc/powernv: Free name on error in opal_event_init()
In opal_event_init() if request_irq() fails name is not freed, leading
to a memory leak. The code only runs at boot time, there's no way for a
user to trigger it, so there's no security impact.
Fix the leak by freeing name in the error path.
Reported-by: 2639161967 <2639161...@qq.com>
Closes: https://lore.kernel.org/linuxppc-dev/87wmjp3wig.fsf@mail.lhotse
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/powernv/opal-irqchip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/powernv/opal-irqchip.c
b/arch/powerpc/platforms/powernv/opal-irqchip.c
index 56a1f7ce78d2..d92759c21fae 100644
--- a/arch/powerpc/platforms/powernv/opal-irqchip.c
+++ b/arch/powerpc/platforms/powernv/opal-irqchip.c
@@ -282,6 +282,7 @@ int __init opal_event_init(void)
name, NULL);
if (rc) {
pr_warn("Error %d requesting OPAL irq %d\n", rc,
(int)r->start);
+ kfree(name);
continue;
}
}
--
2.46.1
Re: [PATCH] powerpc/vdso32: Fix use of crtsavres for PPC64
On Thu, 19 Sep 2024 20:55:57 +0200, Christophe Leroy wrote: > crtsavres.S content is encloded by a #ifndef CONFIG_PPC64 > > To be used on VDSO32 on PPC64 it's content must available on PPC64 as > well. > > Replace #ifndef CONFIG_PPC64 by #ifndef __powerpc64__ as __powerpc64__ > is not set when building VDSO32 on PPC64. > > [...] Applied to powerpc/fixes. [1/1] powerpc/vdso32: Fix use of crtsavres for PPC64 https://git.kernel.org/powerpc/c/699d53f04829d6b8855ff458f86e4b75ef3e5f0c cheers
Re: [PATCH] powerpc/pseries/eeh: move pseries_eeh_err_inject() outside CONFIG_DEBUG_FS block
On Tue, 17 Sep 2024 09:24:45 -0400, Narayana Murty N wrote: > Makes pseries_eeh_err_inject() available even when debugfs > is disabled (CONFIG_DEBUG_FS=n). It moves eeh_debugfs_break_device() > and eeh_pe_inject_mmio_error() out of the CONFIG_DEBUG_FS block > and renames it as eeh_break_device(). > > Applied to powerpc/fixes. [1/1] powerpc/pseries/eeh: move pseries_eeh_err_inject() outside CONFIG_DEBUG_FS block https://git.kernel.org/powerpc/c/3af2e2f68cc6baf0a11f662d30b0bf981f77bfea cheers
Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits
Charlie Jenkins writes:
> On Wed, Sep 11, 2024 at 11:38:55PM +1000, Michael Ellerman wrote:
>> Geert Uytterhoeven writes:
>> > Hi Christophe,
>> >
>> > On Tue, Sep 10, 2024 at 11:21 AM Christophe Leroy
>> > wrote:
>> >> >>> diff --git a/include/uapi/linux/personality.h
>> >> >>> b/include/uapi/linux/personality.h
>> >> >>> index 49796b7756af..cd3b8c154d9b 100644
>> >> >>> --- a/include/uapi/linux/personality.h
>> >> >>> +++ b/include/uapi/linux/personality.h
>> >> >>> @@ -22,6 +22,7 @@ enum {
>> >> >>> WHOLE_SECONDS = 0x200,
>> >> >>> STICKY_TIMEOUTS = 0x400,
>> >> >>> ADDR_LIMIT_3GB =0x800,
>> >> >>> + ADDR_LIMIT_47BIT = 0x1000,
>> >> >>> };
>> >> >>
>> >> >> I wonder if ADDR_LIMIT_128T would be clearer?
>> >> >>
>> >> >
>> >> > I don't follow, what does 128T represent?
>> >>
>> >> 128T is 128 Terabytes, that's the maximum size achievable with a 47BIT
>> >> address, that naming would be more consistant with the ADDR_LIMIT_3GB
>> >> just above that means a 3 Gigabytes limit.
>> >
>> > Hence ADDR_LIMIT_128TB?
>>
>> Yes it should be 128TB. Typo by me.
>
> 47BIT was selected because the usecase for this flag is for applications
> that want to store data in the upper bits of a virtual address space. In
> this case, how large the virtual address space is irrelevant, and only
> the number of bits that are being used, and hence the number of bits
> that are free.
Yeah I understand that's how you came to the problem.
But for the user API I think using the size of the address space is
clearer, easier to explain, and matches the existing ADDR_LIMIT_3GB.
cheers
Re: [PATCH] powerpc/perf: Use guard(irqsave)() in eight functions
Markus Elfring writes:
> From: Markus Elfring
> Date: Mon, 16 Sep 2024 19:25:00 +0200
>
> Scope-based resource management became supported for some
> programming interfaces by contributions of Peter Zijlstra on 2023-05-26.
> See also the commit 54da6a0924311c7cf5015533991e44fb8eb12773 ("locking:
> Introduce __cleanup() based infrastructure").
>
> * Thus replace local_irq_save() and local_irq_restore() calls by calls
> of the macro “guard(irqsave)”.
>
> * Omit the local variables “flags” and “irq_flags”.
>
> * Replace selected usage of the label “out” by a few return statements.
>
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> arch/powerpc/perf/core-book3s.c | 102 +---
> 1 file changed, 42 insertions(+), 60 deletions(-)
These mostly look good.
I don't think the change to power_pmu_event_init() is an improvement.
I'll drop that hunk when applying, or you can send a v2 without that
change if you prefer.
cheers
> @@ -1996,7 +1980,7 @@ static bool is_event_blacklisted(u64 ev)
> static int power_pmu_event_init(struct perf_event *event)
> {
> u64 ev;
> - unsigned long flags, irq_flags;
> + unsigned long flags;
> struct perf_event *ctrs[MAX_HWEVENTS];
> u64 events[MAX_HWEVENTS];
> unsigned int cflags[MAX_HWEVENTS];
> @@ -2115,43 +2099,41 @@ static int power_pmu_event_init(struct perf_event
> *event)
> if (check_excludes(ctrs, cflags, n, 1))
> return -EINVAL;
>
> - local_irq_save(irq_flags);
> - cpuhw = this_cpu_ptr(&cpu_hw_events);
> + {
> + guard(irqsave)();
> + cpuhw = this_cpu_ptr(&cpu_hw_events);
>
> - err = power_check_constraints(cpuhw, events, cflags, n + 1, ctrs);
> + err = power_check_constraints(cpuhw, events, cflags, n + 1,
> ctrs);
>
> - if (has_branch_stack(event)) {
> - u64 bhrb_filter = -1;
> + if (has_branch_stack(event)) {
> + u64 bhrb_filter = -1;
>
> - /*
> - * Currently no PMU supports having multiple branch filters
> - * at the same time. Branch filters are set via MMCRA IFM[32:33]
> - * bits for Power8 and above. Return EOPNOTSUPP when multiple
> - * branch filters are requested in the event attr.
> - *
> - * When opening event via perf_event_open(), branch_sample_type
> - * gets adjusted in perf_copy_attr(). Kernel will automatically
> - * adjust the branch_sample_type based on the event modifier
> - * settings to include PERF_SAMPLE_BRANCH_PLM_ALL. Hence drop
> - * the check for PERF_SAMPLE_BRANCH_PLM_ALL.
> - */
> - if (hweight64(event->attr.branch_sample_type &
> ~PERF_SAMPLE_BRANCH_PLM_ALL) > 1) {
> - local_irq_restore(irq_flags);
> - return -EOPNOTSUPP;
> - }
> + /*
> + * Currently no PMU supports having multiple branch
> filters
> + * at the same time. Branch filters are set via MMCRA
> IFM[32:33]
> + * bits for Power8 and above. Return EOPNOTSUPP when
> multiple
> + * branch filters are requested in the event attr.
> + *
> + * When opening event via perf_event_open(),
> branch_sample_type
> + * gets adjusted in perf_copy_attr(). Kernel will
> automatically
> + * adjust the branch_sample_type based on the event
> modifier
> + * settings to include PERF_SAMPLE_BRANCH_PLM_ALL.
> Hence drop
> + * the check for PERF_SAMPLE_BRANCH_PLM_ALL.
> + */
> + if (hweight64(event->attr.branch_sample_type &
> ~PERF_SAMPLE_BRANCH_PLM_ALL)
> + > 1)
> + return -EOPNOTSUPP;
>
> - if (ppmu->bhrb_filter_map)
> - bhrb_filter = ppmu->bhrb_filter_map(
> - event->attr.branch_sample_type);
> + if (ppmu->bhrb_filter_map)
> + bhrb_filter =
> ppmu->bhrb_filter_map(event->attr.branch_sample_type);
>
> - if (bhrb_filter == -1) {
> - local_irq_restore(irq_flags);
> - return -EOPNOTSUPP;
> + if (bhrb_filter == -1)
> + return -EOPNOTSUPP;
> +
> + cpuhw->bhrb_filter = bhrb_filter;
> }
> - cpuhw->bhrb_filter = bhrb_filter;
> }
>
> - local_irq_restore(irq_flags);
> if (err)
> return -EINVAL;
>
> --
> 2.46.0
Re: [FSL P50x0] [GIT KERNEL] [VDSO] compiling issue
Christian Zigotzky writes: > Hi All, > > The compiling of the latest Git kernel doesn’t work anymore for our FSL > P5020/P5040 boards [1] since the random-6.12-rc1 updates [2]. > > Error messages: > > arch/powerpc/kernel/vdso/vdso32.so.dbg: dynamic relocations are not supported > > make[2]: *** [arch/powerpc/kernel/vdso/Makefile:75: > arch/powerpc/kernel/vdso/vdso32.so.dbg] > > Reverting of the vdso updates has solved the compiing issue. > > Could you please check the random-6.12-rc1 updates? [2] > > Thanks, > Christian > > [1] http://wiki.amiga.org/index.php?title=X5000 > > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a39ac5b7d62679c07a3e3d12b0f6982377d8a7d > > + Kernel config > > Link: > https://raw.githubusercontent.com/chzigotzky/kernels/refs/heads/main/configs/x5000_defconfig Your config has: # CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y But all our defconfigs use CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE. Which explains why we didn't catch this in build testing. I've added a build with OPTIMIZE_FOR_SIZE=y so hopefully we'll catch any similar errors in future. cheers
Re: [RFC PATCH] powerpc/tlb: enable arch want batched unmap tlb flush
Luming Yu writes: > On Thu, Sep 19, 2024 at 01:22:21PM +1000, Michael Ellerman wrote: >> Luming Yu writes: >> > From: Yu Luming >> > >> > ppc always do its own tracking for batch tlb. >> >> I don't think it does? :) >> >> I think you're referring to the batch handling in >> arch/powerpc/include/asm/book3s/64/tlbflush-hash.h ? >> >> But that's only used for 64-bit Book3S with the HPT MMU. >> >> > By trivially enabling >> > the ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH in ppc, ppc arch can re-use >> > common code in rmap and reduce overhead and do optimization it could not >> > have without a tlb flushing context at low architecture level. >> > >> > Signed-off-by: Luming Yu >> > --- >> > arch/powerpc/Kconfig| 1 + >> > arch/powerpc/include/asm/tlbbatch.h | 30 + >> > 2 files changed, 31 insertions(+) >> > create mode 100644 arch/powerpc/include/asm/tlbbatch.h >> >> This doesn't build: >> >> https://github.com/linuxppc/linux-snowpatch/actions/runs/10919442655 >> >> Can you please follow the instructions here: >> >> https://github.com/linuxppc/wiki/wiki/Testing-with-GitHub-Actions >> >> Which describe how to fork our CI tree that has Github Actions >> preconfigured, then you can apply your patches on top and push to github >> and it will do some test builds for you. Notably it will do 32-bit >> builds which is what broke here. > thanks, I will take a look and do this for next patch before posting on > mailing list. :-) > > Ideally it should also include qemu boot tests for targets that must work. Those scripts do qemu boots of pseries p8/p9, powernv p8/p9, 44x, e5500, g5, and mac99. It doesn't boot full distros because that's too slow for Github Actions, so it doesn't catch all bugs, but it's better than nothing. > I think we could also need a powerpc yocto recipe as well to make > patch test more customizable > and reproducible than fedora/Debian distro. I've been searching for it > for a while, but I couldn't find a useful one. Maybe I need to come up > one of my own to facilitate the ci test bot ideas. I've never used Yocto, not sure if it does/did support powerpc. Buildroot can build powerpc images with lots of packages included. cheers
Re: [PATCH] powerpc/atomic: Use YZ constraints for DS-form instructions
Segher Boessenkool writes: > Hi! > > On Mon, Sep 16, 2024 at 10:05:10PM +1000, Michael Ellerman wrote: >> The 'ld' and 'std' instructions require a 4-byte aligned displacement >> because they are DS-form instructions. But the "m" asm constraint >> doesn't enforce that. >> >> That can lead to build errors if the compiler chooses a non-aligned >> displacement, as seen with GCC 14: >> >> /tmp/ccuSzwiR.s: Assembler messages: >> /tmp/ccuSzwiR.s:2579: Error: operand out of domain (39 is not a multiple >> of 4) >> make[5]: *** [scripts/Makefile.build:229: net/core/page_pool.o] Error 1 >> >> Dumping the generated assembler shows: >> >> ld 8,39(8) # MEM[(const struct atomic64_t *)_29].counter, t >> >> Use the YZ constraints to tell the compiler either to generate a DS-form >> displacement, or use an X-form instruction, either of which prevents the >> build error. > > Great explanation text, a perfect commit! :-) Thanks - I'm sure there's something that could be better, but I do try :) cheers
Re: [PATCH] crypto: Removing CRYPTO_AES_GCM_P10.
Danny Tsen writes: > Removing CRYPTO_AES_GCM_P10 in Kconfig first so that we can apply the > subsequent patches to fix data mismatch over ipsec tunnel. This change log needs to stand on its own. ie. it needs to explain what the problem is and why the feature is being disabled, without reference to subsequent patches (which will probably be merged separately). It should also have a Fixes/stable tag. And as Christophe said, just adding a dependency on BROKEN is sufficient. cheers > diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig > index 09ebcbdfb34f..96ca2c4c8827 100644 > --- a/arch/powerpc/crypto/Kconfig > +++ b/arch/powerpc/crypto/Kconfig > @@ -105,22 +105,22 @@ config CRYPTO_AES_PPC_SPE > architecture specific assembler implementations that work on 1KB > tables or 256 bytes S-boxes. > > -config CRYPTO_AES_GCM_P10 > - tristate "Stitched AES/GCM acceleration support on P10 or later CPU > (PPC)" > - depends on PPC64 && CPU_LITTLE_ENDIAN && VSX > - select CRYPTO_LIB_AES > - select CRYPTO_ALGAPI > - select CRYPTO_AEAD > - select CRYPTO_SKCIPHER > - help > - AEAD cipher: AES cipher algorithms (FIPS-197) > - GCM (Galois/Counter Mode) authenticated encryption mode (NIST > SP800-38D) > - Architecture: powerpc64 using: > - - little-endian > - - Power10 or later features > - > - Support for cryptographic acceleration instructions on Power10 or > - later CPU. This module supports stitched acceleration for AES/GCM. > +#config CRYPTO_AES_GCM_P10 > +#tristate "Stitched AES/GCM acceleration support on P10 or later CPU > (PPC)" > +#depends on PPC64 && CPU_LITTLE_ENDIAN && VSX > +#select CRYPTO_LIB_AES > +#select CRYPTO_ALGAPI > +#select CRYPTO_AEAD > +#select CRYPTO_SKCIPHER > +#help > +# AEAD cipher: AES cipher algorithms (FIPS-197) > +# GCM (Galois/Counter Mode) authenticated encryption mode (NIST > SP800-38D) > +# Architecture: powerpc64 using: > +#- little-endian > +#- Power10 or later features > +# > +# Support for cryptographic acceleration instructions on Power10 or > +# later CPU. This module supports stitched acceleration for AES/GCM. > > config CRYPTO_CHACHA20_P10 > tristate "Ciphers: ChaCha20, XChacha20, XChacha12 (P10 or later)" > -- > 2.43.0
Re: [PATCH v2] crash, powerpc: Default to CRASH_DUMP=n on PPC_BOOK3S_32
Dave Vasilevsky writes:
> Fixes boot failures on 6.9 on PPC_BOOK3S_32 machines using
> Open Firmware. On these machines, the kernel refuses to boot
> from non-zero PHYSICAL_START, which occurs when CRASH_DUMP is on.
>
> Since most PPC_BOOK3S_32 machines boot via Open Firmware, it should
> default to off for them. Users booting via some other mechanism
> can still turn it on explicitly.
>
> Does not change the default on any other architectures for the
> time being.
>
> Signed-off-by: Dave Vasilevsky
> Reported-by: Reimar Döffinger
> Closes: https://lists.debian.org/debian-powerpc/2024/07/msg1.html
> Fixes: 75bc255a7444 ("crash: clean up kdump related config items")
> ---
> arch/arm/Kconfig | 3 +++
> arch/arm64/Kconfig | 3 +++
> arch/loongarch/Kconfig | 3 +++
> arch/mips/Kconfig | 3 +++
> arch/powerpc/Kconfig | 4
> arch/riscv/Kconfig | 3 +++
> arch/s390/Kconfig | 3 +++
> arch/sh/Kconfig| 3 +++
> arch/x86/Kconfig | 3 +++
> kernel/Kconfig.kexec | 2 +-
> 10 files changed, 29 insertions(+), 1 deletion(-)
Acked-by: Michael Ellerman (powerpc)
cheers
Re: [RFC PATCH] powerpc/tlb: enable arch want batched unmap tlb flush
Luming Yu writes: > From: Yu Luming > > ppc always do its own tracking for batch tlb. I don't think it does? :) I think you're referring to the batch handling in arch/powerpc/include/asm/book3s/64/tlbflush-hash.h ? But that's only used for 64-bit Book3S with the HPT MMU. > By trivially enabling > the ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH in ppc, ppc arch can re-use > common code in rmap and reduce overhead and do optimization it could not > have without a tlb flushing context at low architecture level. > > Signed-off-by: Luming Yu > --- > arch/powerpc/Kconfig| 1 + > arch/powerpc/include/asm/tlbbatch.h | 30 + > 2 files changed, 31 insertions(+) > create mode 100644 arch/powerpc/include/asm/tlbbatch.h This doesn't build: https://github.com/linuxppc/linux-snowpatch/actions/runs/10919442655 Can you please follow the instructions here: https://github.com/linuxppc/wiki/wiki/Testing-with-GitHub-Actions Which describe how to fork our CI tree that has Github Actions preconfigured, then you can apply your patches on top and push to github and it will do some test builds for you. Notably it will do 32-bit builds which is what broke here. cheers
[GIT PULL] Please pull powerpc/linux.git powerpc-6.12-1 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Linus, Please pull powerpc updates for 6.12. No conflicts that I'm aware of. The VDSO changes have already been merged via the random tree. cheers The following changes since commit de9c2c66ad8e787abec7c9d7eff4f8c3cdd28aed: Linux 6.11-rc2 (2024-08-04 13:50:53 -0700) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-6.12-1 for you to fetch changes up to 39190ac7cff1fd15135fa8e658030d9646fdb5f2: powerpc/atomic: Use YZ constraints for DS-form instructions (2024-09-17 22:17:57 +1000) - -- powerpc updates for 6.12 - Reduce alignment constraints on STRICT_KERNEL_RWX and speed-up TLB misses on 8xx and 603. - Replace kretprobe code with rethook and enable fprobe. - Remove the "fast endian switch" syscall. - Handle DLPAR device tree updates in kernel, allowing the deprecation of the binary /proc/powerpc/ofdt interface. Thanks to: Abhishek Dubey, Alex Shi, Benjamin Gray, Christophe Leroy, Gaosheng Cui, Gautam Menghani, Geert Uytterhoeven, Haren Myneni, Hari Bathini, Huang Xiaojia, Jinjie Ruan, Madhavan Srinivasan, Miguel Ojeda, Mina Almasry, Narayana Murty N, Naveen Rao, Rob Herring (Arm), Scott Cheloha, Segher Boessenkool, Stephen Rothwell, Thomas Zimmermann, Uwe Kleine-König, Vaibhav Jain, Zhang Zekun. - -- Abhishek Dubey (1): powerpc: Replace kretprobe code with rethook on powerpc Alex Shi (1): KVM: PPC: Book3S HV: remove unused varible Benjamin Gray (5): powerpc/code-patching: Add generic memory patching powerpc/code-patching: Add data patch alignment check powerpc/64: Convert patch_instruction() to patch_u32() powerpc/32: Convert patch_instruction() to patch_uint() powerpc/code-patching: Add boot selftest for data patching Christophe Leroy (17): powerpc: Remove unused LHZX_BE macro powerpc/8xx: Fix initial memory mapping powerpc/8xx: Fix kernel vs user address comparison powerpc/8xx: Copy kernel PGD entries into all PGDIRs Revert "powerpc/8xx: Always pin kernel text TLB" powerpc/8xx: Allow setting DATA alignment even with STRICT_KERNEL_RWX powerpc/8xx: Reduce default size of module/execmem area powerpc/8xx: Preallocate execmem page tables powerpc/8xx: Inconditionally use task PGDIR in ITLB misses powerpc/8xx: Inconditionally use task PGDIR in DTLB misses powerpc/32s: Reduce default size of module/execmem area powerpc/603: Copy kernel PGD entries into all PGDIRs and preallocate execmem page tables powerpc/603: Switch r0 and r3 in TLB miss handlers powerpc/603: Inconditionally use task PGDIR in ITLB misses powerpc/603: Inconditionally use task PGDIR in DTLB misses powerpc/32: Implement validation of emergency stack powerpc/vdso: Inconditionally use CFUNC macro Gaosheng Cui (5): powerpc: Remove obsoleted declaration for _get_SP powerpc/maple: Remove obsoleted declaration for maple_calibrate_decr() powerpc/pasemi: Remove obsoleted declaration for pas_pci_irq_fixup() powerpc: Remove obsoleted declarations for use_cop and drop_cop powerpc/powernv/pci: Remove obsoleted declaration for pnv_pci_init_ioda_hub Gautam Menghani (1): KVM: PPC: Book3S HV: Refactor HFSCR emulation for KVM guests Haren Myneni (3): powerpc/pseries: Use correct data types from pseries_hp_errorlog struct powerpc/pseries/dlpar: Remove device tree node for DLPAR IO remove powerpc/pseries/dlpar: Add device tree nodes for DLPAR IO add Huang Xiaojia (3): powerpc: Constify struct kobj_type powerpc: powernv: Constify struct kobj_type powerpc: pseries: Constify struct kobj_type Jinjie Ruan (1): powerpc: Remove useless config comment in asm/percpu.h Madhavan Srinivasan (2): powerpc/xmon: Fix tmpstr length check in scanhex selftests/powerpc: Allow building without static libc Michael Ellerman (13): MAINTAINERS: Mark powerpc Cell as orphaned MAINTAINERS: Mark powerpc spufs as orphaned powerpc/configs/64s: Enable DEFERRED_STRUCT_PAGE_INIT powerpc/64s/mm: Move __real_pte stubs into hash-4k.h powerpc/64s: Make mmu_hash_ops __ro_after_init powerpc/mm/64s: Move THP reqs into a separate symbol powerpc/mm/64s: Restrict THP to Radix or HPT w/64K pages powerpc/64s: Remove the "fast endian switch" syscall powerpc: Stop using no_llseek macintosh/via-pmu: register_pmu_pm_ops() can be __init Merge branch 'topic/ppc-kvm' into next MAINTAINERS: powerpc: Add Maddy powerpc/atomic: Use YZ constraints for DS-form instructions Narayana Murty N (1): powerpc/pseries/eeh: Fix pseries_eeh_err_inject Rob Herring (Arm) (1):
Re: [RFC PATCH] powerpc/vdso: Should VDSO64 functions be flagged as functions like VDSO32 ?
Christophe Leroy writes:
> On powerpc64 as shown below by readelf, vDSO functions symbols have
> type NOTYPE.
>
> $ powerpc64-linux-gnu-readelf -a arch/powerpc/kernel/vdso/vdso64.so.dbg
> ELF Header:
> Magic: 7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00
> Class: ELF64
> Data: 2's complement, big endian
> Version: 1 (current)
> OS/ABI:UNIX - System V
> ABI Version: 0
> Type: DYN (Shared object file)
> Machine: PowerPC64
> Version: 0x1
> ...
>
> Symbol table '.dynsym' contains 12 entries:
>Num:Value Size TypeBind Vis Ndx Name
> ...
> 1: 052484 NOTYPE GLOBAL DEFAULT8
> __[...]@@LINUX_2.6.15
> ...
> 4: 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6.15
> 5: 06c048 NOTYPE GLOBAL DEFAULT8
> __[...]@@LINUX_2.6.15
>
> Symbol table '.symtab' contains 56 entries:
>Num:Value Size TypeBind Vis Ndx Name
> ...
> 45: 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6.15
> 46: 06c048 NOTYPE GLOBAL DEFAULT8 __kernel_getcpu
> 47: 052484 NOTYPE GLOBAL DEFAULT8
> __kernel_clock_getres
>
> To overcome that, commit ba83b3239e65 ("selftests: vDSO: fix vDSO
> symbols lookup for powerpc64") was proposed to make selftests also
> look for NOTYPE symbols, but is it the correct fix ?
>
> VDSO32 functions are flagged as functions, why not VDSO64 functions ?
> Is it because VDSO functions are not traditional C functions using
> the standard API ?
Yes. There's some explanation in the original commit:
Note that the symbols exposed by the vDSO aren't "normal" function symbols,
apps
can't be expected to link against them directly, the vDSO's are both seen
as if they were linked at 0 and the symbols just contain offsets to the
various functions. This is done on purpose to avoid a relocation step
(ppc64 functions normally have descriptors with abs addresses in them).
When glibc uses those functions, it's expected to use it's own trampolines
that know how to reach them.
>From
>https://github.com/mpe/linux-fullhistory/commit/5f2dd691b62da9d9cc54b938f8b29c22c93cb805
The descriptors it's talking about are the OPD function descriptors used
on ABI v1 (big endian).
> But it is exactly the same for VDSO32 functions, allthough they are
> flagged as functions.
It's not quite the same because of the function descriptors.
On ppc64/ABIv1 a function pointer for "F" points to an opd, which then
points to ".F" which has the actual text. It's the ".F" symbol that has
type "function".
> So lets flag them as functions and revert the selftest change.
>
> What's your opinion on that ?
I think it's fine on ppc64le, I worry slightly that it risks breaking
glibc or something else on big endian.
It is more correct for the text symbol to have type function, even if
there's no function descriptor for it.
glibc has a special case already for handling the VDSO symbols which
creates a fake opd pointing at the kernel symbol. So changing the VDSO
symbol type to function shouldn't affect that AFAICS.
I think the only cause of breakage would be if something is explicitly
looking for NOTYPE symbols, which seems unlikely, but you never know.
So I think we could attempt to take this change for v6.13, giving it
lots of time to get some test coverage in next before going to mainline.
cheers
> It predates git kernel history and both VDSO32 and VDSO64 were brough by
> arch/ppc64/ with that difference already.
>
> Signed-off-by: Christophe Leroy
> ---
> commit ba83b3239e65 is in random git tree at the moment :
> https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/commit/?id=ba83b3239e657469709d15dcea5f9b65bf9dbf34
> On the list at :
> https://lore.kernel.org/lkml/fc1a0862516b1e11b336d409f2cb8aab10a97337.1725020674.git.christophe.le...@csgroup.eu/T/#u
> ---
> arch/powerpc/include/asm/vdso.h | 1 +
> tools/testing/selftests/vDSO/parse_vdso.c | 3 +--
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/vdso.h b/arch/powerpc/include/asm/vdso.h
> index 7650b6ce14c8..8d972bc98b55 100644
> --- a/arch/powerpc/include/asm/vdso.h
> +++ b/arch/powerpc/include/asm/vdso.h
> @@ -25,6 +25,7 @@ int vdso_getcpu_init(void);
> #ifdef __VDSO64__
> #define V_FUNCTION_BEGIN(name) \
> .globl name;\
> + .type name,@function; \
> name: \
>
> #define V_FUNCTION_END(name) \
> diff --git a/tools/testing/selftests/vDSO/parse_vdso.c
> b/tools/testing/selftests/vDSO/parse_vdso.c
> index d9ccc5acac18..4ae417372e9e 100644
> --- a/tools/testing/selftests/vDSO/parse_vdso.c
> +++ b/to
Re: [PATCH] powerpc/atomic: Use YZ constraints for DS-form instructions
On Mon, 16 Sep 2024 22:05:10 +1000, Michael Ellerman wrote: > The 'ld' and 'std' instructions require a 4-byte aligned displacement > because they are DS-form instructions. But the "m" asm constraint > doesn't enforce that. > > That can lead to build errors if the compiler chooses a non-aligned > displacement, as seen with GCC 14: > > [...] Applied to powerpc/next. [1/1] powerpc/atomic: Use YZ constraints for DS-form instructions https://git.kernel.org/powerpc/c/39190ac7cff1fd15135fa8e658030d9646fdb5f2 cheers
Re: [PATCH] MAINTAINERS: powerpc: Add Maddy
On Tue, 27 Aug 2024 16:36:51 +1000, Michael Ellerman wrote: > Maddy will be helping out with upstream maintenance, add him as a > reviewer. > > Applied to powerpc/next. [1/1] MAINTAINERS: powerpc: Add Maddy https://git.kernel.org/powerpc/c/b77d36bb9a3de774950ba712a0e47f9d33c6f6d7 cheers
Re: [PATCH] powerpc/atomic: Use YZ constraints for DS-form instructions
Mina Almasry writes:
> On Mon, Sep 16, 2024 at 5:05 AM Michael Ellerman wrote:
>>
>> The 'ld' and 'std' instructions require a 4-byte aligned displacement
>> because they are DS-form instructions. But the "m" asm constraint
>> doesn't enforce that.
>>
>> That can lead to build errors if the compiler chooses a non-aligned
>> displacement, as seen with GCC 14:
>>
>> /tmp/ccuSzwiR.s: Assembler messages:
>> /tmp/ccuSzwiR.s:2579: Error: operand out of domain (39 is not a multiple
>> of 4)
>> make[5]: *** [scripts/Makefile.build:229: net/core/page_pool.o] Error 1
>>
>> Dumping the generated assembler shows:
>>
>> ld 8,39(8) # MEM[(const struct atomic64_t *)_29].counter, t
>>
>> Use the YZ constraints to tell the compiler either to generate a DS-form
>> displacement, or use an X-form instruction, either of which prevents the
>> build error.
>>
>> See commit 2d43cc701b96 ("powerpc/uaccess: Fix build errors seen with
>> GCC 13/14") for more details on the constraint letters.
>>
>> Fixes: 9f0cbea0d8cc ("[POWERPC] Implement atomic{, 64}_{read, write}()
>> without volatile")
>> Cc: sta...@vger.kernel.org # v2.6.24+
>> Reported-by: Stephen Rothwell
>> Closes: https://lore.kernel.org/all/20240913125302.0a06b...@canb.auug.org.au
>> Signed-off-by: Michael Ellerman
>
> I'm not familiar enough with the code around the changes, but I have
> been able to confirm cherry-picking this resolves the build issue I'm
> seeing on net-next, so, FWIW,
>
> Tested-by: Mina Almasry
Thanks.
cheers
[PATCH] powerpc/atomic: Use YZ constraints for DS-form instructions
The 'ld' and 'std' instructions require a 4-byte aligned displacement
because they are DS-form instructions. But the "m" asm constraint
doesn't enforce that.
That can lead to build errors if the compiler chooses a non-aligned
displacement, as seen with GCC 14:
/tmp/ccuSzwiR.s: Assembler messages:
/tmp/ccuSzwiR.s:2579: Error: operand out of domain (39 is not a multiple of 4)
make[5]: *** [scripts/Makefile.build:229: net/core/page_pool.o] Error 1
Dumping the generated assembler shows:
ld 8,39(8) # MEM[(const struct atomic64_t *)_29].counter, t
Use the YZ constraints to tell the compiler either to generate a DS-form
displacement, or use an X-form instruction, either of which prevents the
build error.
See commit 2d43cc701b96 ("powerpc/uaccess: Fix build errors seen with
GCC 13/14") for more details on the constraint letters.
Fixes: 9f0cbea0d8cc ("[POWERPC] Implement atomic{, 64}_{read, write}() without
volatile")
Cc: sta...@vger.kernel.org # v2.6.24+
Reported-by: Stephen Rothwell
Closes: https://lore.kernel.org/all/20240913125302.0a06b...@canb.auug.org.au
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/asm-compat.h | 6 ++
arch/powerpc/include/asm/atomic.h | 5 +++--
arch/powerpc/include/asm/uaccess.h| 7 +--
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/asm-compat.h
b/arch/powerpc/include/asm/asm-compat.h
index 2bc53c646ccd..83848b534cb1 100644
--- a/arch/powerpc/include/asm/asm-compat.h
+++ b/arch/powerpc/include/asm/asm-compat.h
@@ -39,6 +39,12 @@
#define STDX_BEstringify_in_c(stdbrx)
#endif
+#ifdef CONFIG_CC_IS_CLANG
+#define DS_FORM_CONSTRAINT "Z<>"
+#else
+#define DS_FORM_CONSTRAINT "YZ<>"
+#endif
+
#else /* 32-bit */
/* operations for longs and pointers */
diff --git a/arch/powerpc/include/asm/atomic.h
b/arch/powerpc/include/asm/atomic.h
index 5bf6a4d49268..d1ea554c33ed 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
/*
* Since *_return_relaxed and {cmp}xchg_relaxed are implemented with
@@ -197,7 +198,7 @@ static __inline__ s64 arch_atomic64_read(const atomic64_t
*v)
if (IS_ENABLED(CONFIG_PPC_KERNEL_PREFIXED))
__asm__ __volatile__("ld %0,0(%1)" : "=r"(t) :
"b"(&v->counter));
else
- __asm__ __volatile__("ld%U1%X1 %0,%1" : "=r"(t) :
"m<>"(v->counter));
+ __asm__ __volatile__("ld%U1%X1 %0,%1" : "=r"(t) :
DS_FORM_CONSTRAINT (v->counter));
return t;
}
@@ -208,7 +209,7 @@ static __inline__ void arch_atomic64_set(atomic64_t *v, s64
i)
if (IS_ENABLED(CONFIG_PPC_KERNEL_PREFIXED))
__asm__ __volatile__("std %1,0(%2)" : "=m"(v->counter) :
"r"(i), "b"(&v->counter));
else
- __asm__ __volatile__("std%U0%X0 %1,%0" : "=m<>"(v->counter) :
"r"(i));
+ __asm__ __volatile__("std%U0%X0 %1,%0" : "=" DS_FORM_CONSTRAINT
(v->counter) : "r"(i));
}
#define ATOMIC64_OP(op, asm_op)
\
diff --git a/arch/powerpc/include/asm/uaccess.h
b/arch/powerpc/include/asm/uaccess.h
index fd594bf6c6a9..4f5a46a77fa2 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#ifdef __powerpc64__
/* We use TASK_SIZE_USER64 as TASK_SIZE is not constant */
@@ -92,12 +93,6 @@ __pu_failed:
\
: label)
#endif
-#ifdef CONFIG_CC_IS_CLANG
-#define DS_FORM_CONSTRAINT "Z<>"
-#else
-#define DS_FORM_CONSTRAINT "YZ<>"
-#endif
-
#ifdef __powerpc64__
#ifdef CONFIG_PPC_KERNEL_PREFIXED
#define __put_user_asm2_goto(x, ptr, label)\
--
2.46.0
Re: [PATCH net-next v2] page_pool: fix build on powerpc with GCC 14
Christophe Leroy writes:
> Le 14/09/2024 à 04:02, Michael Ellerman a écrit :
...
>>
>> diff --git a/arch/powerpc/include/asm/atomic.h
>> b/arch/powerpc/include/asm/atomic.h
>> index 5bf6a4d49268..0e41c1da82dd 100644
>> --- a/arch/powerpc/include/asm/atomic.h
>> +++ b/arch/powerpc/include/asm/atomic.h
>> @@ -23,6 +23,12 @@
>> #define __atomic_release_fence() \
>> __asm__ __volatile__(PPC_RELEASE_BARRIER "" : : : "memory")
>>
>> +#ifdef CONFIG_CC_IS_CLANG
>> +#define DS_FORM_CONSTRAINT "Z<>"
>> +#else
>> +#define DS_FORM_CONSTRAINT "YZ<>"
>> +#endif
>
> I see we have the same in uaccess.h, added by commit 2d43cc701b96
> ("powerpc/uaccess: Fix build errors seen with GCC 13/14")
Yep.
> Should that go in a common header, maybe ppc_asm.h ?
That would be the obvious place, but unfortunately including ppc_asm.h
in atomic.h breaks the build due to header spaghetti.
For now I've put the defines in asm-compat.h, which is not ideal but
seems to work.
cheers
Re: [PATCH net-next v2] page_pool: fix build on powerpc with GCC 14
Mina Almasry writes:
> Building net-next with powerpc with GCC 14 compiler results in this
> build error:
>
> /home/sfr/next/tmp/ccuSzwiR.s: Assembler messages:
> /home/sfr/next/tmp/ccuSzwiR.s:2579: Error: operand out of domain (39 is
> not a multiple of 4)
> make[5]: *** [/home/sfr/next/next/scripts/Makefile.build:229:
> net/core/page_pool.o] Error 1
>
> Root caused in this thread:
> https://lore.kernel.org/netdev/913e2fbd-d318-4c9b-aed2-4d333a1d5...@cs-soprasteria.com/
Sorry I'm late to this, the original report wasn't Cc'ed to linuxppc-dev :D
I think this is a bug in the arch/powerpc inline asm constraints.
Can you try the patch below, it fixes the build error for me.
I'll run it through some boot tests and turn it into a proper patch over
the weekend.
cheers
diff --git a/arch/powerpc/include/asm/atomic.h
b/arch/powerpc/include/asm/atomic.h
index 5bf6a4d49268..0e41c1da82dd 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -23,6 +23,12 @@
#define __atomic_release_fence() \
__asm__ __volatile__(PPC_RELEASE_BARRIER "" : : : "memory")
+#ifdef CONFIG_CC_IS_CLANG
+#define DS_FORM_CONSTRAINT "Z<>"
+#else
+#define DS_FORM_CONSTRAINT "YZ<>"
+#endif
+
static __inline__ int arch_atomic_read(const atomic_t *v)
{
int t;
@@ -197,7 +203,7 @@ static __inline__ s64 arch_atomic64_read(const atomic64_t
*v)
if (IS_ENABLED(CONFIG_PPC_KERNEL_PREFIXED))
__asm__ __volatile__("ld %0,0(%1)" : "=r"(t) :
"b"(&v->counter));
else
- __asm__ __volatile__("ld%U1%X1 %0,%1" : "=r"(t) :
"m<>"(v->counter));
+ __asm__ __volatile__("ld%U1%X1 %0,%1" : "=r"(t) :
DS_FORM_CONSTRAINT (v->counter));
return t;
}
@@ -208,7 +214,7 @@ static __inline__ void arch_atomic64_set(atomic64_t *v, s64
i)
if (IS_ENABLED(CONFIG_PPC_KERNEL_PREFIXED))
__asm__ __volatile__("std %1,0(%2)" : "=m"(v->counter) :
"r"(i), "b"(&v->counter));
else
- __asm__ __volatile__("std%U0%X0 %1,%0" : "=m<>"(v->counter) :
"r"(i));
+ __asm__ __volatile__("std%U0%X0 %1,%0" : "=" DS_FORM_CONSTRAINT
(v->counter) : "r"(i));
}
#define ATOMIC64_OP(op, asm_op)
\
Re: [PATCH] of: address: Unify resource bounds overflow checking
Rob Herring writes:
> On Fri, Sep 13, 2024 at 8:15 AM Michael Ellerman wrote:
>> Thomas Weißschuh writes:
>> > The members "start" and "end" of struct resource are of type
>> > "resource_size_t" which can be 32bit wide.
>> > Values read from OF however are always 64bit wide.
>> >
>> > Refactor the diff overflow checks into a helper function.
>> > Also extend the checks to validate each calculation step.
>> >
>> > Signed-off-by: Thomas Weißschuh
>> > ---
>> > drivers/of/address.c | 45 ++---
>> > 1 file changed, 26 insertions(+), 19 deletions(-)
>> >
>> > diff --git a/drivers/of/address.c b/drivers/of/address.c
>> > index 7e59283a4472..df854bb427ce 100644
>> > --- a/drivers/of/address.c
>> > +++ b/drivers/of/address.c
>> > @@ -198,6 +198,25 @@ static u64 of_bus_pci_map(__be32 *addr, const __be32
>> > *range, int na, int ns,
>> >
>> > #endif /* CONFIG_PCI */
>> >
>> > +static int __of_address_resource_bounds(struct resource *r, u64 start,
>> > u64 size)
>> > +{
>> > + u64 end = start;
>> > +
>> > + if (overflows_type(start, r->start))
>> > + return -EOVERFLOW;
>> > + if (size == 0)
>> > + return -EOVERFLOW;
>> > + if (check_add_overflow(end, size - 1, &end))
>> > + return -EOVERFLOW;
>> > + if (overflows_type(end, r->end))
>> > + return -EOVERFLOW;
>>
>> This breaks PCI on powerpc qemu. Part of the PCI probe reads a resource
>> that's zero sized, which used to succeed but now fails due to the size
>> check above.
>>
>> The diff below fixes it for me.
>
> I fixed it up with your change.
Thanks.
cheers
Re: [PATCH] of: address: Unify resource bounds overflow checking
Thomas Weißschuh writes:
> The members "start" and "end" of struct resource are of type
> "resource_size_t" which can be 32bit wide.
> Values read from OF however are always 64bit wide.
>
> Refactor the diff overflow checks into a helper function.
> Also extend the checks to validate each calculation step.
>
> Signed-off-by: Thomas Weißschuh
> ---
> drivers/of/address.c | 45 ++---
> 1 file changed, 26 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 7e59283a4472..df854bb427ce 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -198,6 +198,25 @@ static u64 of_bus_pci_map(__be32 *addr, const __be32
> *range, int na, int ns,
>
> #endif /* CONFIG_PCI */
>
> +static int __of_address_resource_bounds(struct resource *r, u64 start, u64
> size)
> +{
> + u64 end = start;
> +
> + if (overflows_type(start, r->start))
> + return -EOVERFLOW;
> + if (size == 0)
> + return -EOVERFLOW;
> + if (check_add_overflow(end, size - 1, &end))
> + return -EOVERFLOW;
> + if (overflows_type(end, r->end))
> + return -EOVERFLOW;
This breaks PCI on powerpc qemu. Part of the PCI probe reads a resource
that's zero sized, which used to succeed but now fails due to the size
check above.
The diff below fixes it for me.
It leaves r.end == r.start, which is fine in my case, because the code
only uses r.start.
And it seems more sane than the old code which would return
end = start - 1, for zero sized resources.
cheers
diff --git a/drivers/of/address.c b/drivers/of/address.c
index df854bb427ce..a001e789a6c4 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -204,9 +204,7 @@ static int __of_address_resource_bounds(struct resource *r,
u64 start, u64 size)
if (overflows_type(start, r->start))
return -EOVERFLOW;
- if (size == 0)
- return -EOVERFLOW;
- if (check_add_overflow(end, size - 1, &end))
+ if (size > 0 && check_add_overflow(end, size - 1, &end))
return -EOVERFLOW;
if (overflows_type(end, r->end))
return -EOVERFLOW;
Re: [PATCH 1/1] crypto: Fix data mismatch over ipsec tunnel encrypted/decrypted with ppc64le AES/GCM module.
Danny Tsen writes: > This patch is to fix an issue when simd is not usable that data mismatch > may occur over ipsec tunnel. The fix is to register algs as SIMD modules > so that the algorithm is excecuted when SIMD instructions is usable. > > A new module rfc4106(gcm(aes)) is also added. Re-write AES/GCM assembly > codes with smaller footprints and small performance gain. > > This patch has been tested with the kernel crypto module tcrypt.ko and > has passed the selftest. The patch is also tested with > CONFIG_CRYPTO_MANAGER_EXTRA_TESTS enabled. > > Signed-off-by: Danny Tsen > --- > arch/powerpc/crypto/Kconfig|1 + > arch/powerpc/crypto/aes-gcm-p10-glue.c | 141 +- > arch/powerpc/crypto/aes-gcm-p10.S | 2421 +++- > 3 files changed, 1187 insertions(+), 1376 deletions(-) As this is a bug fix it should have a Fixes: tag, and probably a stable Cc as well. But that diffstat is really large for a bug fix. Is there no way to fix the issue in a smaller patch? Even if that is just disabling the feature until it can be fixed in subsequent commits? cheers
Re: [PATCH] powerpc: Switch back to struct platform_driver::remove()
On Mon, 09 Sep 2024 15:09:02 +0200, Uwe Kleine-König wrote:
> After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
> return void") .remove() is (again) the right callback to implement for
> platform drivers.
>
> Convert all pwm drivers to use .remove(), with the eventual goal to drop
> struct platform_driver::remove_new(). As .remove() and .remove_new() have
> the same prototypes, conversion is done by just changing the structure
> member name in the driver initializer.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Switch back to struct platform_driver::remove()
https://git.kernel.org/powerpc/c/01d34cc93639172272c3e47edd5cf1a3ffc6dc7a
cheers
Re: [PATCH v3] powerpc/pseries/eeh: Fix pseries_eeh_err_inject
On Mon, 09 Sep 2024 09:02:20 -0500, Narayana Murty N wrote: > VFIO_EEH_PE_INJECT_ERR ioctl is currently failing on pseries > due to missing implementation of err_inject eeh_ops for pseries. > This patch implements pseries_eeh_err_inject in eeh_ops/pseries > eeh_ops. Implements support for injecting MMIO load/store error > for testing from user space. > > The check on PCI error type (bus type) code is moved to platform > code, since the eeh_pe_inject_err can be allowed to more error > types depending on platform requirement. Removal of the check for > 'type' in eeh_pe_inject_err() doesn't impact PowerNV as > pnv_eeh_err_inject() already has an equivalent check in place. > > [...] Applied to powerpc/next. [1/1] powerpc/pseries/eeh: Fix pseries_eeh_err_inject https://git.kernel.org/powerpc/c/b0e2b828dfca645a228f8c89d12fbc2baecfb7ea cheers
Re: [PATCH v2] selftest/powerpc/benchmark: remove requirement libc-dev
On Mon, 12 Aug 2024 15:11:52 +0530, Madhavan Srinivasan wrote: > Currently exec-target.c file is linked as static and this > post a requirement to install libc dev package to build. > Without it, build-break when compiling selftest/powerpc/benchmark. > > CC exec_target > /usr/bin/ld: cannot find -lc: No such file or directory > collect2: error: ld returned 1 exit status > > [...] Applied to powerpc/next. [1/1] selftest/powerpc/benchmark: remove requirement libc-dev https://git.kernel.org/powerpc/c/8c9c01ce695eea84d19482e7429e3d54ceb7585c cheers
Re: [PowerPC][linux-next-6.11-rc7-20240910] Kernel Warnings at kernel/jump_label.c:266
Venkat Rao Bagalkote writes:
> Greetings!!!
>
> I am observing kernel warnings while booting with
> linux-next-6.11-rc7-20240910 kernel. Below are the warnings.
>
> [ 63.613506] WARNING: CPU: 20 PID: 214 at kernel/jump_label.c:266
> static_key_dec+0x78/0x8c
> [ 63.613518] Modules linked in: ext4 mbcache jbd2 dm_service_time sd_mod sg
> ibmvfc mlx5_core ibmvnic scsi_transport_fc ibmveth mlxfw psample dm_multipath
> dm_mirror dm_region_hash dm_log dm_mod fuse
> [ 63.613542] CPU: 20 UID: 0 PID: 214 Comm: kworker/20:1 Not tainted
> 6.11.0-rc7-next-20240910-auto #1
> [ 63.613549] Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200
> 0xf06 of:IBM,FW1060.00 (NH1060_016) hv:phyp pSeries
> [ 63.613556] Workqueue: cgroup_destroy css_free_rwork_fn
> [ 63.613563] NIP: c048ca20 LR: c048d060 CTR:
> c05cb330
> [ 63.613568] REGS: c0005a1afa80 TRAP: 0700 Not tainted
> (6.11.0-rc7-next-20240910-auto)
> [ 63.613573] MSR: 8282b033 CR:
> 24000884 XER: 20040001
> [ 63.613586] CFAR: c048c9cc IRQMASK: 0
> [ 63.613586] GPR00: c048d060 c0005a1afd20 c15f4300
> c2faa440
> [ 63.613586] GPR04: 0001 009e c84bae00
> 009d
> [ 63.613586] GPR08:
> c0005b852780
> [ 63.613586] GPR12: c05cb330 c00c7db7df00 c01a779c
> c84b27c0
> [ 63.613586] GPR16:
>
> [ 63.613586] GPR20: c00c7b914300 c2de73c8 c27b07a8
> fef7
> [ 63.613586] GPR24: 0402 c0005b852780 c8eabc05
> 0010
> [ 63.613586] GPR28: c2d2fac0 ce9d6000 c00070444000
> c2faa440
> [ 63.613633] NIP [c048ca20] static_key_dec+0x78/0x8c
> [ 63.613639] LR [c048d060]
> __static_key_slow_dec_cpuslocked+0x38/0xb4
> [ 63.613645] Call Trace:
> [ 63.613647] [c0005a1afd20] [c0005a1afd50] 0xc0005a1afd50
> (unreliable)
> [ 63.613653] [c0005a1afd50] [c048d124]
> static_key_slow_dec+0x48/0xb0
> [ 63.613660] [c0005a1afdc0] [c05cb40c]
> mem_cgroup_css_free+0xdc/0x104
> [ 63.613667] [c0005a1afdf0] [c02c4d58]
> css_free_rwork_fn+0x70/0x394
> [ 63.613673] [c0005a1afe40] [c019a7dc]
> process_one_work+0x1fc/0x4dc
> [ 63.613680] [c0005a1afef0] [c019b73c] worker_thread+0x340/0x504
> [ 63.613686] [c0005a1aff90] [c01a78cc] kthread+0x138/0x140
> [ 63.613691] [c0005a1affe0] [c000df98]
> start_kernel_thread+0x14/0x18
> [ 63.613697] Code: 7c0004ac 7c074800 40820018 3861 5463063e 4e800020
> 6000 6000 7ce93b78 4ba4 6000 6000 <0fe0> 3861
> 7c60189e 5463063e
> [ 63.613711] ---[ end trace ]---
>
> Issue is introduced by the commit: de752774f38bb766941ed1bf910ba5a9f6cc6bf7
Which was:
de752774f38b ("jump_label: Fix static_key_slow_dec() yet again")
And was already reported:
https://lore.kernel.org/all/202409082005.393050e2-oliver.s...@intel.com/
https://lore.kernel.org/all/2024091011.2591-1-spassw...@web.de
In today's linux-next (20240911) it has become:
1d7f856c2ca4 ("jump_label: Fix static_key_slow_dec() yet again")
Can you test if the bug is fixed in today's linux-next?
cheers
Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits
"Arnd Bergmann" writes: > On Mon, Sep 9, 2024, at 23:22, Charlie Jenkins wrote: >> On Fri, Sep 06, 2024 at 10:52:34AM +0100, Lorenzo Stoakes wrote: >>> On Fri, Sep 06, 2024 at 09:14:08AM GMT, Arnd Bergmann wrote: >>> The intent is to optionally be able to run a process that keeps higher bits >>> free for tagging and to be sure no memory mapping in the process will >>> clobber these (correct me if I'm wrong Charlie! :) ... > Let's see what the other architectures do and then come up with > a way that fixes the pointer tagging case first on those that are > broken. We can see if there needs to be an extra flag after that. > Here is what I found: > > - x86_64 uses DEFAULT_MAP_WINDOW of BIT(47), uses a 57 bit > address space when an addr hint is passed. > - arm64 uses DEFAULT_MAP_WINDOW of BIT(47) or BIT(48), returns > higher 52-bit addresses when either a hint is passed or > CONFIG_EXPERT and CONFIG_ARM64_FORCE_52BIT is set (this > is a debugging option) > - ppc64 uses a DEFAULT_MAP_WINDOW of BIT(47) or BIT(48), > returns 52 bit address when an addr hint is passed It's 46 or 47 depending on PAGE_SIZE (4K or 64K): $ git grep "define DEFAULT_MAP_WINDOW_USER64" arch/powerpc/include/asm/task_size_64.h arch/powerpc/include/asm/task_size_64.h:#define DEFAULT_MAP_WINDOW_USER64 TASK_SIZE_128TB arch/powerpc/include/asm/task_size_64.h:#define DEFAULT_MAP_WINDOW_USER64 TASK_SIZE_64TB cheers
Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits
Geert Uytterhoeven writes:
> Hi Christophe,
>
> On Tue, Sep 10, 2024 at 11:21 AM Christophe Leroy
> wrote:
>> >>> diff --git a/include/uapi/linux/personality.h
>> >>> b/include/uapi/linux/personality.h
>> >>> index 49796b7756af..cd3b8c154d9b 100644
>> >>> --- a/include/uapi/linux/personality.h
>> >>> +++ b/include/uapi/linux/personality.h
>> >>> @@ -22,6 +22,7 @@ enum {
>> >>> WHOLE_SECONDS = 0x200,
>> >>> STICKY_TIMEOUTS = 0x400,
>> >>> ADDR_LIMIT_3GB =0x800,
>> >>> + ADDR_LIMIT_47BIT = 0x1000,
>> >>> };
>> >>
>> >> I wonder if ADDR_LIMIT_128T would be clearer?
>> >>
>> >
>> > I don't follow, what does 128T represent?
>>
>> 128T is 128 Terabytes, that's the maximum size achievable with a 47BIT
>> address, that naming would be more consistant with the ADDR_LIMIT_3GB
>> just above that means a 3 Gigabytes limit.
>
> Hence ADDR_LIMIT_128TB?
Yes it should be 128TB. Typo by me.
cheers
Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits
Charlie Jenkins writes:
> On Fri, Sep 06, 2024 at 04:59:40PM +1000, Michael Ellerman wrote:
>> Charlie Jenkins writes:
>> > Create a personality flag ADDR_LIMIT_47BIT to support applications
>> > that wish to transition from running in environments that support at
>> > most 47-bit VAs to environments that support larger VAs. This
>> > personality can be set to cause all allocations to be below the 47-bit
>> > boundary. Using MAP_FIXED with mmap() will bypass this restriction.
>> >
>> > Signed-off-by: Charlie Jenkins
>> > ---
>> > include/uapi/linux/personality.h | 1 +
>> > mm/mmap.c| 3 +++
>> > 2 files changed, 4 insertions(+)
>> >
>> > diff --git a/include/uapi/linux/personality.h
>> > b/include/uapi/linux/personality.h
>> > index 49796b7756af..cd3b8c154d9b 100644
>> > --- a/include/uapi/linux/personality.h
>> > +++ b/include/uapi/linux/personality.h
>> > @@ -22,6 +22,7 @@ enum {
>> >WHOLE_SECONDS = 0x200,
>> >STICKY_TIMEOUTS = 0x400,
>> >ADDR_LIMIT_3GB =0x800,
>> > + ADDR_LIMIT_47BIT = 0x1000,
>> > };
>>
>> I wonder if ADDR_LIMIT_128T would be clearer?
>>
>
> I don't follow, what does 128T represent?
Sorry, as Christophe explained it's 128 Terabytes, which is the actual
value of the address limit.
I think expressing it as the address value is probably more widely
understood, and would also match ADDR_LIMIT_3GB.
>> Have you looked at writing an update for the personality(2) man page? :)
>
> I will write an update to the man page if this patch is approved!
Yeah fair enough.
My (poorly expressed) point was that trying to describe the flag for the
man page might highlight that using the 47BIT name requires more
explanation.
cheers
Re: [PATCH v2] powerpc/pseries/eeh: Fix pseries_eeh_err_inject
Narayana Murty N writes:
> On 05/09/24 6:33 PM, Michael Ellerman wrote:
>> Narayana Murty N writes:
>>> VFIO_EEH_PE_INJECT_ERR ioctl is currently failing on pseries
>>> due to missing implementation of err_inject eeh_ops for pseries.
>>> This patch implements pseries_eeh_err_inject in eeh_ops/pseries
>>> eeh_ops. Implements support for injecting MMIO load/store error
>>> for testing from user space.
>>>
>>> The check on PCI error type code is moved to platform code, since
>>> the eeh_pe_inject_err can be allowed to more error types depending
>>> on platform requirement.
>>>
>>> Signed-off-by: Narayana Murty N
>>> ---
>>>
>>> Testing:
>>>
>>> vfio-test [1] by Alex Willamson, was forked and updated to add
>>> support inject error on pSeries guest and used to test this
>>> patch[2].
>>>
>>> References:
>>> ===
>>> [1] https://github.com/awilliam/tests
>>> [2] https://github.com/nnmwebmin/vfio-ppc-tests/tree/vfio-ppc-ex
>>>
>>>
>>> Changelog:
>>> V1:https://lore.kernel.org/all/20240822082713.529982-1-nnmli...@linux.ibm.com/
>>> - Resolved build issues for ppc64|le_defconfig by moving the
>>> pseries_eeh_err_inject() definition outside of the CONFIG_PCI_IOV
>>> code block.
>>> - New eeh_pe_inject_mmio_error wrapper function added to avoid
>>> CONFIG_EEH is not set.
>>
>> I don't see why that's necessary?
>>
>> It's only called from eeh_pseries.c, which is only built for
>> PPC_PSERIES, and when PPC_PSERIES=y, EEH is always enabled.
>>
>>> diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
>>> index 91a9fd53254f..8da6b047a4fe 100644
>>> --- a/arch/powerpc/include/asm/eeh.h
>>> +++ b/arch/powerpc/include/asm/eeh.h
>>> @@ -308,7 +308,7 @@ int eeh_pe_reset(struct eeh_pe *pe, int option, bool
>>> include_passed);
>>> int eeh_pe_configure(struct eeh_pe *pe);
>>> int eeh_pe_inject_err(struct eeh_pe *pe, int type, int func,
>>> unsigned long addr, unsigned long mask);
>>> -
>>> +int eeh_pe_inject_mmio_error(struct pci_dev *pdev);
>>> /**
>>>* EEH_POSSIBLE_ERROR() -- test for possible MMIO failure.
>>>*
>>> @@ -338,6 +338,10 @@ static inline int eeh_check_failure(const volatile
>>> void __iomem *token)
>>> return 0;
>>> }
>>>
>>> +static inline int eeh_pe_inject_mmio_error(struct pci_dev *pdev)
>>> +{
>>> + return -ENXIO;
>>> +}
>>> #define eeh_dev_check_failure(x) (0)
>>>
>>> static inline void eeh_addr_cache_init(void) { }
>>> diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
>>> index d03f17987fca..49ab11a287a3 100644
>>> --- a/arch/powerpc/kernel/eeh.c
>>> +++ b/arch/powerpc/kernel/eeh.c
>>> @@ -1537,10 +1537,6 @@ int eeh_pe_inject_err(struct eeh_pe *pe, int type,
>>> int func,
>>> if (!eeh_ops || !eeh_ops->err_inject)
>>> return -ENOENT;
>>>
>>> - /* Check on PCI error type */
>>> - if (type != EEH_ERR_TYPE_32 && type != EEH_ERR_TYPE_64)
>>> - return -EINVAL;
>>> -
>>
>> The change log should mention why it's OK to remove these checks. You
>> add the same checks in pseries_eeh_err_inject(), but what about
>> pnv_eeh_err_inject() ?
>>
>> It is OK AFAICS, because pnv_eeh_err_inject() already contains
>> equivalent checks, but you should spell that out.
>>
>> cheers
>
> yes mpe. I do agree, your comments are addressed in V3 posted
>
> here
> https://lore.kernel.org/all/20240909140220.529333-1-nnmli...@linux.ibm.com/
Thanks.
cheers
Re: [PATCH] powerpc/ftrace: restore r2 to caller's stack on livepatch sibling call
"Ryan B. Sullivan" writes: > Hello all, > > Just wanted to ping and see if there was any further feedback or > questions regarding the patch? Hi Ryan, I'd really like a selftest that triggers the sibling call behaviour. As I said upthread I tried writing one but failed. Which you later explained is because the cross-module sibling call is not generated by the compiler but rather by the code being objcopy'ed (or similar). I think it should be possible to trick the compiler into letting us do a cross-module sibling call by doing it in an inline asm block. Obviously that's non-standard, but I think it might work well enough for a test? We have an example of calling a function within an inline asm block in call_do_irq(). I'll try to find time to get that done, but I can't promise when. cheers
Re: [PATCH -next,v2] MIPS: Remove the obsoleted code for include/linux/mv643xx.h
Gaosheng Cui writes: > Most of the drivers which used this header have been deleted, most > of these code is obsoleted, move the only defines that are actually > used into arch/powerpc/platforms/chrp/pegasos_eth.c and delete the > file completely. > > Signed-off-by: Gaosheng Cui > --- > v2: Delete the header file include/linux/mv643xx.h completely. > v1: Remove obsoleted declaration for mv64340_irq_init > MAINTAINERS | 1 - > arch/powerpc/platforms/chrp/pegasos_eth.c | 7 +- > include/linux/mv643xx.h | 921 -- > 3 files changed, 5 insertions(+), 924 deletions(-) > delete mode 100644 include/linux/mv643xx.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 0a3d9e17295a..2b5dbf7f3cd0 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -13708,7 +13708,6 @@ M:Sebastian Hesselbarth > > L: net...@vger.kernel.org > S: Maintained > F: drivers/net/ethernet/marvell/mv643xx_eth.* > -F: include/linux/mv643xx.h You need to Cc netdev and Sebastian. cheers
Re: [PATCH v4 RESEND] powerpc: Replace kretprobe code with rethook on powerpc
Masami Hiramatsu (Google) writes:
> On Fri, 06 Sep 2024 21:52:52 +1000
> Michael Ellerman wrote:
>
>> On Fri, 30 Aug 2024 07:31:31 -0400, Abhishek Dubey wrote:
>> > This is an adaptation of commit f3a112c0c40d ("x86,rethook,kprobes:
>> > Replace kretprobe with rethook on x86") to powerpc.
>> >
>> > Rethook follows the existing kretprobe implementation, but separates
>> > it from kprobes so that it can be used by fprobe (ftrace-based
>> > function entry/exit probes). As such, this patch also enables fprobe
>> > to work on powerpc. The only other change compared to the existing
>> > kretprobe implementation is doing the return address fixup in
>> > arch_rethook_fixup_return().
>> >
>> > [...]
>>
>> Applied to powerpc/next.
>>
>> [1/1] powerpc: Replace kretprobe code with rethook on powerpc
>>
>> https://git.kernel.org/powerpc/c/19f1bc3fb55452739dd3d56cfd06c29ecdbe3e9f
>
> Thanks, and sorry for late reply, but I don't have any objection.
Thanks. No worries.
cheers
Re: [PATCH] crash: Default to CRASH_DUMP=n when support for it is unlikely
Dave Vasilevsky writes: > I received a notification from Patchwork that my patch is now in the > state "Handled Elsewhere".[0] Does that mean someone merged it > somewhere? Or that I should be using a different mailing list? Or > something else? > > I'd appreciate some guidance. It was sent/Cc'ed to linuxppc-dev, so it was picked up by the linuxppc patchwork, which is fine and normal. Because it touches many arches I don't plan to merge it, I would expect the kexec maintainers to take it. So I marked it as "Handled Elsewhere" in the linuxppc patchwork - ie. not handled via the powerpc tree. That doesn't mean anyone else has merged it, it just means I haven't and don't plan to. cheers
Re: [PATCH] powerpc/xive: Use cpumask_intersects()
Costa Shulyupin writes:
> Replace `cpumask_any_and(a, b) >= nr_cpu_ids`
> with the more readable `!cpumask_intersects(a, b)`.
I agree it's more readable.
It would be nice if the change log told me that both functions have
similar performance behaviour. I'm not saying this is a super hot path,
but CPU masks can get pretty big, and some cpumask routines compute the
full mask while others short-circuit.
cheers
> diff --git a/arch/powerpc/sysdev/xive/common.c
> b/arch/powerpc/sysdev/xive/common.c
> index fa01818c1972c..a6c388bdf5d08 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -726,7 +726,7 @@ static int xive_irq_set_affinity(struct irq_data *d,
> pr_debug("%s: irq %d/0x%x\n", __func__, d->irq, hw_irq);
>
> /* Is this valid ? */
> - if (cpumask_any_and(cpumask, cpu_online_mask) >= nr_cpu_ids)
> + if (!cpumask_intersects(cpumask, cpu_online_mask))
> return -EINVAL;
>
> /*
> --
> 2.45.0
Re: [PATCH 1/2] powerpc/vdso: Fix VDSO data access when running in a non-root time namespace
"Jason A. Donenfeld" writes:
> On Fri, Sep 06, 2024 at 03:43:17PM +0200, Jason A. Donenfeld wrote:
>> On Fri, Sep 06, 2024 at 10:23:08PM +1000, Michael Ellerman wrote:
>> > Christophe Leroy writes:
>> > > When running in a non-root time namespace, the global VDSO data page
>> > > is replaced by a dedicated namespace data page and the global data
>> > > page is mapped next to it. Detailed explanations can be found at
>> > > commit 660fd04f9317 ("lib/vdso: Prepare for time namespace support").
>> > >
>> > > When it happens, __kernel_get_syscall_map and __kernel_get_tbfreq
>> > > and __kernel_sync_dicache don't work anymore because they read 0
>> > > instead of the data they need.
>> > >
>> > > To address that, clock_mode has to be read. When it is set to
>> > > VDSO_CLOCKMODE_TIMENS, it means it is a dedicated namespace data page
>> > > and the global data is located on the following page.
>> > >
>> > > Add a macro called get_realdatapage which reads clock_mode and add
>> > > PAGE_SIZE to the pointer provided by get_datapage macro when
>> > > clock_mode is equal to VDSO_CLOCKMODE_TIMENS. Use this new macro
>> > > instead of get_datapage macro except for time functions as they handle
>> > > it internally.
>> > >
>> > > Fixes: 74205b3fc2ef ("powerpc/vdso: Add support for time namespaces")
>> > > Signed-off-by: Christophe Leroy
>> >
>> > Oops.
>> >
>> > I guess it should also have:
>> >
>> > Cc: sta...@vger.kernel.org # v5.13+
>> > Reported-by: Jason A. Donenfeld
>> > Closes: https://lore.kernel.org/all/ztnyqzi-nrsns...@zx2c4.com/
>> >
>> > Jason how do you want to handle this?
>> >
>> > I can put patch 1 in a topic branch that we both merge? Then you can
>> > apply patch 2 on top of that merge in your tree.
>> >
>> > Or we could both apply patch 1 to our trees, it might lead to a conflict
>> > but it wouldn't be anything drastic.
>>
>> The merge window for 6.12 is pretty soon. Why don't I just take this in
>> my random.git tree (with your ack) as a prereq to the ppc vDSO work.
>> It'll slide in _before_ Christophe's other commits, and then the
>> separate vgetrandom fixup will be squashed in the right place there.
>>
>> And then it'll hit stable when that's submitted for 6.12. It's an old
>> bug that nobody noticed, and time namespaces are kind of obscure, so I
>> think waiting a week and a half for the merge window to open is probably
>> fine.
>
> So I've just done this (preliminarily, pending Michael's approval), and
> it comes out decently clean and everything works fine.
Sorry, didn't check email over the weekend.
Acked-by: Michael Ellerman (powerpc)
> The commit
> sequence becomes:
>
> ...
> c206cd11e7f2 selftests: vDSO: ensure vgetrandom works in a time namespace
> ...
> e59cc170924c powerpc/vdso: Fix VDSO data access when running in a non-root
> time namespace
> 887e7a77dc99 mm: Define VM_DROPPABLE for powerpc/32
> f2ee39ec52c2 powerpc/vdso32: Add crtsavres
> 994148e87080 powerpc/vdso: Refactor CFLAGS for CVDSO build
> c49ec121a6dd powerpc/vdso: Wire up getrandom() vDSO implementation on VDSO32
> <-- fixed up
> a8a5e16cde32 powerpc/vdso: Wire up getrandom() vDSO implementation on VDSO64
>
> So I'm happy with this.
Thanks.
cheers
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-6.11-3 tag
Linus Torvalds writes: > On Fri, 6 Sept 2024 at 05:08, Michael Ellerman wrote: >> >> Please pull some more powerpc fixes for 6.11: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git >> tags/powerpc-6.11-3 > > Hmm. New pgp key? Please don't take me by surprise like this. Yes, sorry. I switched to it a few weeks back but this is the first pull request I've sent since. > The key looks fine, I see the signature by Stephen Rothwell, but I get > worried when I suddenly see a new signature with no notice and then > have to go looking around for it. It's also signed by my old key. I posted it to the keys repo: https://lore.kernel.org/keys/87o75pp2bt.fsf@mail.lhotse/ But yeah I still should have mentioned it in the pull request. cheers
Re: [PATCH 1/2] powerpc/vdso: Fix VDSO data access when running in a non-root time namespace
Christophe Leroy writes:
> When running in a non-root time namespace, the global VDSO data page
> is replaced by a dedicated namespace data page and the global data
> page is mapped next to it. Detailed explanations can be found at
> commit 660fd04f9317 ("lib/vdso: Prepare for time namespace support").
>
> When it happens, __kernel_get_syscall_map and __kernel_get_tbfreq
> and __kernel_sync_dicache don't work anymore because they read 0
> instead of the data they need.
>
> To address that, clock_mode has to be read. When it is set to
> VDSO_CLOCKMODE_TIMENS, it means it is a dedicated namespace data page
> and the global data is located on the following page.
>
> Add a macro called get_realdatapage which reads clock_mode and add
> PAGE_SIZE to the pointer provided by get_datapage macro when
> clock_mode is equal to VDSO_CLOCKMODE_TIMENS. Use this new macro
> instead of get_datapage macro except for time functions as they handle
> it internally.
>
> Fixes: 74205b3fc2ef ("powerpc/vdso: Add support for time namespaces")
> Signed-off-by: Christophe Leroy
Oops.
I guess it should also have:
Cc: sta...@vger.kernel.org # v5.13+
Reported-by: Jason A. Donenfeld
Closes: https://lore.kernel.org/all/ztnyqzi-nrsns...@zx2c4.com/
Jason how do you want to handle this?
I can put patch 1 in a topic branch that we both merge? Then you can
apply patch 2 on top of that merge in your tree.
Or we could both apply patch 1 to our trees, it might lead to a conflict
but it wouldn't be anything drastic.
cheers
[GIT PULL] Please pull powerpc/linux.git powerpc-6.11-3 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Linus, Please pull some more powerpc fixes for 6.11: The following changes since commit 227bbaabe64b6f9cd98aa051454c1d4a194a8c6a: powerpc/topology: Check if a core is online (2024-08-13 10:32:17 +1000) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-6.11-3 for you to fetch changes up to 734ad0af3609464f8f93e00b6c0de1e112f44559: powerpc/qspinlock: Fix deadlock in MCS queue (2024-08-29 15:12:51 +1000) - -- powerpc fixes for 6.11 #3 - Fix a deadlock in the powerpc qspinlock MCS queue logic. - Fix the return type of pgd_val() to not truncate 64-bit PTEs on 85xx. - Allow the check for dynamic relocations in the VDSO to work correctly. - Make mmu_pte_psize static to fix a build error. Thanks to: Christophe Leroy, Nysal Jan K.A., Nicholas Piggin, Geetika Moolchandani, Jijo Varghese, Vaishnavi Bhat. - -- Christophe Leroy (3): powerpc/64e: Define mmu_pte_psize static powerpc/vdso: Don't discard rela sections powerpc/mm: Fix return type of pgd_val() Nysal Jan K.A. (1): powerpc/qspinlock: Fix deadlock in MCS queue arch/powerpc/include/asm/nohash/32/pgtable.h | 4 ++-- arch/powerpc/include/asm/pgtable-types.h | 12 +--- arch/powerpc/kernel/vdso/vdso32.lds.S| 4 +++- arch/powerpc/kernel/vdso/vdso64.lds.S| 4 ++-- arch/powerpc/lib/qspinlock.c | 10 +- arch/powerpc/mm/nohash/tlb_64e.c | 2 +- 6 files changed, 26 insertions(+), 10 deletions(-) -BEGIN PGP SIGNATURE- iHUEARYKAB0WIQRjvi15rv0TSTaE+SIF0oADX8seIQUCZtrv3QAKCRAF0oADX8se IbILAQDjj0pScmC9KZX8xYxH7QT7uw4WnTvuYclNNOMQAU/NhgD8DVMpHfMcj75r ErmOete8qKyD/3w1P+70YGICf4yKewU= =fFem -END PGP SIGNATURE-
Re: [PATCH] KVM: PPC: remove unused varible
On Fri, 16 Aug 2024 17:33:12 +0800, al...@kernel.org wrote: > During build testing, we found a error: > /arch/powerpc/kvm/book3s_hv.c:4052:17: error: variable 'loops' set but not > used [-Werror,-Wunused-but-set-variable] > unsigned long loops = 0; > 1 error generated. > > Remove the unused variable could fix this. > > [...] Applied to powerpc/topic/ppc-kvm. [1/1] KVM: PPC: remove unused varible https://git.kernel.org/powerpc/c/46765aaec4d78b9fef59e647ab228283991de075 cheers
Re: [PATCH] powerpc/configs/64s: Enable DEFERRED_STRUCT_PAGE_INIT
On Tue, 20 Aug 2024 16:57:05 +1000, Michael Ellerman wrote: > It can speed up initialisation of page structs at boot on large > machines. > > Applied to powerpc/next. [1/1] powerpc/configs/64s: Enable DEFERRED_STRUCT_PAGE_INIT https://git.kernel.org/powerpc/c/d6b34416b08895a7457c53630595ce84e4aa904c cheers
Re: [PATCH] powerpc/64s/mm: Move __real_pte stubs into hash-4k.h
On Wed, 21 Aug 2024 18:07:29 +1000, Michael Ellerman wrote: > The stub versions of __real_pte() etc are only used with HPT & 4K pages, > so move them into the hash-4k.h header. > > Applied to powerpc/next. [1/1] powerpc/64s/mm: Move __real_pte stubs into hash-4k.h https://git.kernel.org/powerpc/c/8ae4f16f7d7b59cca55aeca6db7c9636ffe7fbaa cheers
Re: [PATCH 0/2] Use helper function for_each_child_of_node()
On Thu, 22 Aug 2024 16:54:28 +0800, Zhang Zekun wrote: > Use for_each_child_of_node() to iterate through the device_node, this > can make code more simple. > > Zhang Zekun (2): > powerpc/powermac/pfunc_base: Use helper function > for_each_child_of_node() > powerpc/pseries/dlpar: Use helper function for_each_child_of_node() > > [...] Applied to powerpc/next. [1/2] powerpc/powermac/pfunc_base: Use helper function for_each_child_of_node() https://git.kernel.org/powerpc/c/197116e2dec8d23888ce76044fe673480afceff0 [2/2] powerpc/pseries/dlpar: Use helper function for_each_child_of_node() https://git.kernel.org/powerpc/c/46f4bbb8aac2b876355cdefdacd1971b65f8b631 cheers
Re: [PATCH] powerpc: Stop using no_llseek
On Tue, 03 Sep 2024 21:19:51 +1000, Michael Ellerman wrote:
> Since commit 868941b14441 ("fs: remove no_llseek"), no_llseek() is
> simply defined to be NULL, and a NULL llseek means seeking is
> unsupported.
>
> So for statically defined file_operations, such as all these, there's no
> need or benefit to set llseek = no_llseek.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Stop using no_llseek
https://git.kernel.org/powerpc/c/5b4bc44a4854ccd41eef9aa9f47677f7d136c294
cheers
Re: [PATCH] powerpc/64s: Remove the "fast endian switch" syscall
On Fri, 23 Aug 2024 17:08:30 +1000, Michael Ellerman wrote: > The non-standard "fast endian switch" syscall was added in 2008[1], > but was never widely used. It was disabled by default in 2017[2], and > there's no evidence it's ever been used since. > > Remove it entirely. > > A normal endian switch syscall was added in 2015[3]. > > [...] Applied to powerpc/next. [1/1] powerpc/64s: Remove the "fast endian switch" syscall https://git.kernel.org/powerpc/c/29dbb984496daa490f3c1181b734b538a6f7b534 cheers
Re: [PATCH] powerpc/64s: Make mmu_hash_ops __ro_after_init
On Wed, 21 Aug 2024 18:07:45 +1000, Michael Ellerman wrote: > The mmu_hash_ops are only assigned to during boot, so mark them > __ro_after_init to prevent any further modification. > > Applied to powerpc/next. [1/1] powerpc/64s: Make mmu_hash_ops __ro_after_init https://git.kernel.org/powerpc/c/8589cdf0cf0b0a03d2285fc46ada2f28113f8620 cheers
Re: [PATCH] macintosh/via-pmu: register_pmu_pm_ops() can be __init
On Wed, 21 Aug 2024 18:21:01 +1000, Michael Ellerman wrote: > register_pmu_pm_ops() is only called at init time, via > device_initcall(), so can be marked __init. The driver can't be built as > a module. > > Applied to powerpc/next. [1/1] macintosh/via-pmu: register_pmu_pm_ops() can be __init https://git.kernel.org/powerpc/c/a5a670df1db79f4bb462601aa4cc03caffa761a2 cheers
Re: [PATCH 1/2] powerpc/mm/64s: Move THP reqs into a separate symbol
On Fri, 23 Aug 2024 13:29:10 +1000, Michael Ellerman wrote: > Move the Kconfig symbols related to transparent hugepages (THP) under a > separate config symbol, separate from CONFIG_PPC_BOOK3S_64. > > The new symbol is automatically enabled if CONFIG_PPC_BOOK3S_64 is > enabled, so there is no behaviour change, except for the existence of > the new PPC_THP symbol. > > [...] Applied to powerpc/next. [1/2] powerpc/mm/64s: Move THP reqs into a separate symbol https://git.kernel.org/powerpc/c/f61d413a1c1feaa4cd04fca840564ab90124bec4 [2/2] powerpc/mm/64s: Restrict THP to Radix or HPT w/64K pages https://git.kernel.org/powerpc/c/87def77bb5f4b61d47538a34bb2b2cb7db3c037b cheers
Re: [PATCH v3] powerpc/xmon: Fix tmpstr length check in scanhex
On Mon, 26 Aug 2024 12:12:17 +0530, Madhavan Srinivasan wrote: > If a function name is greater than 63 char long, xmon command > may not find them. For example, here is a test that > executed an illegal instruction in a kernel function and one of > call stack function has name >63 char long, > > cpu 0x0: Vector: 700 (Program Check) at [ca6577e0] > pc: c01aacb8: > check__allowed__function__name__for__symbol__r4+0x8/0x10 > lr: c019c1e0: > check__allowed__function__name__for__symbol__r1+0x20/0x40 > sp: ca657a80 >msr: 8288b033 > current = 0xca439900 > paca= 0xc3e9 irqmask: 0x03 irq_happened: 0x01 > . > [link register ] c019c1e0 > check__allowed__function__name__for__symbol__r1+0x20/0x40 > [ca657a80] ca439900 (unreliable) > [ca657aa0] c01021d8 > check__allowed__function__name__for__symbol__r2_resolution_symbol+0x38/0x4c > [ca657ac0] c019b424 power_pmu_event_init+0xa4/0xa50 > > [...] Applied to powerpc/next. [1/1] powerpc/xmon: Fix tmpstr length check in scanhex https://git.kernel.org/powerpc/c/0405e128110d47a40443936e68dc32d7bc4ccc0b cheers
Re: [PATCH -next 1/3] powerpc: Constify struct kobj_type
On Mon, 26 Aug 2024 23:09:55 +0800, Huang Xiaojia wrote: > 'struct kobj_type' is not modified. It is only used in > kobject_init_and_add()/kobject_init() which takes > a 'const struct kobj_type *ktype' parameter. > > Constifying this structure moves some data to a read-only section, > so increase over all security. > > [...] Applied to powerpc/next. [1/3] powerpc: Constify struct kobj_type https://git.kernel.org/powerpc/c/7509c23770054fdaffd966926462248d44a323c1 [2/3] powerpc: powernv: Constify struct kobj_type https://git.kernel.org/powerpc/c/7492ca369e98a45b55592456dc1b24d58b3392f5 [3/3] powerpc: pseries: Constify struct kobj_type https://git.kernel.org/powerpc/c/6f2683274d0d0b51a986f73c2afb9058156f1641 cheers
Re: [PATCH v3 1/3] powerpc/pseries: Use correct data types from pseries_hp_errorlog struct
On Wed, 21 Aug 2024 19:50:26 -0700, Haren Myneni wrote: > _be32 type is defined for some elements in pseries_hp_errorlog > struct but also used them u32 after be32_to_cpu() conversion. > > Example: In handle_dlpar_errorlog() > hp_elog->_drc_u.drc_index = be32_to_cpu(hp_elog->_drc_u.drc_index); > > And later assigned to u32 type > dlpar_cpu() - u32 drc_index = hp_elog->_drc_u.drc_index; > > [...] Applied to powerpc/next. [1/3] powerpc/pseries: Use correct data types from pseries_hp_errorlog struct https://git.kernel.org/powerpc/c/b76e0d4215b6b622127ebcceaa7f603313ceaec4 [2/3] powerpc/pseries/dlpar: Remove device tree node for DLPAR IO remove https://git.kernel.org/powerpc/c/17a51171c20d590d3d3c632bcdd946f5fc3c0061 [3/3] powerpc/pseries/dlpar: Add device tree nodes for DLPAR IO add https://git.kernel.org/powerpc/c/02b98ff44a57c1376c5a92a8518fda5c82bb5a91 cheers
Re: [PATCH -next] powerpc/powernv/pci: Remove obsoleted declaration for pnv_pci_init_ioda_hub
On Thu, 22 Aug 2024 21:00:43 +0800, Gaosheng Cui wrote:
> The pnv_pci_init_ioda_hub() have been removed since
> commit 5ac129cdb50b ("powerpc/powernv/pci: Remove ioda1 support"),
> and now it is useless, so remove it.
>
>
Applied to powerpc/next.
[1/1] powerpc/powernv/pci: Remove obsoleted declaration for
pnv_pci_init_ioda_hub
https://git.kernel.org/powerpc/c/10c8ac13395a087c90ba6acd11f793588ba5609e
cheers
Re: [PATCH -next 0/4] Remove obsoleted declaration for powerpc
On Thu, 22 Aug 2024 21:06:05 +0800, Gaosheng Cui wrote: > Remove obsoleted declaration for powerpc, thanks! > > Gaosheng Cui (4): > powerpc: Remove obsoleted declaration for _get_SP > powerpc: Remove obsoleted declaration for maple_calibrate_decr > powerpc: Remove obsoleted declaration for pas_pci_irq_fixup > powerpc: Remove obsoleted declarations for use_cop and drop_cop > > [...] Applied to powerpc/next. [1/4] powerpc: Remove obsoleted declaration for _get_SP https://git.kernel.org/powerpc/c/dace02a9ee1921adee05bf1807a78f92ee2dea2b [2/4] powerpc: Remove obsoleted declaration for maple_calibrate_decr https://git.kernel.org/powerpc/c/6745c5bb2e0fe513918ce2136108a2efb92bdea1 [3/4] powerpc: Remove obsoleted declaration for pas_pci_irq_fixup https://git.kernel.org/powerpc/c/fe16a749731e86d580acf8d43b0298dfe6d1503d [4/4] powerpc: Remove obsoleted declarations for use_cop and drop_cop https://git.kernel.org/powerpc/c/600d6a7e630e970624911624eb15986245b18668 cheers
Re: [PATCH 00/14] Reduce alignment constraint on STRICT_KERNEL_RWX and speed-up TLB misses on 8xx and 603
On Tue, 20 Aug 2024 19:23:44 +0200, Christophe Leroy wrote: > This series does mainly two things: > - Remove the 8M alignment constraint on STRICT_KERNEL_RWX on 8xx to > avoid wasting memory. > - Speed-up TLB misses by duplicating kernel PGD entries into each > task's PGDIRs to avoid the address comparison in TLB miss handler. > > On 8xx, the address comparison takes a significant part of CPU cycles > as it requires saving/restoring CR, and because a taken branch > requires 2 cycles. > On 603 it is less significant because CR is saved automatically and > has to be restored anyway but it is still worth it. > > [...] Applied to powerpc/next. [01/14] powerpc/8xx: Fix initial memory mapping https://git.kernel.org/powerpc/c/f9f2bff64c2f0dbee57be3d8c2741357ad3d05e6 [02/14] powerpc/8xx: Fix kernel vs user address comparison https://git.kernel.org/powerpc/c/65a82e117ffeeab0baf6f871a1cab11a28ace183 [03/14] powerpc/8xx: Copy kernel PGD entries into all PGDIRs https://git.kernel.org/powerpc/c/985db026c34dfc45213649023d5505822a5dcd78 [04/14] Revert "powerpc/8xx: Always pin kernel text TLB" https://git.kernel.org/powerpc/c/1a736d98c84acd38e40fff69528ce7aaa55dd22d [05/14] powerpc/8xx: Allow setting DATA alignment even with STRICT_KERNEL_RWX https://git.kernel.org/powerpc/c/bcf77a70c4ffc9b01044229de87f5b6f9c1f7913 [06/14] powerpc/8xx: Reduce default size of module/execmem area https://git.kernel.org/powerpc/c/c5eec4df25c34f4bee8c757ed157f5d96eaba554 [07/14] powerpc/8xx: Preallocate execmem page tables https://git.kernel.org/powerpc/c/16a71c045186a11c1c743934e330de78162b86dd [08/14] powerpc/8xx: Inconditionally use task PGDIR in ITLB misses https://git.kernel.org/powerpc/c/33c527522f394f63cc589a6f7af990b2232444c8 [09/14] powerpc/8xx: Inconditionally use task PGDIR in DTLB misses https://git.kernel.org/powerpc/c/ac9f97ff8b324905d457f2694490c63b9deccbc6 [10/14] powerpc/32s: Reduce default size of module/execmem area https://git.kernel.org/powerpc/c/2f2b9a3adc66e978a1248ffb38df8477e8e97c57 [11/14] powerpc/603: Copy kernel PGD entries into all PGDIRs and preallocate execmem page tables https://git.kernel.org/powerpc/c/82ef440f9a38a1fd7f4854397633a35af33840a5 [12/14] powerpc/603: Switch r0 and r3 in TLB miss handlers https://git.kernel.org/powerpc/c/31c0e137ec609f36877ea39cd343ef2476d080aa [13/14] powerpc/603: Inconditionally use task PGDIR in ITLB misses https://git.kernel.org/powerpc/c/3f57d90c231d3329aaed7079dd05b5a2f7692a58 [14/14] powerpc/603: Inconditionally use task PGDIR in DTLB misses https://git.kernel.org/powerpc/c/062e825a336017c0334c7497690826c95aa1a84f cheers
Re: [PATCH] powerpc/vdso: Inconditionally use CFUNC macro
On Thu, 22 Aug 2024 10:00:29 +0200, Christophe Leroy wrote:
> During merge of commit 4e991e3c16a3 ("powerpc: add CFUNC assembly
> label annotation") a fallback version of CFUNC macro was added at
> the last minute, so it can be used inconditionally.
>
>
Applied to powerpc/next.
[1/1] powerpc/vdso: Inconditionally use CFUNC macro
https://git.kernel.org/powerpc/c/65948b0e716a47382731889ee6bbb18642b8b003
cheers
Re: [PATCH v2] powerpc/32: Implement validation of emergency stack
On Tue, 20 Aug 2024 14:26:54 +0200, Christophe Leroy wrote: > VMAP stack added an emergency stack on powerpc/32 for when there is > a stack overflow, but failed to add stack validation for that > emergency stack. That validation is required for show stack. > > Implement it. > > > [...] Applied to powerpc/next. [1/1] powerpc/32: Implement validation of emergency stack https://git.kernel.org/powerpc/c/dca5b1d69aea36ab559d9ca13729370007c60df1 cheers
Re: [PATCH v4 RESEND] powerpc: Replace kretprobe code with rethook on powerpc
On Fri, 30 Aug 2024 07:31:31 -0400, Abhishek Dubey wrote:
> This is an adaptation of commit f3a112c0c40d ("x86,rethook,kprobes:
> Replace kretprobe with rethook on x86") to powerpc.
>
> Rethook follows the existing kretprobe implementation, but separates
> it from kprobes so that it can be used by fprobe (ftrace-based
> function entry/exit probes). As such, this patch also enables fprobe
> to work on powerpc. The only other change compared to the existing
> kretprobe implementation is doing the return address fixup in
> arch_rethook_fixup_return().
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Replace kretprobe code with rethook on powerpc
https://git.kernel.org/powerpc/c/19f1bc3fb55452739dd3d56cfd06c29ecdbe3e9f
cheers
Re: [PATCH v2] powerpc/qspinlock: Fix deadlock in MCS queue
On Thu, 29 Aug 2024 07:58:27 +0530, Nysal Jan K.A. wrote: > If an interrupt occurs in queued_spin_lock_slowpath() after we increment > qnodesp->count and before node->lock is initialized, another CPU might > see stale lock values in get_tail_qnode(). If the stale lock value happens > to match the lock on that CPU, then we write to the "next" pointer of > the wrong qnode. This causes a deadlock as the former CPU, once it becomes > the head of the MCS queue, will spin indefinitely until it's "next" pointer > is set by its successor in the queue. > > [...] Applied to powerpc/fixes. [1/1] powerpc/qspinlock: Fix deadlock in MCS queue https://git.kernel.org/powerpc/c/734ad0af3609464f8f93e00b6c0de1e112f44559 cheers
Re: [oss-security] Linux kernel: memory leak in arch/powerpc/platforms/powernv/opal-irqchip.c: opal_event_init()
Solar Designer writes:
> Hi,
>
> This bug report is misaddressed. Per upstream's preference and common
> sense (given how many issue reports there are against the Linux kernel),
> most Linux kernel (maybe-)issues should first be reported to Linux
> kernel maintainers/lists or (if you're reasonably sure of significant
> security relevance) to the Linux kernel security team, and only then (if
> relevant) maybe also to general security lists. Occasional exceptions
> exist, such as for publicly exploited issues, but if you're new to this
> chances are that you should play by the rules, not claim an exception.
This was also reported to secur...@kernel.org, and I replied saying
there was no real security impact and that it should be reported to
linuxppc-dev@lists.ozlabs.org.
> On Mon, Sep 02, 2024 at 09:54:52AM +0800, 2639161967 wrote:
>> in the newest linux release version,
>> in /arch/powerpc/platforms/powernv/opal-irqchip.c file , the
>> opal_event_init function, the variable "name"defined in line 270, and is
>> alloced memory in line 274 or 276, but not free, cause many times memory
>> leak, and most old release versions have the problem.
>
> The code in question is:
>
> int __init opal_event_init(void)
> {
> [...]
> /* Install interrupt handlers */
> for (i = 0; i < opal_irq_count; i++) {
> struct resource *r = &opal_irqs[i];
> const char *name;
>
> /* Prefix name */
> if (r->name && strlen(r->name))
> name = kasprintf(GFP_KERNEL, "opal-%s", r->name);
> else
> name = kasprintf(GFP_KERNEL, "opal");
>
> if (!name)
> continue;
> /* Install interrupt handler */
> rc = request_irq(r->start, opal_interrupt, r->flags &
> IRQD_TRIGGER_MASK,
>name, NULL);
> if (rc) {
> pr_warn("Error %d requesting OPAL irq %d\n", rc,
> (int)r->start);
> continue;
> }
> }
...
>
> I'm CC'ing this to some maintainers in case they want to add to the "if
> (rc) {" block, if only to silence static analysis tools, but other than
> that I see nothing to do on this report.
If the request_irq() fails it's either some sort of firmware
misconfiguration, or ENOMEM, both which are possibly fatal to the
machine.
But still, it would be reasonable to kfree() name in the error path, as
you say if only to keep the static analysis clean.
Thanks for looking at it and sorry for the noise on your lists.
cheers
Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits
Charlie Jenkins writes:
> Create a personality flag ADDR_LIMIT_47BIT to support applications
> that wish to transition from running in environments that support at
> most 47-bit VAs to environments that support larger VAs. This
> personality can be set to cause all allocations to be below the 47-bit
> boundary. Using MAP_FIXED with mmap() will bypass this restriction.
>
> Signed-off-by: Charlie Jenkins
> ---
> include/uapi/linux/personality.h | 1 +
> mm/mmap.c| 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/include/uapi/linux/personality.h
> b/include/uapi/linux/personality.h
> index 49796b7756af..cd3b8c154d9b 100644
> --- a/include/uapi/linux/personality.h
> +++ b/include/uapi/linux/personality.h
> @@ -22,6 +22,7 @@ enum {
> WHOLE_SECONDS = 0x200,
> STICKY_TIMEOUTS = 0x400,
> ADDR_LIMIT_3GB =0x800,
> + ADDR_LIMIT_47BIT = 0x1000,
> };
I wonder if ADDR_LIMIT_128T would be clearer?
Have you looked at writing an update for the personality(2) man page? :)
cheers
Re: [PATCH v2] powerpc/pseries/eeh: Fix pseries_eeh_err_inject
Narayana Murty N writes:
> VFIO_EEH_PE_INJECT_ERR ioctl is currently failing on pseries
> due to missing implementation of err_inject eeh_ops for pseries.
> This patch implements pseries_eeh_err_inject in eeh_ops/pseries
> eeh_ops. Implements support for injecting MMIO load/store error
> for testing from user space.
>
> The check on PCI error type code is moved to platform code, since
> the eeh_pe_inject_err can be allowed to more error types depending
> on platform requirement.
>
> Signed-off-by: Narayana Murty N
> ---
>
> Testing:
>
> vfio-test [1] by Alex Willamson, was forked and updated to add
> support inject error on pSeries guest and used to test this
> patch[2].
>
> References:
> ===
> [1] https://github.com/awilliam/tests
> [2] https://github.com/nnmwebmin/vfio-ppc-tests/tree/vfio-ppc-ex
>
>
> Changelog:
> V1:https://lore.kernel.org/all/20240822082713.529982-1-nnmli...@linux.ibm.com/
> - Resolved build issues for ppc64|le_defconfig by moving the
> pseries_eeh_err_inject() definition outside of the CONFIG_PCI_IOV
> code block.
> - New eeh_pe_inject_mmio_error wrapper function added to avoid
> CONFIG_EEH is not set.
I don't see why that's necessary?
It's only called from eeh_pseries.c, which is only built for
PPC_PSERIES, and when PPC_PSERIES=y, EEH is always enabled.
> diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
> index 91a9fd53254f..8da6b047a4fe 100644
> --- a/arch/powerpc/include/asm/eeh.h
> +++ b/arch/powerpc/include/asm/eeh.h
> @@ -308,7 +308,7 @@ int eeh_pe_reset(struct eeh_pe *pe, int option, bool
> include_passed);
> int eeh_pe_configure(struct eeh_pe *pe);
> int eeh_pe_inject_err(struct eeh_pe *pe, int type, int func,
> unsigned long addr, unsigned long mask);
> -
> +int eeh_pe_inject_mmio_error(struct pci_dev *pdev);
> /**
> * EEH_POSSIBLE_ERROR() -- test for possible MMIO failure.
> *
> @@ -338,6 +338,10 @@ static inline int eeh_check_failure(const volatile void
> __iomem *token)
> return 0;
> }
>
> +static inline int eeh_pe_inject_mmio_error(struct pci_dev *pdev)
> +{
> + return -ENXIO;
> +}
> #define eeh_dev_check_failure(x) (0)
>
> static inline void eeh_addr_cache_init(void) { }
> diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
> index d03f17987fca..49ab11a287a3 100644
> --- a/arch/powerpc/kernel/eeh.c
> +++ b/arch/powerpc/kernel/eeh.c
> @@ -1537,10 +1537,6 @@ int eeh_pe_inject_err(struct eeh_pe *pe, int type, int
> func,
> if (!eeh_ops || !eeh_ops->err_inject)
> return -ENOENT;
>
> - /* Check on PCI error type */
> - if (type != EEH_ERR_TYPE_32 && type != EEH_ERR_TYPE_64)
> - return -EINVAL;
> -
The change log should mention why it's OK to remove these checks. You
add the same checks in pseries_eeh_err_inject(), but what about
pnv_eeh_err_inject() ?
It is OK AFAICS, because pnv_eeh_err_inject() already contains
equivalent checks, but you should spell that out.
cheers
Re: [PATCH 13/15] powerpc/rtas: Use fsleep() to minimize additional sleep duration
Anna-Maria Behnsen writes:
> When commit 38f7b7067dae ("powerpc/rtas: rtas_busy_delay() improvements")
> was introduced, documentation about proper usage of sleep realted functions
> was outdated.
>
...
> Use fsleep() directly instead of using an own heuristic for the best
> sleeping mechanism to use..
Thanks for tidying this up. I only learnt about fsleep() in the last ~year.
Two minor nits ...
> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
> index f7e86e09c49f..0794ca28e51e 100644
> --- a/arch/powerpc/kernel/rtas.c
> +++ b/arch/powerpc/kernel/rtas.c
> @@ -1390,21 +1390,14 @@ bool __ref rtas_busy_delay(int status)
>*/
> ms = clamp(ms, 1U, 1000U);
> /*
> - * The delay hint is an order-of-magnitude suggestion, not
> - * a minimum. It is fine, possibly even advantageous, for
> - * us to pause for less time than hinted. For small values,
> - * use usleep_range() to ensure we don't sleep much longer
> - * than actually needed.
> - *
> - * See Documentation/timers/timers-howto.rst for
> - * explanation of the threshold used here. In effect we use
> - * usleep_range() for 9900 and 9901, msleep() for
> - * 9902-9905.
> + * The delay hint is an order-of-magnitude suggestion, not a
> + * minimum. It is fine, possibly even advantageous, for us to
> + * pause for less time than hinted. To make sure pause time will
> + * not be a way longer than requested independent of HZ
"not be way longer" reads better I think?
> + * configuration, use fsleep(). See fsleep() for detailes of
^
details
> + * used sleeping functions.
>*/
> - if (ms <= 20)
> - usleep_range(ms * 100, ms * 1000);
> - else
> - msleep(ms);
> + fsleep(ms * 1000);
> break;
> case RTAS_BUSY:
> ret = true;
Acked-by: Michael Ellerman (powerpc)
cheers
Re: [PATCH v5 0/5] Wire up getrandom() vDSO implementation on powerpc
"Jason A. Donenfeld" writes: > Hi Christophe, Michael, > > On Mon, Sep 02, 2024 at 09:17:17PM +0200, Christophe Leroy wrote: >> This series wires up getrandom() vDSO implementation on powerpc. >> >> Tested on PPC32 on real hardware. >> Tested on PPC64 (both BE and LE) on QEMU: >> >> Performance on powerpc 885: >> ~# ./vdso_test_getrandom bench-single >> vdso: 2500 times in 62.938002291 seconds >> libc: 2500 times in 535.581916866 seconds >> syscall: 2500 times in 531.525042806 seconds >> >> Performance on powerpc 8321: >> ~# ./vdso_test_getrandom bench-single >> vdso: 2500 times in 16.899318858 seconds >> libc: 2500 times in 131.050596522 seconds >> syscall: 2500 times in 129.794790389 seconds >> >> Performance on QEMU pseries: >> ~ # ./vdso_test_getrandom bench-single >> vdso: 2500 times in 4.97162 seconds >> libc: 2500 times in 75.516749981 seconds >> syscall: 2500 times in 86.842242014 seconds > > Looking good. I have no remaining nits on this patchset; it looks good > to me. > > A review from Michael would be nice though (in addition to the necessary > "Ack" I need to commit this to my tree), because there are a lot of PPC > particulars that I don't know enough about to review properly. For > example, you use -ffixed-r30 on PPC64. I'm sure there's a good reason > for this, but I don't know enough to assess it. And cvdso_call I have no > idea what's going on. Etc. It all looks good to me, and has survived some testing. Let's get it merged and get some wider test coverage. There is an existing comment in the a/p/vdso/Makefile about the fixed-r30 thing, tldr is it's a workaround to avoid breaking old versions of Go. For the series: Acked-by: Michael Ellerman (powerpc) If you can include Maddy's test results from Power9 in the change log for patch 5 that'd be nice. cheers
Re: [PATCH 2/3] mm: Pass vm_flags to generic_get_unmapped_area()
Mark Brown writes:
> In preparation for using vm_flags to ensure guard pages for shadow stacks
> supply them as an argument to generic_get_unmapped_area(). The only user
> outside of the core code is the PowerPC book3s64 implementation which is
> trivially wrapping the generic implementation in the radix_enabled() case.
>
> Signed-off-by: Mark Brown
> ---
> arch/powerpc/mm/book3s64/slice.c | 4 ++--
> include/linux/sched/mm.h | 4 ++--
> mm/mmap.c| 10 ++
> 3 files changed, 10 insertions(+), 8 deletions(-)
Acked-by: Michael Ellerman (powerpc)
cheers
> diff --git a/arch/powerpc/mm/book3s64/slice.c
> b/arch/powerpc/mm/book3s64/slice.c
> index ada6bf896ef8..87307d0fc3b8 100644
> --- a/arch/powerpc/mm/book3s64/slice.c
> +++ b/arch/powerpc/mm/book3s64/slice.c
> @@ -641,7 +641,7 @@ unsigned long arch_get_unmapped_area(struct file *filp,
>vm_flags_t vm_flags)
> {
> if (radix_enabled())
> - return generic_get_unmapped_area(filp, addr, len, pgoff, flags);
> + return generic_get_unmapped_area(filp, addr, len, pgoff, flags,
> vm_flags);
>
> return slice_get_unmapped_area(addr, len, flags,
>
> mm_ctx_user_psize(¤t->mm->context), 0);
> @@ -655,7 +655,7 @@ unsigned long arch_get_unmapped_area_topdown(struct file
> *filp,
>vm_flags_t vm_flags)
> {
> if (radix_enabled())
> - return generic_get_unmapped_area_topdown(filp, addr0, len,
> pgoff, flags);
> + return generic_get_unmapped_area_topdown(filp, addr0, len,
> pgoff, flags, vm_flags);
>
> return slice_get_unmapped_area(addr0, len, flags,
>
> mm_ctx_user_psize(¤t->mm->context), 1);
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index c4d34abc45d4..07bb8d4181d7 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -204,11 +204,11 @@ unsigned long mm_get_unmapped_area_vmflags(struct
> mm_struct *mm,
> unsigned long
> generic_get_unmapped_area(struct file *filp, unsigned long addr,
> unsigned long len, unsigned long pgoff,
> - unsigned long flags);
> + unsigned long flags, vm_flags_t vm_flags);
> unsigned long
> generic_get_unmapped_area_topdown(struct file *filp, unsigned long addr,
> unsigned long len, unsigned long pgoff,
> - unsigned long flags);
> + unsigned long flags, vm_flags_t vm_flags);
> #else
> static inline void arch_pick_mmap_layout(struct mm_struct *mm,
>struct rlimit *rlim_stack) {}
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 7528146f886f..b06ba847c96e 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1789,7 +1789,7 @@ unsigned long vm_unmapped_area(struct
> vm_unmapped_area_info *info)
> unsigned long
> generic_get_unmapped_area(struct file *filp, unsigned long addr,
> unsigned long len, unsigned long pgoff,
> - unsigned long flags)
> + unsigned long flags, vm_flags_t vm_flags)
> {
> struct mm_struct *mm = current->mm;
> struct vm_area_struct *vma, *prev;
> @@ -1823,7 +1823,8 @@ arch_get_unmapped_area(struct file *filp, unsigned long
> addr,
> unsigned long len, unsigned long pgoff,
> unsigned long flags, vm_flags_t vm_flags)
> {
> - return generic_get_unmapped_area(filp, addr, len, pgoff, flags);
> + return generic_get_unmapped_area(filp, addr, len, pgoff, flags,
> + vm_flags);
> }
> #endif
>
> @@ -1834,7 +1835,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long
> addr,
> unsigned long
> generic_get_unmapped_area_topdown(struct file *filp, unsigned long addr,
> unsigned long len, unsigned long pgoff,
> - unsigned long flags)
> + unsigned long flags, vm_flags_t vm_flags)
> {
> struct vm_area_struct *vma, *prev;
> struct mm_struct *mm = current->mm;
> @@ -1887,7 +1888,8 @@ arch_get_unmapped_area_topdown(struct file *filp,
> unsigned long addr,
> unsigned long len, unsigned long pgoff,
> unsigned long flags, vm_flags_t vm_flags)
> {
> - return generic_get_unmapped_area_topdown(filp, addr, len, pgoff, flags);
> + return generic_get_unmapped_area_topdown(filp, addr, len, pgoff, flags,
> + vm_flags);
> }
> #endif
>
>
> --
> 2.39.2
[PATCH] powerpc: Stop using no_llseek
Since commit 868941b14441 ("fs: remove no_llseek"), no_llseek() is
simply defined to be NULL, and a NULL llseek means seeking is
unsupported.
So for statically defined file_operations, such as all these, there's no
need or benefit to set llseek = no_llseek.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/eeh.c| 4
arch/powerpc/platforms/52xx/mpc52xx_gpt.c| 1 -
arch/powerpc/platforms/cell/spufs/file.c | 17 -
arch/powerpc/platforms/powernv/eeh-powernv.c | 1 -
arch/powerpc/platforms/pseries/dtl.c | 1 -
5 files changed, 24 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index d03f17987fca..2f7f0efd564a 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1682,7 +1682,6 @@ static ssize_t eeh_force_recover_write(struct file *filp,
static const struct file_operations eeh_force_recover_fops = {
.open = simple_open,
- .llseek = no_llseek,
.write = eeh_force_recover_write,
};
@@ -1726,7 +1725,6 @@ static ssize_t eeh_dev_check_write(struct file *filp,
static const struct file_operations eeh_dev_check_fops = {
.open = simple_open,
- .llseek = no_llseek,
.write = eeh_dev_check_write,
.read = eeh_debugfs_dev_usage,
};
@@ -1846,7 +1844,6 @@ static ssize_t eeh_dev_break_write(struct file *filp,
static const struct file_operations eeh_dev_break_fops = {
.open = simple_open,
- .llseek = no_llseek,
.write = eeh_dev_break_write,
.read = eeh_debugfs_dev_usage,
};
@@ -1893,7 +1890,6 @@ static ssize_t eeh_dev_can_recover(struct file *filp,
static const struct file_operations eeh_dev_can_recover_fops = {
.open = simple_open,
- .llseek = no_llseek,
.write = eeh_dev_can_recover,
.read = eeh_debugfs_dev_usage,
};
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index 2bd6abcdc113..1ea591ec6083 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -644,7 +644,6 @@ static int mpc52xx_wdt_release(struct inode *inode, struct
file *file)
static const struct file_operations mpc52xx_wdt_fops = {
.owner = THIS_MODULE,
- .llseek = no_llseek,
.write = mpc52xx_wdt_write,
.unlocked_ioctl = mpc52xx_wdt_ioctl,
.compat_ioctl = compat_ptr_ioctl,
diff --git a/arch/powerpc/platforms/cell/spufs/file.c
b/arch/powerpc/platforms/cell/spufs/file.c
index 7f4e0db8eb08..d5a2c77bc908 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -453,7 +453,6 @@ static const struct file_operations spufs_cntl_fops = {
.release = spufs_cntl_release,
.read = simple_attr_read,
.write = simple_attr_write,
- .llseek = no_llseek,
.mmap = spufs_cntl_mmap,
};
@@ -634,7 +633,6 @@ static ssize_t spufs_mbox_read(struct file *file, char
__user *buf,
static const struct file_operations spufs_mbox_fops = {
.open = spufs_pipe_open,
.read = spufs_mbox_read,
- .llseek = no_llseek,
};
static ssize_t spufs_mbox_stat_read(struct file *file, char __user *buf,
@@ -664,7 +662,6 @@ static ssize_t spufs_mbox_stat_read(struct file *file, char
__user *buf,
static const struct file_operations spufs_mbox_stat_fops = {
.open = spufs_pipe_open,
.read = spufs_mbox_stat_read,
- .llseek = no_llseek,
};
/* low-level ibox access function */
@@ -769,7 +766,6 @@ static const struct file_operations spufs_ibox_fops = {
.open = spufs_pipe_open,
.read = spufs_ibox_read,
.poll = spufs_ibox_poll,
- .llseek = no_llseek,
};
static ssize_t spufs_ibox_stat_read(struct file *file, char __user *buf,
@@ -797,7 +793,6 @@ static ssize_t spufs_ibox_stat_read(struct file *file, char
__user *buf,
static const struct file_operations spufs_ibox_stat_fops = {
.open = spufs_pipe_open,
.read = spufs_ibox_stat_read,
- .llseek = no_llseek,
};
/* low-level mailbox write */
@@ -901,7 +896,6 @@ static const struct file_operations spufs_wbox_fops = {
.open = spufs_pipe_open,
.write = spufs_wbox_write,
.poll = spufs_wbox_poll,
- .llseek = no_llseek,
};
static ssize_t spufs_wbox_stat_read(struct file *file, char __user *buf,
@@ -929,7 +923,6 @@ static ssize_t spufs_wbox_stat_read(struct file *file, char
__user *buf,
static const struct file_operations spufs_wbox_stat_fops = {
.open = spufs_pipe_open,
.read = spufs_wbox_stat_read,
- .llseek = no_llseek,
};
static int spufs_signal1_open(struct inode *inode, struct file *file)
@@ -1056,7 +1049,6 @@ static const struct file_operations spufs_signal1_fops = {
.read = spufs_signal1_read,
.write = spufs_signal1_write
Re: [PATCH] tty: hvc: convert comma to semicolon
Chen Ni writes:
> Replace a comma between expression statements by a semicolon.
>
> Signed-off-by: Chen Ni
> ---
> drivers/tty/hvc/hvsi_lib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Michael Ellerman (powerpc)
cheers
> diff --git a/drivers/tty/hvc/hvsi_lib.c b/drivers/tty/hvc/hvsi_lib.c
> index 22e1bc4d8a66..b35c44caf3d7 100644
> --- a/drivers/tty/hvc/hvsi_lib.c
> +++ b/drivers/tty/hvc/hvsi_lib.c
> @@ -303,7 +303,7 @@ int hvsilib_write_mctrl(struct hvsi_priv *pv, int dtr)
> pr_devel("HVSI@%x: %s DTR...\n", pv->termno,
>dtr ? "Setting" : "Clearing");
>
> - ctrl.hdr.type = VS_CONTROL_PACKET_HEADER,
> + ctrl.hdr.type = VS_CONTROL_PACKET_HEADER;
> ctrl.hdr.len = sizeof(struct hvsi_control);
> ctrl.verb = cpu_to_be16(VSV_SET_MODEM_CTL);
> ctrl.mask = cpu_to_be32(HVSI_TSDTR);
> --
> 2.25.1
Re: [PATCH v4 RESEND] powerpc: Replace kretprobe code with rethook on powerpc
Abhishek Dubey writes:
> This is an adaptation of commit f3a112c0c40d ("x86,rethook,kprobes:
> Replace kretprobe with rethook on x86") to powerpc.
>
> Rethook follows the existing kretprobe implementation, but separates
> it from kprobes so that it can be used by fprobe (ftrace-based
> function entry/exit probes). As such, this patch also enables fprobe
> to work on powerpc. The only other change compared to the existing
> kretprobe implementation is doing the return address fixup in
> arch_rethook_fixup_return().
>
> Reference to other archs:
> commit b57c2f124098 ("riscv: add riscv rethook implementation")
> commit 7b0a096436c2 ("LoongArch: Replace kretprobe with rethook")
>
> Note:
> =
>
> In future, rethook will be only for kretprobe, and kretprobe
> will be replaced by fprobe.
>
> https://lore.kernel.org/all/172000134410.63468.1374887213469474.stgit@devnote2/
>
> We will adapt the above implementation for powerpc once its upstream.
> Until then, we can have this implementation of rethook to serve
> current kretprobe usecases.
>
> Reviewed-by: Naveen Rao
> Signed-off-by: Abhishek Dubey
> ---
Was Masami's objection to v3 resolved?
cheers
Re: [PATCH v3 1/5] mm: Define VM_DROPPABLE for powerpc/32
Christophe Leroy writes:
> Commit 9651fcedf7b9 ("mm: add MAP_DROPPABLE for designating always
> lazily freeable mappings") only adds VM_DROPPABLE for 64 bits
> architectures.
>
> In order to also use the getrandom vDSO implementation on powerpc/32,
> use VM_ARCH_1 for VM_DROPPABLE on powerpc/32. This is possible because
> VM_ARCH_1 is used for VM_SAO on powerpc and VM_SAO is only for
> powerpc/64.
Also, there can't be any existing users of VM_SAO on 32-bit, because PROT_SAO
(which maps to VM_SAO) is only accepted on CPUs that support SAO, and
those CPUs are all 64-bit.
cheers
Re: [PATCH] powerpc: Use printk instead of WARN in change_memory_attr
Christophe Leroy writes:
> Le 27/08/2024 à 11:12, Ritesh Harjani (IBM) a écrit :
>> [Vous ne recevez pas souvent de courriers de ritesh.l...@gmail.com.
>> Découvrez pourquoi ceci est important à
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Use pr_warn_once instead of WARN_ON_ONCE as discussed here [1]
>> for printing possible use of set_memory_* on linear map on Hash.
>>
>> [1]: https://lore.kernel.org/all/877cc2fpi2.fsf@mail.lhotse/#t
>>
>> Signed-off-by: Ritesh Harjani (IBM)
>> ---
>> arch/powerpc/mm/pageattr.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/mm/pageattr.c b/arch/powerpc/mm/pageattr.c
>> index ac22bf28086f..c8c2d664c6f3 100644
>> --- a/arch/powerpc/mm/pageattr.c
>> +++ b/arch/powerpc/mm/pageattr.c
>> @@ -94,8 +94,11 @@ int change_memory_attr(unsigned long addr, int numpages,
>> long action)
>> if (!radix_enabled()) {
>> int region = get_region_id(addr);
>>
>> - if (WARN_ON_ONCE(region != VMALLOC_REGION_ID && region !=
>> IO_REGION_ID))
>> + if (region != VMALLOC_REGION_ID && region != IO_REGION_ID) {
>> + pr_warn_once("%s: possible use of set_memory_* on
>> linear map on Hash from (%ps)\n",
>> + __func__,
>> __builtin_return_address(0));
>
> Is it really only linear map ?
>
> What about "possible user of set_memory_* outside of vmalloc or io region.
Yeah that's more accurate. Can drop "possible" too I think? We're pretty
sure that's what happened.
> Maybe a show_stack() would also be worth it ?
>
>
> But in principle I think it would be better to keep the WARN_ONCE until
> we can add __must_check to set_memory_xxx() functions to be sure all
> callers check the result, as mandated by
> https://github.com/KSPP/linux/issues/7
Will that help in this case though?
If the caller checks the return value they'll see that the call failed,
and presumably error out, possibly breaking boot or something else crucial.
Unless we change change_memory_attr() to return EOPNOTSUPP or something
in this case, and expect callers to handle that.
cheers
Re: [PATCH -next 1/4] powerpc: Remove obsoleted declaration for _get_SP
cuigaosheng writes:
> On 2024/8/22 22:16, LEROY Christophe wrote:
>>
>> Le 22/08/2024 à 15:06, Gaosheng Cui a écrit :
>>> [Vous ne recevez pas souvent de courriers de cuigaoshe...@huawei.com.
>>> Découvrez pourquoi ceci est important à
>>> https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>> The _get_SP() have been removed since
>>> commit 917f0af9e5a9 ("powerpc: Remove arch/ppc and include/asm-ppc"),
>>> and now it is useless, so remove it.
>> Not sure that commit is relevant since it relates to arch/ppc/ not
>> arch/powerpc/
>>
>> For arch/powerpc/ I think it is commit f4db196717c6 ("[POWERPC] Remove
>> _get_SP")
>
> In commit 1da177e4c3f4, linux implemented the _get_SP function in misc.S
> and declared and use it in arch/ppc/kernel/process.c, the declaration
> of _get_SP in arch/powerpc/kernel/process.c was introduced in commit
> 14cf11af6cf608, but at this time arch/powerpc/kernel/misc_32.S has not
> been introduced yet，so I think the declaration belongs to _get_SP in the
> misc.S，it have been removed since commit 917f0af9e5a9.
It's true that in
14cf11af6cf6 ("powerpc: Merge enough to start building in arch/powerpc.")
there was no _get_SP() in arch/powerpc, and the build used the one in
arch/ppc, and so at that point the prototype in
arch/powerpc/kernel/process.c was for the implementation in arch/ppc.
But in commit
e7e2d2da2638 ("powerpc: Don't compile in arch/ppc/kernel for 32-bit
ARCH=powerpc")
we stopped building arch/ppc/kernel as part of the powerpc build.
So from then on the prototype was for the implementation in
arch/powerpc. If we check out e7e2d2da2638 and grep in arch/powerpc for _get_SP:
$ git grep -w _get_SP arch/powerpc/ include/asm-powerpc/
arch/powerpc/kernel/misc_32.S:_GLOBAL(_get_SP)
arch/powerpc/kernel/process.c:extern unsigned long _get_SP(void);
So it was indeed f4db196717c6 ("[POWERPC] Remove _get_SP") that removed
the implementation this prototype was referring to.
I'll update the change log, no need to send a v2.
cheers
Re: [PATCH v2 05/17] vdso: Avoid call to memset() by getrandom
Segher Boessenkool writes: > On Thu, Aug 29, 2024 at 07:36:38PM +0200, Christophe Leroy wrote: >> >> >> Le 28/08/2024 à 19:25, Segher Boessenkool a écrit : >> > >> >>Not sure about static binaries, though: do those even use the VDSO? >> > >> >With "static binary" people usually mean "a binary not using any DSOs", >> >I think the VDSO is a DSO, also in this respect? As always, -static >> >builds are *way* less problematic (and faster and smaller :-) ) >> > >> >> AFAIK on powerpc even static binaries use the vDSO, otherwise signals >> don't work. > > How can that work? Non-dynamic binaries do not use ld.so (that is the > definition of a dynamic binary, even). So they cannot link (at runtime) > to any DSO (unless that is done manually?!) At least for signals I don't think the application needs to know anything about the VDSO. The kernel sets up the return to the signal trampoline (in the VDSO), and as long as userspace returns from its signal handler with blr it will land back on the trampoline. cheers
Re: [PATCH RFC v2 1/4] mm: Add MAP_BELOW_HINT
Charlie Jenkins writes: > Some applications rely on placing data in free bits addresses allocated > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the > address returned by mmap to be less than the 48-bit address space, > unless the hint address uses more than 47 bits (the 48th bit is reserved > for the kernel address space). > > To make this behavior explicit and more versatile across all > architectures, define a mmap flag that allows users to define an > arbitrary upper limit on addresses returned by mmap. > > Signed-off-by: Charlie Jenkins > --- > include/uapi/asm-generic/mman-common.h | 1 + > tools/include/uapi/asm-generic/mman-common.h | 1 + You're not meant to update the headers in tools/ directly. There's a mail somewhere from acme somewhere describing the proper process, but the tldr is leave it up to him. > diff --git a/include/uapi/asm-generic/mman-common.h > b/include/uapi/asm-generic/mman-common.h > index 6ce1f1ceb432..03ac13d9aa37 100644 > --- a/include/uapi/asm-generic/mman-common.h > +++ b/include/uapi/asm-generic/mman-common.h > @@ -32,6 +32,7 @@ > > #define MAP_UNINITIALIZED 0x400 /* For anonymous mmap, memory could be >* uninitialized */ > +#define MAP_BELOW_HINT 0x800 /* give out address that is > below (inclusive) hint address */ IMHO the API would be clearer if this actually forced the address to be below the hint. That's what the flag name implies after all. It would also mean the application doesn't need to take into account the length of the mapping when passing the hint. cheers
Re: [PATCH v3 3/3] powerpc/pseries/dlpar: Add device tree nodes for DLPAR IO add
Haren Myneni writes:
> On Wed, 2024-08-28 at 18:12 +1000, Michael Ellerman wrote:
>> Hi Haren,
>>
>> One query below about the of_node refcounting.
>>
>> Haren Myneni writes:
>> > In the powerpc-pseries specific implementation, the IO hotplug
>> > event is handled in the user space (drmgr tool). For the DLPAR
>> > IO ADD, the corresponding device tree nodes and properties will
>> > be added to the device tree after the device enable. The user
>> > space (drmgr tool) uses configure_connector RTAS call with the
>> > DRC index to retrieve the device nodes and updates the device
>> > tree by writing to /proc/ppc64/ofdt. Under system lockdown,
>> > /dev/mem access to allocate buffers for configure_connector RTAS
>> > call is restricted which means the user space can not issue this
>> > RTAS call and also can not access to /proc/ppc64/ofdt. The
>> > pseries implementation need user interaction to power-on and add
>> > device to the slot during the ADD event handling. So adds
>> > complexity if the complete hotplug ADD event handling moved to
>> > the kernel.
>> >
>> > To overcome /dev/mem access restriction, this patch extends the
>> > /sys/kernel/dlpar interface and provides ‘dt add index ’
>> > to the user space. The drmgr tool uses this interface to update
>> > the device tree whenever the device is added. This interface
>> > retrieves device tree nodes for the corresponding DRC index using
>> > the configure_connector RTAS call and adds new device nodes /
>> > properties to the device tree.
>> >
>> > Signed-off-by: Scott Cheloha
>> > Signed-off-by: Haren Myneni
>> > ---
>> > arch/powerpc/platforms/pseries/dlpar.c | 130
>> > +
>> > 1 file changed, 130 insertions(+)
>> >
>> > diff --git a/arch/powerpc/platforms/pseries/dlpar.c
>> > b/arch/powerpc/platforms/pseries/dlpar.c
>> > index 1b49b47c4a4f..6f0bc3ddbf85 100644
>> > --- a/arch/powerpc/platforms/pseries/dlpar.c
>> > +++ b/arch/powerpc/platforms/pseries/dlpar.c
>> ...
>> > @@ -330,6 +345,118 @@ int dlpar_unisolate_drc(u32 drc_index)
>> >return 0;
>> > }
>> >
>> > +static struct device_node *
>> > +get_device_node_with_drc_index(u32 index)
>> > +{
>> > + struct device_node *np = NULL;
>> > + u32 node_index;
>> > + int rc;
>> > +
>> > + for_each_node_with_property(np, "ibm,my-drc-index") {
>> > + rc = of_property_read_u32(np, "ibm,my-drc-index",
>> > + &node_index);
>> > + if (rc) {
>> > + pr_err("%s: %pOF: of_property_read_u32 %s:
>> > %d\n",
>> > + __func__, np, "ibm,my-drc-index", rc);
>> > + of_node_put(np);
>> > + return NULL;
>> > + }
>> > +
>> > + if (index == node_index)
>> > + break;
>>
>> Here we return with np's refcount elevated.
>>
>> > + }
>> > +
>> > + return np;
>> > +}
>> ...
>> > +
>> > +static int dlpar_hp_dt_add(u32 index)
>> > +{
>> > + struct device_node *np, *nodes;
>> > + struct of_changeset ocs;
>> > + int rc;
>> > +
>> > + /*
>> > + * Do not add device node(s) if already exists in the
>> > + * device tree.
>> > + */
>> > + np = get_device_node_with_drc_index(index);
>> > + if (np) {
>> > + pr_err("%s: Adding device node for index (%d), but "
>> > + "already exists in the device tree\n",
>> > + __func__, index);
>> > + rc = -EINVAL;
>> > + goto out;
>>
>> In the error case you drop the reference on np (at out).
>>
>> > + }
>> > + np = get_device_node_with_drc_info(index);
>> >
>> But in the success case np is reassigned, so the refcount is leaked.
>> I think that's unintentional, but I'm not 100% sure.
>
> Michael,
>
> get_device_node_with_drc_index() holds the refcount only if the node is
> already exists. In this case this refcount is dropped.
>
> if (np) {
> pr_err("%s: Adding device node for index (%d), but "
> "already exists in the device tree\n",
> __func__, index);
> rc = -EINVAL;
> goto out; --> drop refcount
> }
Oh yep. I misread that as if (!np).
> Whereas failure from the get_device_node_with_drc_index() - can not
> find the match node. means we do not hold the refcount and need to add
> the node from get_device_node_with_drc_info()
Right.
> I should add a comment regarding refcount to make it clear. will post
> V4 patch with this comment.
It's probably fine as-is, I just needed to read it properly :)
cheers
Re: [PATCH v3 3/3] powerpc/pseries/dlpar: Add device tree nodes for DLPAR IO add
Hi Haren,
One query below about the of_node refcounting.
Haren Myneni writes:
> In the powerpc-pseries specific implementation, the IO hotplug
> event is handled in the user space (drmgr tool). For the DLPAR
> IO ADD, the corresponding device tree nodes and properties will
> be added to the device tree after the device enable. The user
> space (drmgr tool) uses configure_connector RTAS call with the
> DRC index to retrieve the device nodes and updates the device
> tree by writing to /proc/ppc64/ofdt. Under system lockdown,
> /dev/mem access to allocate buffers for configure_connector RTAS
> call is restricted which means the user space can not issue this
> RTAS call and also can not access to /proc/ppc64/ofdt. The
> pseries implementation need user interaction to power-on and add
> device to the slot during the ADD event handling. So adds
> complexity if the complete hotplug ADD event handling moved to
> the kernel.
>
> To overcome /dev/mem access restriction, this patch extends the
> /sys/kernel/dlpar interface and provides ‘dt add index ’
> to the user space. The drmgr tool uses this interface to update
> the device tree whenever the device is added. This interface
> retrieves device tree nodes for the corresponding DRC index using
> the configure_connector RTAS call and adds new device nodes /
> properties to the device tree.
>
> Signed-off-by: Scott Cheloha
> Signed-off-by: Haren Myneni
> ---
> arch/powerpc/platforms/pseries/dlpar.c | 130 +
> 1 file changed, 130 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/dlpar.c
> b/arch/powerpc/platforms/pseries/dlpar.c
> index 1b49b47c4a4f..6f0bc3ddbf85 100644
> --- a/arch/powerpc/platforms/pseries/dlpar.c
> +++ b/arch/powerpc/platforms/pseries/dlpar.c
...
> @@ -330,6 +345,118 @@ int dlpar_unisolate_drc(u32 drc_index)
> return 0;
> }
>
> +static struct device_node *
> +get_device_node_with_drc_index(u32 index)
> +{
> + struct device_node *np = NULL;
> + u32 node_index;
> + int rc;
> +
> + for_each_node_with_property(np, "ibm,my-drc-index") {
> + rc = of_property_read_u32(np, "ibm,my-drc-index",
> + &node_index);
> + if (rc) {
> + pr_err("%s: %pOF: of_property_read_u32 %s: %d\n",
> +__func__, np, "ibm,my-drc-index", rc);
> + of_node_put(np);
> + return NULL;
> + }
> +
> + if (index == node_index)
> + break;
Here we return with np's refcount elevated.
> + }
> +
> + return np;
> +}
...
> +
> +static int dlpar_hp_dt_add(u32 index)
> +{
> + struct device_node *np, *nodes;
> + struct of_changeset ocs;
> + int rc;
> +
> + /*
> + * Do not add device node(s) if already exists in the
> + * device tree.
> + */
> + np = get_device_node_with_drc_index(index);
> + if (np) {
> + pr_err("%s: Adding device node for index (%d), but "
> + "already exists in the device tree\n",
> + __func__, index);
> + rc = -EINVAL;
> + goto out;
In the error case you drop the reference on np (at out).
> + }
> + np = get_device_node_with_drc_info(index);
>
But in the success case np is reassigned, so the refcount is leaked.
I think that's unintentional, but I'm not 100% sure.
> + if (!np)
> + return -EIO;
> +
> + /* Next, configure the connector. */
> + nodes = dlpar_configure_connector(cpu_to_be32(index), np);
> + if (!nodes) {
> + rc = -EIO;
> + goto out;
> + }
> +
> + /*
> + * Add the new nodes from dlpar_configure_connector() onto
> + * the device-tree.
> + */
> + of_changeset_init(&ocs);
> + rc = dlpar_changeset_attach_cc_nodes(&ocs, nodes);
> +
> + if (!rc)
> + rc = of_changeset_apply(&ocs);
> + else
> + dlpar_free_cc_nodes(nodes);
> +
> + of_changeset_destroy(&ocs);
> +
> +out:
> + of_node_put(np);
> + return rc;
> +}
> +
> static int changeset_detach_node_recursive(struct of_changeset *ocs,
> struct device_node *node)
> {
cheers
Re: [PATCH] powerpc/qspinlock: Fix deadlock in MCS queue
"Nysal Jan K.A." writes:
> If an interrupt occurs in queued_spin_lock_slowpath() after we increment
> qnodesp->count and before node->lock is initialized, another CPU might
> see stale lock values in get_tail_qnode(). If the stale lock value happens
> to match the lock on that CPU, then we write to the "next" pointer of
> the wrong qnode. This causes a deadlock as the former CPU, once it becomes
> the head of the MCS queue, will spin indefinitely until it's "next" pointer
> is set by its successor in the queue. This results in lockups similar to
> the following.
...
>
> Thanks to Saket Kumar Bhaskar for help with recreating the issue
>
> Fixes: 84990b169557 ("powerpc/qspinlock: add mcs queueing for contended
> waiters")
> Cc: sta...@vger.kernel.org # v6.2+
> Reported-by: Geetika Moolchandani
> Reported-by: Vaishnavi Bhat
> Reported-by: Jijo Varghese
Do we have links for any of these reports?
cheers
Re: [PATCH v2] powerpc/mm: Fix return type of pgd_val()
On Thu, 22 Aug 2024 09:58:42 +0200, Christophe Leroy wrote:
> Commit 6b0e82791bd0 ("powerpc/e500: switch to 64 bits PGD on 85xx
> (32 bits)") switched PGD entries to 64 bits, but pgd_val() returns
> an unsigned long which is 32 bits on PPC32. This is not a problem
> for regular PMD entries because the upper part is always NULL, but
> when PMD entries are leaf they contain 64 bits values, so pgd_val()
> must return an unsigned long long instead of an unsigned long.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/mm: Fix return type of pgd_val()
https://git.kernel.org/powerpc/c/3b1f7a46977fe2ff9384d08651a6e0d272ae6a60
cheers
Re: [PATCH] powerpc/vdso: Don't discard rela sections
On Tue, 20 Aug 2024 13:28:07 +0200, Christophe Leroy wrote:
> After building the VDSO, there is a verification that it contains
> no dynamic relocation, see commit aff69273af61 ("vdso: Improve
> cmd_vdso_check to check all dynamic relocations").
>
> This verification uses readelf -r and doesn't work if rela sections
> are discarded.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/vdso: Don't discard rela sections
https://git.kernel.org/powerpc/c/6114139c3bdde992f4a19264e4f9bfc100d8d776
cheers
Re: [PATCH] powerpc/64e: Define mmu_pte_psize static
On Tue, 20 Aug 2024 14:42:38 +0200, Christophe Leroy wrote: > mmu_pte_psize is only used in the tlb_64e.c, define it static. > > Applied to powerpc/fixes. [1/1] powerpc/64e: Define mmu_pte_psize static https://git.kernel.org/powerpc/c/d92b5cc29c792f1d3f0aaa3b29dddfe816c03e88 cheers
Re: [PATCH 1/2] MAINTAINERS: Mark powerpc Cell as orphaned
On Fri, 26 Jul 2024 22:33:21 +1000, Michael Ellerman wrote: > Arnd is no longer actively maintaining Cell, mark it as orphan. > > Also drop the dead developerworks link. > > Applied to powerpc/next. [1/2] MAINTAINERS: Mark powerpc Cell as orphaned https://git.kernel.org/powerpc/c/db9a63913fc7aa6ea419c9a787bfa18937515037 [2/2] MAINTAINERS: Mark powerpc spufs as orphaned https://git.kernel.org/powerpc/c/81695066c76fa74aa00aadbcb360cc7ab9c70c51 cheers
Re: [PATCH v4 0/5] Add generic data patching functions
On Wed, 15 May 2024 12:44:40 +1000, Benjamin Gray wrote: > Currently patch_instruction() bases the write length on the value being > written. If the value looks like a prefixed instruction it writes 8 bytes, > otherwise it writes 4 bytes. This makes it potentially buggy to use for > writing arbitrary data, as if you want to write 4 bytes but it decides to > write 8 bytes it may clobber the following memory or be unaligned and > trigger an oops if it tries to cross a page boundary. > > [...] Applied to powerpc/next. [1/5] powerpc/code-patching: Add generic memory patching https://git.kernel.org/powerpc/c/e6b8940e7e80cdfe98ba8493214922998920dd9c [2/5] powerpc/code-patching: Add data patch alignment check https://git.kernel.org/powerpc/c/dbf828aab466c6534711d1f1454c409ea68d18d0 [3/5] powerpc/64: Convert patch_instruction() to patch_u32() https://git.kernel.org/powerpc/c/90d4fed5b273155c378b1d37595f2209f0a92bed [4/5] powerpc/32: Convert patch_instruction() to patch_uint() https://git.kernel.org/powerpc/c/5799cd765fea93e643d81dbdae76a9c34e06dd18 [5/5] powerpc/code-patching: Add boot selftest for data patching https://git.kernel.org/powerpc/c/b7d47339d00d89af559a7068f4a640fc828177ad cheers
Re: [PATCH] powerpc: Remove LHZX_BE macro
On Wed, 21 Aug 2024 08:47:51 +0200, Christophe Leroy wrote:
> LHZX_BE has been unused since commit dbf44daf7c88 ("bpf, ppc64: remove
> ld_abs/ld_ind")
>
> Remove it.
>
>
Applied to powerpc/next.
[1/1] powerpc: Remove LHZX_BE macro
https://git.kernel.org/powerpc/c/a540ad3e386f8f84bc6d600b93792a50861a81ef
cheers
[PATCH] MAINTAINERS: powerpc: Add Maddy
Maddy will be helping out with upstream maintenance, add him as a reviewer. Signed-off-by: Michael Ellerman --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 878dcd23b331..0ee724dcc05a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12912,6 +12912,7 @@ M: Michael Ellerman R: Nicholas Piggin R: Christophe Leroy R: Naveen N Rao +R: Madhavan Srinivasan L: linuxppc-dev@lists.ozlabs.org S: Supported W: https://github.com/linuxppc/wiki/wiki -- 2.46.0
Re: linux-next: boot warning after merge of the vfs-brauner tree
"Pankaj Raghav (Samsung)" writes:
> On Mon, Aug 26, 2024 at 05:59:31PM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the vfs-brauner tree, today's linux-next boot test (powerpc
>> pseries_le_defconfig) produced this warning:
>
> iomap dio calls set_memory_ro() on the page that is used for sub block
> zeroing.
>
> But looking at powerpc code, they don't support set_memory_ro() for
> memory region that belongs to the kernel(LINEAR_MAP_REGION_ID).
>
> /*
> * On hash, the linear mapping is not in the Linux page table so
> * apply_to_existing_page_range() will have no effect. If in the future
> * the set_memory_* functions are used on the linear map this will need
> * to be updated.
> */
> if (!radix_enabled()) {
> int region = get_region_id(addr);
>
> if (WARN_ON_ONCE(region != VMALLOC_REGION_ID && region !=
> IO_REGION_ID))
> return -EINVAL;
> }
We should probably just turn that into a printk(), WARN is kind of heavy handed.
> We call set_memory_ro() on the zero page as a extra security measure.
Or a data integrity measure. But either way it makes sense.
On architectures that do implement set_memory_ro() it potentially breaks
the linear mapping into small pages, which could have a performance impact.
cheers
Re: [PATCH v2] ata: pata_macio: Use WARN instead of BUG
Sergei Shtylyov writes: > On 8/20/24 6:04 AM, Michael Ellerman wrote: > >> The overflow/underflow conditions in pata_macio_qc_prep() should never >> happen. But if they do there's no need to kill the system entirely, a >> WARN and failing the IO request should be sufficient and might allow the >> system to keep running. > >WARN*() can kill your system with panic_on_warn -- Android is particularly > fond of this kernel parameter but I guess it's not your case... :-) >Greg KH usually advices against using these macros. :-) Yeah, but in this case it's replacing BUG with WARN, so I figure it's clearly an improvement. Also if someone is running with panic_on_warn then they *want* their system to panic if anything strange happens, which is the case here. >> Signed-off-by: Michael Ellerman > [...] > >Please do CC me on the PATA driver patches! This one circumvented my review > (again)... :-/ Oops sorry, I think I just grabbed the Cc's from the report. I'll use get_maintainer.pl in future. cheers
Re: [PATCH] crash: Default to CRASH_DUMP=n when support for it is unlikely
Geert Uytterhoeven writes:
> Hi Dave,
>
> On Fri, Aug 23, 2024 at 2:54 PM Dave Vasilevsky wrote:
>> Fixes boot failures on 6.9 on PPC_BOOK3S_32 machines using
>> Open Firmware. On these machines, the kernel refuses to boot
>> from non-zero PHYSICAL_START, which occurs when CRASH_DUMP is on.
>>
>> Since most PPC_BOOK3S_32 machines boot via Open Firmware, it should
>> default to off for them. Users booting via some other mechanism
>> can still turn it on explicitly.
>>
>> Also defaults to CRASH_DUMP=n on sh.
>>
>> Signed-off-by: Dave Vasilevsky
>> Reported-by: Reimar Döffinger
>> Closes: https://lists.debian.org/debian-powerpc/2024/07/msg1.html
>> Fixes: 75bc255a7444 ("crash: clean up kdump related config items")
>
> Thanks for your patch!
>
>> --- a/kernel/Kconfig.kexec
>> +++ b/kernel/Kconfig.kexec
>> @@ -97,7 +97,7 @@ config KEXEC_JUMP
>>
>> config CRASH_DUMP
>> bool "kernel crash dumps"
>> - default y
>> + default ARCH_DEFAULT_CRASH_DUMP
>> depends on ARCH_SUPPORTS_CRASH_DUMP
>> depends on KEXEC_CORE
>> select VMCORE_INFO
>
> IMHO CRASH_DUMP should just default to n, like most kernel options, as
> it enables non-trivial extra functionality: the kernel source tree has
> more than 100 locations that check if CONFIG_CRASH_DUMP is enabled.
>
> Letting it default to enabled also conflicts with the spirit of the
> help text for the symbol:
>
> Generate crash dump after being started by kexec.
> This should be normally only set in special crash dump kernels
> ^^
> which are loaded in the main kernel with kexec-tools into
> a specially reserved region and then later executed after
> a crash by kdump/kexec. The crash dump kernel must be compiled
> to a memory address not used by the main kernel or BIOS using
> PHYSICAL_START, or it must be built as a relocatable image
> (CONFIG_RELOCATABLE=y).
> For more details see Documentation/admin-guide/kdump/kdump.rst
>
> For s390, this option also enables zfcpdump.
> See also
>
> What is so special about CRASH_DUMP, that it should be enabled by
> default?
The reality is that essentially all distros enable it. Because they
don't want to manage separate kernel / crash-kernel packages.
So IMHO having it enabled by default in upstream does make sense,
because it more closely matches what distros/users actually run.
cheers
[PATCH 1/3] powerpc/64: Remove maple platform
The maple platform was added in 2004 [1], to support the "Maple" 970FX evaluation board. It was later used for IBM JS20/JS21 machines, as well as the Bimini machine, aka "Yellow Dog Powerstation". Sadly all those machines have passed into memory, and there's been no evidence for years that anyone is still using any of them. Remove the platform and related code. It can always be reinstated if there's interest. Note that this has no impact on support for 970FX based Power Macs. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux-fullhistory.git/commit/?id=f0d068d65c5e555ffcfbc189de32598f6f00770c Signed-off-by: Michael Ellerman --- Documentation/arch/powerpc/booting.rst | 4 +- arch/powerpc/Kconfig.debug | 6 - arch/powerpc/boot/.gitignore | 1 - arch/powerpc/boot/Makefile | 3 +- arch/powerpc/boot/wrapper | 7 +- arch/powerpc/configs/maple_defconfig | 111 arch/powerpc/configs/ppc64_defconfig | 1 - arch/powerpc/include/asm/udbg.h| 1 - arch/powerpc/kernel/misc_64.S | 8 +- arch/powerpc/kernel/prom_init.c| 86 arch/powerpc/kernel/udbg.c | 3 - arch/powerpc/kernel/udbg_16550.c | 23 - arch/powerpc/platforms/Kconfig | 1 - arch/powerpc/platforms/Makefile| 1 - arch/powerpc/platforms/maple/Kconfig | 19 - arch/powerpc/platforms/maple/Makefile | 2 - arch/powerpc/platforms/maple/maple.h | 15 - arch/powerpc/platforms/maple/pci.c | 672 - arch/powerpc/platforms/maple/setup.c | 363 - arch/powerpc/platforms/maple/time.c| 170 --- 20 files changed, 8 insertions(+), 1489 deletions(-) delete mode 100644 arch/powerpc/configs/maple_defconfig delete mode 100644 arch/powerpc/platforms/maple/Kconfig delete mode 100644 arch/powerpc/platforms/maple/Makefile delete mode 100644 arch/powerpc/platforms/maple/maple.h delete mode 100644 arch/powerpc/platforms/maple/pci.c delete mode 100644 arch/powerpc/platforms/maple/setup.c delete mode 100644 arch/powerpc/platforms/maple/time.c diff --git a/Documentation/arch/powerpc/booting.rst b/Documentation/arch/powerpc/booting.rst index 11aa440f98cc..472e97891aef 100644 --- a/Documentation/arch/powerpc/booting.rst +++ b/Documentation/arch/powerpc/booting.rst @@ -93,8 +93,8 @@ given platform based on the content of the device-tree. Thus, you should: a) add your platform support as a _boolean_ option in -arch/powerpc/Kconfig, following the example of PPC_PSERIES, -PPC_PMAC and PPC_MAPLE. The latter is probably a good +arch/powerpc/Kconfig, following the example of PPC_PSERIES +and PPC_PMAC. The latter is probably a good example of a board support to start from. b) create your main platform file as diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug index 3799ceceb04a..67581b597954 100644 --- a/arch/powerpc/Kconfig.debug +++ b/arch/powerpc/Kconfig.debug @@ -223,12 +223,6 @@ config PPC_EARLY_DEBUG_RTAS_CONSOLE help Select this to enable early debugging via the RTAS console. -config PPC_EARLY_DEBUG_MAPLE - bool "Maple real mode" - depends on PPC_MAPLE - help - Select this to enable early debugging for Maple. - config PPC_EARLY_DEBUG_PAS_REALMODE bool "PA Semi real mode" depends on PPC_PASEMI diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore index a4716d138cfc..5a867f23fe7f 100644 --- a/arch/powerpc/boot/.gitignore +++ b/arch/powerpc/boot/.gitignore @@ -30,7 +30,6 @@ zImage.coff zImage.epapr zImage.holly zImage.*lds -zImage.maple zImage.miboot zImage.pmac zImage.pseries diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index fa8518067d38..1ff6ad4f6cd2 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -276,7 +276,6 @@ quiet_cmd_wrap = WRAP$@ image-$(CONFIG_PPC_PSERIES)+= zImage.pseries image-$(CONFIG_PPC_POWERNV)+= zImage.pseries -image-$(CONFIG_PPC_MAPLE) += zImage.maple image-$(CONFIG_PPC_IBM_CELL_BLADE) += zImage.pseries image-$(CONFIG_PPC_PS3)+= dtbImage.ps3 image-$(CONFIG_PPC_CHRP) += zImage.chrp @@ -444,7 +443,7 @@ $(obj)/zImage.initrd: $(addprefix $(obj)/, $(initrd-y)) clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \ zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \ zImage.miboot zImage.pmac zImage.pseries \ - zImage.maple simpleImage.* otheros.bld + simpleImage.* otheros.bld # clean up files cached by wrapper clean-kernel-base := vmlinux.strip vmlinux.bin diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper index b1f5549a3c9c..1db60fe13802 100755 --- a/arch/powerpc/boot/wrapper +++ b/arch/powerpc/boot/wrapper @@ -2
[PATCH 3/3] EDAC/powerpc: Remove "maple" drivers
These two drivers are only buildable for the powerpc "maple" platform,
which has now been removed. Remove the drivers.
Signed-off-by: Michael Ellerman
---
drivers/edac/Kconfig| 18 --
drivers/edac/Makefile | 2 -
drivers/edac/amd8111_edac.c | 596
drivers/edac/amd8111_edac.h | 118 ---
drivers/edac/amd8131_edac.c | 358 --
drivers/edac/amd8131_edac.h | 107 ---
6 files changed, 1199 deletions(-)
delete mode 100644 drivers/edac/amd8111_edac.c
delete mode 100644 drivers/edac/amd8111_edac.h
delete mode 100644 drivers/edac/amd8131_edac.c
delete mode 100644 drivers/edac/amd8131_edac.h
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 16c8de5050e5..39a8f135c00e 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -320,24 +320,6 @@ config EDAC_PPC4XX
PowerPC 4xx embedded processors such as the 405EX[r],
440SP, 440SPe, 460EX, 460GT and 460SX.
-config EDAC_AMD8131
- tristate "AMD8131 HyperTransport PCI-X Tunnel"
- depends on PCI && PPC_MAPLE
- help
- Support for error detection and correction on the
- AMD8131 HyperTransport PCI-X Tunnel chip.
- Note, add more Kconfig dependency if it's adopted
- on some machine other than Maple.
-
-config EDAC_AMD8111
- tristate "AMD8111 HyperTransport I/O Hub"
- depends on PCI && PPC_MAPLE
- help
- Support for error detection and correction on the
- AMD8111 HyperTransport I/O Hub chip.
- Note, add more Kconfig dependency if it's adopted
- on some machine other than Maple.
-
config EDAC_CPC925
tristate "IBM CPC925 Memory Controller (PPC970FX)"
depends on PPC64
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 4edfb83ffbee..16397d397908 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -64,8 +64,6 @@ obj-$(CONFIG_EDAC_I10NM) += i10nm_edac.o
skx_edac_common.o
obj-$(CONFIG_EDAC_CELL)+= cell_edac.o
obj-$(CONFIG_EDAC_PPC4XX) += ppc4xx_edac.o
-obj-$(CONFIG_EDAC_AMD8111) += amd8111_edac.o
-obj-$(CONFIG_EDAC_AMD8131) += amd8131_edac.o
obj-$(CONFIG_EDAC_HIGHBANK_MC) += highbank_mc_edac.o
obj-$(CONFIG_EDAC_HIGHBANK_L2) += highbank_l2_edac.o
diff --git a/drivers/edac/amd8111_edac.c b/drivers/edac/amd8111_edac.c
deleted file mode 100644
index a6d3013d5823..
--- a/drivers/edac/amd8111_edac.c
+++ /dev/null
@@ -1,596 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * amd8111_edac.c, AMD8111 Hyper Transport chip EDAC kernel module
- *
- * Copyright (c) 2008 Wind River Systems, Inc.
- *
- * Authors:Cao Qingtao
- * Benjamin Walsh
- * Hu Yongqi
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "edac_module.h"
-#include "amd8111_edac.h"
-
-#define AMD8111_EDAC_REVISION " Ver: 1.0.0"
-#define AMD8111_EDAC_MOD_STR "amd8111_edac"
-
-#define PCI_DEVICE_ID_AMD_8111_PCI 0x7460
-
-enum amd8111_edac_devs {
- LPC_BRIDGE = 0,
-};
-
-enum amd8111_edac_pcis {
- PCI_BRIDGE = 0,
-};
-
-/* Wrapper functions for accessing PCI configuration space */
-static int edac_pci_read_dword(struct pci_dev *dev, int reg, u32 *val32)
-{
- int ret;
-
- ret = pci_read_config_dword(dev, reg, val32);
- if (ret != 0)
- printk(KERN_ERR AMD8111_EDAC_MOD_STR
- " PCI Access Read Error at 0x%x\n", reg);
-
- return ret;
-}
-
-static void edac_pci_read_byte(struct pci_dev *dev, int reg, u8 *val8)
-{
- int ret;
-
- ret = pci_read_config_byte(dev, reg, val8);
- if (ret != 0)
- printk(KERN_ERR AMD8111_EDAC_MOD_STR
- " PCI Access Read Error at 0x%x\n", reg);
-}
-
-static void edac_pci_write_dword(struct pci_dev *dev, int reg, u32 val32)
-{
- int ret;
-
- ret = pci_write_config_dword(dev, reg, val32);
- if (ret != 0)
- printk(KERN_ERR AMD8111_EDAC_MOD_STR
- " PCI Access Write Error at 0x%x\n", reg);
-}
-
-static void edac_pci_write_byte(struct pci_dev *dev, int reg, u8 val8)
-{
- int ret;
-
- ret = pci_write_config_byte(dev, reg, val8);
- if (ret != 0)
- printk(KERN_ERR AMD8111_EDAC_MOD_STR
- " PCI Access Write Error at 0x%x\n", reg);
-}
-
-/*
- * device-specific methods for amd8111 PCI Bridge Controller
- *
- * Error Reporting and Handling for amd8111 chipset could be found
- * in its datasheet 3.1.2 section, P37
- */
-static void amd8111_pci_bridge_init(struct amd8111_pci_info *pci_info)
-{
- u32 val32;
- struct pci_dev *dev = pci_info->dev;
-
- /* First clea
[PATCH 2/3] cpufreq: maple: Remove maple driver
This driver is no longer buildable since the PPC_MAPLE platform was
removed. Remove the driver.
Note that the comment in the driver says it supports "SMU & 970FX
based G5 Macs", but that's not true, that comment was copied from
pmac64-cpufreq.c, which still exists and continues to support those
machines.
Signed-off-by: Michael Ellerman
---
drivers/cpufreq/Kconfig.powerpc | 7 -
drivers/cpufreq/Makefile| 1 -
drivers/cpufreq/maple-cpufreq.c | 241
3 files changed, 249 deletions(-)
delete mode 100644 drivers/cpufreq/maple-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.powerpc b/drivers/cpufreq/Kconfig.powerpc
index 58151ca56695..eb678fa5260a 100644
--- a/drivers/cpufreq/Kconfig.powerpc
+++ b/drivers/cpufreq/Kconfig.powerpc
@@ -17,13 +17,6 @@ config CPU_FREQ_CBE_PMI
frequencies. Using PMI, the processor will not only be able to run at
lower speed, but also at lower core voltage.
-config CPU_FREQ_MAPLE
- bool "Support for Maple 970FX Evaluation Board"
- depends on PPC_MAPLE
- help
- This adds support for frequency switching on Maple 970FX
- Evaluation Board and compatible boards (IBM JS2x blades).
-
config CPU_FREQ_PMAC
bool "Support for Apple PowerBooks"
depends on ADB_PMU && PPC32
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 0f184031dd12..1a8f787db7e2 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -92,7 +92,6 @@ obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ)+=
vexpress-spc-cpufreq.o
obj-$(CONFIG_CPU_FREQ_CBE) += ppc-cbe-cpufreq.o
ppc-cbe-cpufreq-y += ppc_cbe_cpufreq_pervasive.o
ppc_cbe_cpufreq.o
obj-$(CONFIG_CPU_FREQ_CBE_PMI) += ppc_cbe_cpufreq_pmi.o
-obj-$(CONFIG_CPU_FREQ_MAPLE) += maple-cpufreq.o
obj-$(CONFIG_QORIQ_CPUFREQ)+= qoriq-cpufreq.o
obj-$(CONFIG_CPU_FREQ_PMAC)+= pmac32-cpufreq.o
obj-$(CONFIG_CPU_FREQ_PMAC64) += pmac64-cpufreq.o
diff --git a/drivers/cpufreq/maple-cpufreq.c b/drivers/cpufreq/maple-cpufreq.c
deleted file mode 100644
index f9306410a07f..
--- a/drivers/cpufreq/maple-cpufreq.c
+++ /dev/null
@@ -1,241 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2011 Dmitry Eremin-Solenikov
- * Copyright (C) 2002 - 2005 Benjamin Herrenschmidt
- * and Markus Demleitner
- *
- * This driver adds basic cpufreq support for SMU & 970FX based G5 Macs,
- * that is iMac G5 and latest single CPU desktop.
- */
-
-#undef DEBUG
-
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#define DBG(fmt...) pr_debug(fmt)
-
-/* see 970FX user manual */
-
-#define SCOM_PCR 0x0aa001 /* PCR scom addr */
-
-#define PCR_HILO_SELECT0x8000U /* 1 = PCR, 0 = PCRH */
-#define PCR_SPEED_FULL 0xU /* 1:1 speed value */
-#define PCR_SPEED_HALF 0x0002U /* 1:2 speed value */
-#define PCR_SPEED_QUARTER 0x0004U /* 1:4 speed value */
-#define PCR_SPEED_MASK 0x000eU /* speed mask */
-#define PCR_SPEED_SHIFT17
-#define PCR_FREQ_REQ_VALID 0x0001U /* freq request valid */
-#define PCR_VOLT_REQ_VALID 0x8000U /* volt request valid */
-#define PCR_TARGET_TIME_MASK 0x6000U /* target time */
-#define PCR_STATLAT_MASK 0x1f00U /* STATLAT value */
-#define PCR_SNOOPLAT_MASK 0x00f0U /* SNOOPLAT value */
-#define PCR_SNOOPACC_MASK 0x000fU /* SNOOPACC value */
-
-#define SCOM_PSR 0x408001 /* PSR scom addr */
-/* warning: PSR is a 64 bits register */
-#define PSR_CMD_RECEIVED 0x2000U /* command received */
-#define PSR_CMD_COMPLETED 0x1000U /* command completed */
-#define PSR_CUR_SPEED_MASK 0x0300U /* current speed */
-#define PSR_CUR_SPEED_SHIFT(56)
-
-/*
- * The G5 only supports two frequencies (Quarter speed is not supported)
- */
-#define CPUFREQ_HIGH 0
-#define CPUFREQ_LOW 1
-
-static struct cpufreq_frequency_table maple_cpu_freqs[] = {
- {0, CPUFREQ_HIGH, 0},
- {0, CPUFREQ_LOW,0},
- {0, 0, CPUFREQ_TABLE_END},
-};
-
-/* Power mode data is an array of the 32 bits PCR values to use for
- * the various frequencies, retrieved from the device-tree
- */
-static int maple_pmode_cur;
-
-static const u32 *maple_pmode_data;
-static int maple_pmode_max;
-
-/*
- * SCOM based frequency switching for 970FX rev3
- */
-static int maple_scom_switch_freq(int speed_mode)
-{
- unsigned long flags;
- int to;
-
- local_irq_save(flags);
-
- /* Clear PCR
[PATCH] powerpc/64s: Remove the "fast endian switch" syscall
The non-standard "fast endian switch" syscall was added in 2008[1],
but was never widely used. It was disabled by default in 2017[2], and
there's no evidence it's ever been used since.
Remove it entirely.
A normal endian switch syscall was added in 2015[3].
[1]: 745a14cc264b ("[POWERPC] Add fast little-endian switch system call")
[2]: 529d235a0e19 ("powerpc: Add a proper syscall for switching endianness")
[3]: 727f13616c45 ("powerpc: Disable the fast-endian switch syscall by default")
Signed-off-by: Michael Ellerman
---
arch/powerpc/Kconfig.debug | 6 --
arch/powerpc/kernel/exceptions-64s.S | 17 -
2 files changed, 23 deletions(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 3799ceceb04a..0bbec4afc0d5 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -379,12 +379,6 @@ config FAIL_IOMMU
If you are unsure, say N.
-config PPC_FAST_ENDIAN_SWITCH
- bool "Deprecated fast endian-switch syscall"
- depends on DEBUG_KERNEL && PPC_BOOK3S_64
- help
- If you're unsure what this is, say N.
-
config KASAN_SHADOW_OFFSET
hex
depends on KASAN
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S
index eaf2f167c342..195b075d116c 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1989,13 +1989,6 @@ INT_DEFINE_END(system_call)
INTERRUPT_TO_KERNEL
#endif
-#ifdef CONFIG_PPC_FAST_ENDIAN_SWITCH
-BEGIN_FTR_SECTION
- cmpdi r0,0x1ebe
- beq-1f
-END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE)
-#endif
-
/* We reach here with PACA in r13, r13 in r9. */
mfspr r11,SPRN_SRR0
mfspr r12,SPRN_SRR1
@@ -2015,16 +2008,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE)
b system_call_common
#endif
.endif
-
-#ifdef CONFIG_PPC_FAST_ENDIAN_SWITCH
- /* Fast LE/BE switch system call */
-1: mfspr r12,SPRN_SRR1
- xorir12,r12,MSR_LE
- mtspr SPRN_SRR1,r12
- mr r13,r9
- RFI_TO_USER /* return to userspace */
- b . /* prevent speculative execution */
-#endif
.endm
EXC_REAL_BEGIN(system_call, 0xc00, 0x100)
--
2.46.0
[PATCH 1/2] powerpc/mm/64s: Move THP reqs into a separate symbol
Move the Kconfig symbols related to transparent hugepages (THP) under a separate config symbol, separate from CONFIG_PPC_BOOK3S_64. The new symbol is automatically enabled if CONFIG_PPC_BOOK3S_64 is enabled, so there is no behaviour change, except for the existence of the new PPC_THP symbol. Signed-off-by: Michael Ellerman --- arch/powerpc/platforms/Kconfig.cputype | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index 4b0d7d4f88f6..9536e591c72a 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -84,11 +84,8 @@ config PPC_BOOK3S_64 bool "Server processors" select PPC_FPU select PPC_HAVE_PMU_SUPPORT - select HAVE_ARCH_TRANSPARENT_HUGEPAGE - select HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION select ARCH_ENABLE_SPLIT_PMD_PTLOCK - select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE select ARCH_SUPPORTS_HUGETLBFS select ARCH_SUPPORTS_NUMA_BALANCING select HAVE_MOVE_PMD @@ -108,6 +105,13 @@ config PPC_BOOK3E_64 endchoice +config PPC_THP + def_bool y + depends on PPC_BOOK3S_64 + select HAVE_ARCH_TRANSPARENT_HUGEPAGE + select HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD + select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE + choice prompt "CPU selection" help -- 2.46.0
[PATCH 2/2] powerpc/mm/64s: Restrict THP to Radix or HPT w/64K pages
Transparent hugepages (THP) are not supported when using the Hash Page Table (HPT) MMU with 4K pages. Currently a HPT-only 4K kernel still allows THP to be enabled, which is misleading. Add restrictions to the PPC_THP symbol so that if the kernel is configured with 4K pages and only the HPT MMU (no Radix), then THP is disabled. Note that it's still possible to build a combined Radix/HPT kernel with 4K pages, which does allow THP to be enabled at build time. As such the HPT code still needs to provide some THP related symbols, to allow the build to succeed, but those code paths are never run. See the stubs in arch/powerpc/include/asm/book3s/64/hash-4k.h. Signed-off-by: Michael Ellerman --- arch/powerpc/platforms/Kconfig.cputype | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index 9536e591c72a..1453ccc900c4 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -108,6 +108,7 @@ endchoice config PPC_THP def_bool y depends on PPC_BOOK3S_64 + depends on PPC_RADIX_MMU || (PPC_64S_HASH_MMU && PAGE_SIZE_64KB) select HAVE_ARCH_TRANSPARENT_HUGEPAGE select HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE -- 2.46.0
Re: [PATCH] powerpc/pseries: Use correct data types from pseries_hp_errorlog struct
Haren Myneni writes: > _be32 type is defined for some elements in pseries_hp_errorlog > struct but also used them u32 after be32_to_cpu() conversion. > > Example: In handle_dlpar_errorlog() > hp_elog->_drc_u.drc_index = be32_to_cpu(hp_elog->_drc_u.drc_index); > > And later assigned to u32 type > dlpar_cpu() - u32 drc_index = hp_elog->_drc_u.drc_index; > > This incorrect usage is giving the following warnings and the > patch resolve these warnings with the correct assignment. > > arch/powerpc/platforms/pseries/dlpar.c:398:53: sparse: sparse: > incorrect type in argument 1 (different base types) @@ > expected unsigned int [usertype] drc_index @@ > got restricted __be32 [usertype] drc_index @@ > ... > arch/powerpc/platforms/pseries/dlpar.c:418:43: sparse: sparse: > incorrect type in assignment (different base types) @@ > expected restricted __be32 [usertype] drc_count @@ > got unsigned int [usertype] @@ > > Reported-by: kernel test robot > Closes: > https://lore.kernel.org/oe-kbuild-all/202408182142.wuikqyae-...@intel.com/ > Closes: > https://lore.kernel.org/oe-kbuild-all/202408182302.o7qro45s-...@intel.com/ > Signed-off-by: Haren Myneni Thanks for fixing these. I'd prefer it if you could rebase this to go at the start of your DLPAR IO series, ie. fix the existing errors first, and then add your series on top of that. cheers
[PATCH] macintosh/via-pmu: register_pmu_pm_ops() can be __init
register_pmu_pm_ops() is only called at init time, via
device_initcall(), so can be marked __init. The driver can't be built as
a module.
Signed-off-by: Michael Ellerman
---
drivers/macintosh/via-pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 7b7808281292..2f131ab9bb15 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -2334,7 +2334,7 @@ static const struct platform_suspend_ops pmu_pm_ops = {
.valid = pmu_sleep_valid,
};
-static int register_pmu_pm_ops(void)
+static int __init register_pmu_pm_ops(void)
{
if (pmu_kind == PMU_OHARE_BASED)
powerbook_sleep_init_3400();
--
2.46.0
[PATCH] powerpc/64s: Make mmu_hash_ops __ro_after_init
The mmu_hash_ops are only assigned to during boot, so mark them __ro_after_init to prevent any further modification. Signed-off-by: Michael Ellerman --- arch/powerpc/mm/book3s64/hash_utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/mm/book3s64/hash_utils.c b/arch/powerpc/mm/book3s64/hash_utils.c index 01c3b4b65241..845fb7ef0ad3 100644 --- a/arch/powerpc/mm/book3s64/hash_utils.c +++ b/arch/powerpc/mm/book3s64/hash_utils.c @@ -125,7 +125,7 @@ int mmu_ci_restrictions; #endif static u8 *linear_map_hash_slots; static unsigned long linear_map_hash_count; -struct mmu_hash_ops mmu_hash_ops; +struct mmu_hash_ops mmu_hash_ops __ro_after_init; EXPORT_SYMBOL(mmu_hash_ops); /* -- 2.46.0
[PATCH] powerpc/64s/mm: Move __real_pte stubs into hash-4k.h
The stub versions of __real_pte() etc are only used with HPT & 4K pages,
so move them into the hash-4k.h header.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/book3s/64/hash-4k.h | 20 +++
arch/powerpc/include/asm/book3s/64/pgtable.h | 26
2 files changed, 20 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/hash-4k.h
b/arch/powerpc/include/asm/book3s/64/hash-4k.h
index 6472b08fa1b0..57ebbacf1709 100644
--- a/arch/powerpc/include/asm/book3s/64/hash-4k.h
+++ b/arch/powerpc/include/asm/book3s/64/hash-4k.h
@@ -89,6 +89,26 @@ static inline int hash__hugepd_ok(hugepd_t hpd)
}
#endif
+/*
+ * With 4K page size the real_pte machinery is all nops.
+ */
+#define __real_pte(e, p, o)((real_pte_t){(e)})
+#define __rpte_to_pte(r) ((r).pte)
+#define __rpte_to_hidx(r,index)(pte_val(__rpte_to_pte(r)) >>
H_PAGE_F_GIX_SHIFT)
+
+#define pte_iterate_hashed_subpages(rpte, psize, va, index, shift) \
+ do { \
+ index = 0; \
+ shift = mmu_psize_defs[psize].shift; \
+
+#define pte_iterate_hashed_end() } while(0)
+
+/*
+ * We expect this to be called only for user addresses or kernel virtual
+ * addresses other than the linear mapping.
+ */
+#define pte_pagesize_index(mm, addr, pte) MMU_PAGE_4K
+
/*
* 4K PTE format is different from 64K PTE format. Saving the hash_slot is just
* a matter of returning the PTE bits that need to be modified. On 64K PTE,
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 8f9432e3855a..014632161edb 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -314,32 +314,6 @@ static inline bool pud_leaf(pud_t pud)
#ifndef __ASSEMBLY__
-/*
- * This is the default implementation of various PTE accessors, it's
- * used in all cases except Book3S with 64K pages where we have a
- * concept of sub-pages
- */
-#ifndef __real_pte
-
-#define __real_pte(e, p, o)((real_pte_t){(e)})
-#define __rpte_to_pte(r) ((r).pte)
-#define __rpte_to_hidx(r,index)(pte_val(__rpte_to_pte(r)) >>
H_PAGE_F_GIX_SHIFT)
-
-#define pte_iterate_hashed_subpages(rpte, psize, va, index, shift) \
- do { \
- index = 0; \
- shift = mmu_psize_defs[psize].shift; \
-
-#define pte_iterate_hashed_end() } while(0)
-
-/*
- * We expect this to be called only for user addresses or kernel virtual
- * addresses other than the linear mapping.
- */
-#define pte_pagesize_index(mm, addr, pte) MMU_PAGE_4K
-
-#endif /* __real_pte */
-
static inline unsigned long pte_update(struct mm_struct *mm, unsigned long
addr,
pte_t *ptep, unsigned long clr,
unsigned long set, int huge)
--
2.46.0
[PATCH] powerpc/configs/64s: Enable DEFERRED_STRUCT_PAGE_INIT
It can speed up initialisation of page structs at boot on large machines. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 544a65fda77b..6001d580c0dd 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -93,6 +93,7 @@ CONFIG_MEMORY_HOTREMOVE=y CONFIG_KSM=y CONFIG_TRANSPARENT_HUGEPAGE=y CONFIG_MEM_SOFT_DIRTY=y +CONFIG_DEFERRED_STRUCT_PAGE_INIT=y CONFIG_ZONE_DEVICE=y CONFIG_NET=y CONFIG_PACKET=y -- 2.46.0
Re: [PATCH v2 1/4] mm: Add optional close() to struct vm_special_mapping
Linus Torvalds writes:
> On Mon, 19 Aug 2024 at 13:15, Linus Torvalds
> wrote:
>>
>> Ok, I did a quick hack-job to remove that disgusting
>> install_special_mapping() legacy case.
>>
>> With this [..]
>
> I forgot to actually attach that "this". Here it is. For real, this time.
>
>Linus
> arch/csky/kernel/vdso.c| 28 +---
> arch/hexagon/kernel/vdso.c | 14 ++
> arch/nios2/mm/init.c | 12
> arch/sh/kernel/vsyscall/vsyscall.c | 14 +++---
> arch/x86/um/vdso/vma.c | 12
> include/linux/mm.h | 4
> mm/mmap.c | 32 +---
> 7 files changed, 63 insertions(+), 53 deletions(-)
>
...
> index 1bd85a6949c4..5e68ab7a8898 100644
> --- a/arch/sh/kernel/vsyscall/vsyscall.c
> +++ b/arch/sh/kernel/vsyscall/vsyscall.c
> @@ -36,6 +36,10 @@ __setup("vdso=", vdso_setup);
> */
> extern const char vsyscall_trapa_start, vsyscall_trapa_end;
> static struct page *syscall_pages[1];
> +static struct vm_special_mapping vdso_mapping = {
> + .name = "[vdso]",
> + .pages = syscall_pages;
^
should be ,
> +};
cheers
[PATCH v2] ata: pata_macio: Use WARN instead of BUG
The overflow/underflow conditions in pata_macio_qc_prep() should never
happen. But if they do there's no need to kill the system entirely, a
WARN and failing the IO request should be sufficient and might allow the
system to keep running.
Signed-off-by: Michael Ellerman
---
drivers/ata/pata_macio.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
v2: Use AC_ERR_SYSTEM as suggested by Damien.
diff --git a/drivers/ata/pata_macio.c b/drivers/ata/pata_macio.c
index 1cb8d24b088f..f2f36e55a1f4 100644
--- a/drivers/ata/pata_macio.c
+++ b/drivers/ata/pata_macio.c
@@ -554,7 +554,8 @@ static enum ata_completion_errors pata_macio_qc_prep(struct
ata_queued_cmd *qc)
while (sg_len) {
/* table overflow should never happen */
- BUG_ON (pi++ >= MAX_DCMDS);
+ if (WARN_ON_ONCE(pi >= MAX_DCMDS))
+ return AC_ERR_SYSTEM;
len = (sg_len < MAX_DBDMA_SEG) ? sg_len : MAX_DBDMA_SEG;
table->command = cpu_to_le16(write ? OUTPUT_MORE:
INPUT_MORE);
@@ -566,11 +567,13 @@ static enum ata_completion_errors
pata_macio_qc_prep(struct ata_queued_cmd *qc)
addr += len;
sg_len -= len;
++table;
+ ++pi;
}
}
/* Should never happen according to Tejun */
- BUG_ON(!pi);
+ if (WARN_ON_ONCE(!pi))
+ return AC_ERR_SYSTEM;
/* Convert the last command to an input/output */
table--;
--
2.46.0
[PATCH v2] ata: pata_macio: Fix DMA table overflow
Kolbjørn and Jonáš reported that their 32-bit PowerMacs were crashing
in pata-macio since commit 09fe2bfa6b83 ("ata: pata_macio: Fix
max_segment_size with PAGE_SIZE == 64K").
For example:
kernel BUG at drivers/ata/pata_macio.c:544!
Oops: Exception in kernel mode, sig: 5 [#1]
BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 DEBUG_PAGEALLOC PowerMac
...
NIP pata_macio_qc_prep+0xf4/0x190
LR pata_macio_qc_prep+0xfc/0x190
Call Trace:
0xc1421660 (unreliable)
ata_qc_issue+0x14c/0x2d4
__ata_scsi_queuecmd+0x200/0x53c
ata_scsi_queuecmd+0x50/0xe0
scsi_queue_rq+0x788/0xb1c
__blk_mq_issue_directly+0x58/0xf4
blk_mq_plug_issue_direct+0x8c/0x1b4
blk_mq_flush_plug_list.part.0+0x584/0x5e0
__blk_flush_plug+0xf8/0x194
__submit_bio+0x1b8/0x2e0
submit_bio_noacct_nocheck+0x230/0x304
btrfs_work_helper+0x200/0x338
process_one_work+0x1a8/0x338
worker_thread+0x364/0x4c0
kthread+0x100/0x104
start_kernel_thread+0x10/0x14
That commit increased max_segment_size to 64KB, with the justification
that the SCSI core was already using that size when PAGE_SIZE == 64KB,
and that there was existing logic to split over-sized requests.
However with a sufficiently large request, the splitting logic causes
each sg to be split into two commands in the DMA table, leading to
overflow of the DMA table, triggering the BUG_ON().
With default settings the bug doesn't trigger, because the request size
is limited by max_sectors_kb == 1280, however max_sectors_kb can be
increased, and apparently some distros do that by default using udev
rules.
Fix the bug for 4KB kernels by reverting to the old max_segment_size.
For 64KB kernels the sg_tablesize needs to be halved, to allow for the
possibility that each sg will be split into two.
Fixes: 09fe2bfa6b83 ("ata: pata_macio: Fix max_segment_size with PAGE_SIZE ==
64K")
Cc: sta...@vger.kernel.org # v6.10+
Reported-by: Kolbjørn Barmen
Closes:
https://lore.kernel.org/all/62d248bb-e97a-25d2-bcf2-9160c518c...@kolla.no/
Reported-by: Jonáš Vidra
Closes:
https://lore.kernel.org/all/3b6441b8-06e6-45da-9e55-f92f2c869...@ufal.mff.cuni.cz/
Tested-by: Kolbjørn Barmen
Signed-off-by: Michael Ellerman
---
drivers/ata/pata_macio.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
v2: Namespace the defines as requested by Damien.
Tab align the defines.
diff --git a/drivers/ata/pata_macio.c b/drivers/ata/pata_macio.c
index 1b85e8bf4ef9..1cb8d24b088f 100644
--- a/drivers/ata/pata_macio.c
+++ b/drivers/ata/pata_macio.c
@@ -208,6 +208,19 @@ static const char* macio_ata_names[] = {
/* Don't let a DMA segment go all the way to 64K */
#define MAX_DBDMA_SEG 0xff00
+#ifdef CONFIG_PAGE_SIZE_64KB
+/*
+ * The SCSI core requires the segment size to cover at least a page, so
+ * for 64K page size kernels it must be at least 64K. However the
+ * hardware can't handle 64K, so pata_macio_qc_prep() will split large
+ * requests. To handle the split requests the tablesize must be halved.
+ */
+#define PATA_MACIO_MAX_SEGMENT_SIZESZ_64K
+#define PATA_MACIO_SG_TABLESIZE(MAX_DCMDS / 2)
+#else
+#define PATA_MACIO_MAX_SEGMENT_SIZEMAX_DBDMA_SEG
+#define PATA_MACIO_SG_TABLESIZEMAX_DCMDS
+#endif
/*
* Wait 1s for disk to answer on IDE bus after a hard reset
@@ -912,16 +925,10 @@ static int pata_macio_do_resume(struct pata_macio_priv
*priv)
static const struct scsi_host_template pata_macio_sht = {
__ATA_BASE_SHT(DRV_NAME),
- .sg_tablesize = MAX_DCMDS,
+ .sg_tablesize = PATA_MACIO_SG_TABLESIZE,
/* We may not need that strict one */
.dma_boundary = ATA_DMA_BOUNDARY,
- /*
-* The SCSI core requires the segment size to cover at least a page, so
-* for 64K page size kernels this must be at least 64K. However the
-* hardware can't handle 64K, so pata_macio_qc_prep() will split large
-* requests.
-*/
- .max_segment_size = SZ_64K,
+ .max_segment_size = PATA_MACIO_MAX_SEGMENT_SIZE,
.device_configure = pata_macio_device_configure,
.sdev_groups= ata_common_sdev_groups,
.can_queue = ATA_DEF_QUEUE,
--
2.46.0
Re: [PATCH v3 14/16] modules: Support extended MODVERSIONS info
Matthew Maurer writes: > On Fri, Aug 16, 2024 at 4:04 PM Michael Ellerman wrote: >> Matthew Maurer writes: >> > Adds a new format for MODVERSIONS which stores each field in a separate >> > ELF section. This initially adds support for variable length names, but >> > could later be used to add additional fields to MODVERSIONS in a >> > backwards compatible way if needed. Any new fields will be ignored by >> > old user tooling, unlike the current format where user tooling cannot >> > tolerate adjustments to the format (for example making the name field >> > longer). >> > >> > Since PPC munges its version records to strip leading dots, we reproduce >> > the munging for the new format. >> >> AFAICS the existing code only strips a single leading dot, not all >> leading dots? > > You appear to be correct, I'll update that in the next version, but > want to wait for more feedback on the rest of the patchset before > sending up another full series. Yep, no worries. cheers
