Re: [PATCH] powerpc: Disable CPU unknown by CLANG when CC_IS_CLANG
On Thu, 2 Feb 2023 12:01:04 +0100, Christophe Leroy wrote: > CLANG only knows the following CPUs: > > generic, 440, 450, 601, 602, 603, 603e, 603ev, 604, 604e, 620, 630, > g3, 7400, g4, 7450, g4+, 750, 8548, 970, g5, a2, e500, e500mc, e5500, > power3, pwr3, power4, pwr4, power5, pwr5, power5x, pwr5x, power6, > pwr6, power6x, pwr6x, power7, pwr7, power8, pwr8, power9, pwr9, > power10, pwr10, powerpc, ppc, ppc32, powerpc64, ppc64, powerpc64le, > ppc64le, futur > > [...] Applied to powerpc/next. [1/1] powerpc: Disable CPU unknown by CLANG when CC_IS_CLANG https://git.kernel.org/powerpc/c/4b10306e98456aed03cad75ce467e8b1efdccca0 cheers
Re: [PATCH] powerpc/kexec_file: fix implicit decl error
On Sat, 4 Feb 2023 09:22:06 -0800, Randy Dunlap wrote: > kexec (PPC64) code calls memory_hotplug_max(). Add the header declaration > for it from . Using does not work since > the #include for depends on CONFIG_NUMA=y, which is not > set in this kernel config file. > > Fixes this build error/warning: > > [...] Applied to powerpc/fixes. [1/1] powerpc/kexec_file: fix implicit decl error https://git.kernel.org/powerpc/c/97e45d469eb180a7bd2809e4e079331552c73e42 cheers
Re: [PATCH] powerpc/64s/interrupt: Fix interrupt exit race with security mitigation switch
On Mon, 6 Feb 2023 14:22:40 +1000, Nicholas Piggin wrote: > The RFI and STF security mitigation options can flip the > interrupt_exit_not_reentrant static branch condition concurrently with > the interrupt exit code which tests that branch. > > Interrupt exit tests this condition to set MSR[EE|RI] for exit, then > again in the case a soft-masked interrupt is found pending, to recover > the MSR so the interrupt can be replayed before attempting to exit > again. If the condition changes between these two tests, the MSR and irq > soft-mask state will become corrupted, leading to warnings and possible > crashes. For example, if the branch is initially true then false, > MSR[EE] will be 0 but PACA_IRQ_HARD_DIS clear and EE may not get > enabled, leading to warnings in irq_64.c. > > [...] Applied to powerpc/fixes. [1/1] powerpc/64s/interrupt: Fix interrupt exit race with security mitigation switch https://git.kernel.org/powerpc/c/2ea31e2e62bbc4d11c411eeb36f1b02841dbcab1 cheers
Re: [PATCH v6 24/26] powerpc/pseries: Implement secvars for dynamic secure boot
Andrew Donnellan writes: > On Mon, 2023-02-13 at 22:32 +1100, Michael Ellerman wrote: >> > > + memcpy(, data, sizeof(flags)); >> > >> > conversion from bytestream to integer: I think in this case it >> > would be better to use >> > >> > flags = cpu_to_be64p((__u64*)data); >> > >> > so that the flags always in hypervisor/big endian format >> >> I don't think it's correct to byte swap the flags here. They must be >> in big endian format, but that's up to the caller. > > That was what I initially thought, until I went and tested it properly > and found it was indeed broken (at least in our qemu environment, this > is slightly tricky for me to test right now on real hardware with real > PowerVM) depending on kernel endianness. > > - Userspace writes the flags into the buffer in BE order > > - The first 8 bytes of the buffer are memcpy()ed, in BE order, into > flags (a u64) > > - plpar_hcall9() is called with flags as an argument, loaded into r9 > > - r9 is moved to r8 before jumping into the hypervisor > > On a BE system, this works fine. On an LE system, this results in the > bytes in the flags variable being loaded into the register in LE order, > so the conversion is necessary. Ah yep of course. So although the flags are written by userspace as part of the data as a stream of bytes, they're passed to the HV via a register. I've had this patch in next for a few days and don't want to rebase it. So can you send a follow-up patch to fix the flags endianess, with a nice changelog and comment :) cheers
Re: [PATCH v3 09/24] powerpc: Remove COMMAND_LINE_SIZE from uapi
Alexandre Ghiti writes: > From: Palmer Dabbelt > > As far as I can tell this is not used by userspace and thus should not > be part of the user-visible API. > > Signed-off-by: Palmer Dabbelt > --- > arch/powerpc/include/asm/setup.h | 2 +- > arch/powerpc/include/uapi/asm/setup.h | 2 -- > 2 files changed, 1 insertion(+), 3 deletions(-) Acked-by: Michael Ellerman (powerpc) cheers
Re: Build regressions/improvements in v6.2-rc8
Geert Uytterhoeven writes:
> On Mon, 13 Feb 2023, Geert Uytterhoeven wrote:
>> JFYI, when comparing v6.2-rc8[1] to v6.2-rc7[3], the summaries are:
>> - build errors: +11/-1
>
>+ {standard input}: Error: unrecognized opcode: `dcbfl': => 5736, 4743,
> 4327, 4476, 4447, 5067, 4602, 5212, 5224, 4298, 5594, 4315, 5050, 5195, 4464,
> 5079
>+ {standard input}: Error: unrecognized opcode: `dlmzb.': => 2848, 18800,
> 2842, 2383, 106, 2377, 3327, 112
>+ {standard input}: Error: unrecognized opcode: `iccci': => 204, 163, 510
>+ {standard input}: Error: unrecognized opcode: `lbarx': => 570, 196
>+ {standard input}: Error: unrecognized opcode: `mbar': => 887, 558,
> 1172, 539, 516, 837, 1457, 1125, 815, 7523, 1100, 1385, 368, 703, 662, 468,
> 441, 1410
>+ {standard input}: Error: unrecognized opcode: `mfdcr': => 3589, 4358,
> 3565, 3493, 3614, 128, 3445, 276, 3518, 3541, 3469, 4413
>+ {standard input}: Error: unrecognized opcode: `mtdcr': => 265, 4402,
> 4430, 4375, 4388, 4347, 117, 4443
>+ {standard input}: Error: unrecognized opcode: `stbcx.': => 196, 570
>+ {standard input}: Error: unrecognized opcode: `tlbwe': => 475, 476, 477
>
> powerpc-gcc11/ppc64_book3e_allmodconfig
> powerpc-gcc11/powerpc-allmodconfig
> powerpc-gcc11/corenet64_smp_defconfig
> powerpc-gcc11/powerpc-allyesconfig
> powerpc-gcc11/44x/fsp2_defconfig
That was me updating the GCC 11 toolchain from 11.1 to 11.3 (and more
importantly binutils 2.36 to 2.38), so not an actual regression.
I've backed that change out for now for powerpc builds.
cheers
Re: [PATCH v6 24/26] powerpc/pseries: Implement secvars for dynamic secure boot
Stefan Berger writes:
> On 2/10/23 03:03, Andrew Donnellan wrote:
>> From: Russell Currey
...
>> +static int plpks_set_variable(const char *key, u64 key_len, u8 *data,
>> + u64 data_size)
>> +{
>> +struct plpks_var var = {0};
>> +int rc = 0;
>> +u64 flags;
>> +
>> +// Secure variables need to be prefixed with 8 bytes of flags.
>> +// We only want to perform the write if we have at least one byte of
>> data.
>> +if (data_size <= sizeof(flags))
>> +return -EINVAL;
>> +
>> +// We subtract 1 from key_len because we don't need to include the
>> +// null terminator at the end of the string
>> +var.name = kcalloc(key_len - 1, sizeof(wchar_t), GFP_KERNEL);
>> +if (!var.name)
>> +return -ENOMEM;
>> +rc = utf8s_to_utf16s(key, key_len - 1, UTF16_LITTLE_ENDIAN, (wchar_t
>> *)var.name,
>> + key_len - 1);
>> +if (rc < 0)
>> +goto err;
>> +var.namelen = rc * 2;
>> +
>> +memcpy(, data, sizeof(flags));
>
> conversion from bytestream to integer: I think in this case it would be
> better to use
>
> flags = cpu_to_be64p((__u64*)data);
>
> so that the flags always in hypervisor/big endian format
I don't think it's correct to byte swap the flags here. They must be in
big endian format, but that's up to the caller.
The powernv secvar backend doesn't byte swap the flags, if the pseries
one did then the final content of the variable, written either by phyp
or OPAL, would differ depending on which backend is active.
Or am I missing something?
cheers
[PATCH] powerpc/nohash: Fix build error with binutils >= 2.38
With bintils >= 2.38 the ppc64_book3e_allmodconfig build fails:
{standard input}: Assembler messages:
{standard input}:196: Error: unrecognized opcode: `lbarx'
{standard input}:196: Error: unrecognized opcode: `stbcx.'
make[5]: *** [scripts/Makefile.build:252:
arch/powerpc/mm/nohash/e500_hugetlbpage.o] Error 1
That happens because the default CPU for that config is e5500, set via
CONFIG_TARGET_CPU, and so the assembler is building for e5500, which
doesn't support those instructions.
Fix it by using machine directives to tell the assembler to assemble the
relevant code for e6500, which does support lbarx/stbcx.
That is safe because the code already has the CPU_FTR_SMT check, which
ensures the lbarx sequence doesn't run on e5500, which doesn't support
SMT.
Signed-off-by: Michael Ellerman
---
arch/powerpc/mm/nohash/e500_hugetlbpage.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/nohash/e500_hugetlbpage.c
b/arch/powerpc/mm/nohash/e500_hugetlbpage.c
index c7d4b317a823..58c8d9849cb1 100644
--- a/arch/powerpc/mm/nohash/e500_hugetlbpage.c
+++ b/arch/powerpc/mm/nohash/e500_hugetlbpage.c
@@ -45,7 +45,9 @@ static inline void book3e_tlb_lock(void)
if (!cpu_has_feature(CPU_FTR_SMT))
return;
- asm volatile("1: lbarx %0, 0, %1;"
+ asm volatile(".machine push;"
+".machine e6500;"
+"1: lbarx %0, 0, %1;"
"cmpwi %0, 0;"
"bne 2f;"
"stbcx. %2, 0, %1;"
@@ -56,6 +58,7 @@ static inline void book3e_tlb_lock(void)
"bne 2b;"
"b 1b;"
"3:"
+".machine pop;"
: "=" (tmp)
: "r" (>tcd_ptr->lock), "r" (token)
: "memory");
--
2.39.1
Re: [PATCH] powerpc/machdep: warn when machine_is() used too early
Christophe Leroy writes:
> Le 11/02/2023 à 00:56, Nathan Lynch via B4 Submission Endpoint a écrit :
>> From: Nathan Lynch
>>
>> machine_is() can't provide correct results before probe_machine() has
>> run. Warn when it's used too early in boot.
>>
>> Signed-off-by: Nathan Lynch
>> ---
>> Prompted by my attempts to do some pseries-specific setup during
>> rtas_initialize() and being puzzled for a while that it wasn't
>> working.
>> ---
>> arch/powerpc/include/asm/machdep.h | 12 +++-
>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/machdep.h
>> b/arch/powerpc/include/asm/machdep.h
>> index 378b8d5836a7..8c0a799d18cd 100644
>> --- a/arch/powerpc/include/asm/machdep.h
>> +++ b/arch/powerpc/include/asm/machdep.h
>> @@ -220,11 +220,13 @@ extern struct machdep_calls *machine_id;
>> EXPORT_SYMBOL(mach_##name); \
>> struct machdep_calls mach_##name __machine_desc =
>>
>> -#define machine_is(name) \
>> -({ \
>> -extern struct machdep_calls mach_##name \
>> -__attribute__((weak)); \
>> -machine_id == _##name; \
>> +#define machine_is(name)\
>> +({ \
>> +extern struct machdep_calls mach_##name \
>> +__attribute__((weak)); \
>> +WARN(!machine_id, \
>> + "machine_is() called before probe_machine()"); \
>
> Is a WARN() really necessary ? WARN() is less optimised than WARN_ON(),
> especially on PPC64.
>
> This should never ever happen so a WARN_ON(!machine_id) should be
> enough, the developper that hits it is able to go to the given file:line
> and understand what happened.
Yeah I agree, WARN_ON() should be sufficient here, and should generate
slightly better code. We have > 100 uses of machine_is(), so keeping
each small is desirable.
cheers
Re: [PATCH v6 24/26] powerpc/pseries: Implement secvars for dynamic secure boot
Andrew Donnellan writes: > On Fri, 2023-02-10 at 16:28 -0500, Stefan Berger wrote: >> > > +err: >> > > + kfree(var.data); >> > >> > remove the kfree() >> >> Actually don't remove it but it should probably be >> >> if (var.data != ) >> kfree(var.data); >> > > Argh, thanks for catching this. > > I don't think the condition is needed - we can assume the var.data is > unmodified. > > mpe, are you able to fix this up in merge? Yeah, can you reply here with the delta you want applied. cheers
Re: linux-next: build failure after merge of the powerpc tree
Stephen Rothwell writes:
> Hi all,
>
> After merging the powerpc tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
>
> arch/powerpc/kernel/setup_64.c: In function 'early_setup':
> arch/powerpc/kernel/setup_64.c:400:34: error: 'struct thread_info' has no
> member named 'cpu'
> 400 | task_thread_info(current)->cpu = boot_cpuid; // fix
> task_cpu(current)
> | ^~
>
> Caused by commit
>
> 0ecf51ca51e5 ("powerpc/64: Fix task_cpu in early boot when booting non-zero
> cpuid")
>
> # CONFIG_SMP is not set
Thanks. I squashed in the fix.
cheers
[GIT PULL] Please pull powerpc/linux.git powerpc-6.2-5 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some more powerpc fixes for 6.2: The following changes since commit 1665c027afb225882a5a0b014c45e84290b826c2: powerpc/64s: Reconnect tlb_flush() to hash__tlb_flush() (2023-02-02 13:25:47 +1100) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-6.2-5 for you to fetch changes up to 2ea31e2e62bbc4d11c411eeb36f1b02841dbcab1: powerpc/64s/interrupt: Fix interrupt exit race with security mitigation switch (2023-02-07 10:13:33 +1100) - -- powerpc fixes for 6.2 #5 - Fix interrupt exit race with security mitigation switching. - Don't select ARCH_WANTS_NO_INSTR until warnings are fixed. - Build fix for CONFIG_NUMA=n. Thanks to: Nicholas Piggin, Randy Dunlap, Sachin Sant. - -- Michael Ellerman (1): powerpc: Don't select ARCH_WANTS_NO_INSTR Nicholas Piggin (1): powerpc/64s/interrupt: Fix interrupt exit race with security mitigation switch Randy Dunlap (1): powerpc/kexec_file: fix implicit decl error arch/powerpc/Kconfig | 1 - arch/powerpc/kernel/interrupt.c | 6 -- arch/powerpc/kexec/file_load_64.c | 1 + 3 files changed, 5 insertions(+), 3 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmPoj04ACgkQUevqPMjh pYB3wA/+Kt7u27m3MjbwXMb127eP2V6nzGLkyN1wL8/xGMtehNGfLRVI7VGs96J8 cGAvr7nxRjamhfjqAzUPBWihhmQhrTTzrUb/Czlgbxpjov3KHCif2aaQsLuZRI8P KaZbCJJdx1mBh7mpREWrCT1FlZhN6j8mDfjbmUjlnEKcZnTk/xDF6SHYRjbmPbLh KsWSFAE/zwiPYSuaIDASdLHvNJ9YomysSYpu8b9JSJlyT/JZftPzRdvf8ab8ji++ AyVNeCLr7S/Dejn0AZZNaB9FJ6R+KB6KnHBwFYraykASao60qwcDvQ6enUknWsYS eDLPkpPLZ5lwiNF834MsYz/Cci/nUO1Vg8++e3c5++62kyDsljQPyPrLG40lL6Ok SXnFI4CsygUrHbIB/7glesceagOPkeVQwoUtZHC11o+SG0YsqSzT2Mb4KbnocTaf Veyon0OJfWu4ylfHGsQdpFl6hlCdu/COzV5Qwv57mXG6sem4nQBkcIE5+MdW6IAG UQiFHVWvF2P/rvX23Qf4nade2Aspw7Al2VLN0dPrvv04+BO8wHRdXkHjF/PldDMC D7yRjTlBQ5irZW+CwRe2XbRMuiHOiwc6R8v4k2Qs2zWIrmfGOdusM9mM8Xlet8EK lwyImXGeInFNh6bRwcPshFiIvWY/EfmPZ8A0zTqxBU9GpQV0J18= =1Ktz -END PGP SIGNATURE-
Re: [PATCH v2 11/19] powerpc/rtas: add work area allocator
Nathan Lynch writes:
> Michael Ellerman writes:
>> Nathan Lynch via B4 Submission Endpoint
>> writes:
...
>>> +struct rtas_work_area * __ref rtas_work_area_alloc(size_t size)
>>> +{
>>> + struct rtas_work_area *area;
>>> + unsigned long addr;
>>> +
>>> + might_sleep();
>>> +
>>> + WARN_ON(size > RTAS_WORK_AREA_MAX_ALLOC_SZ);
>>> + size = min_t(size_t, size, RTAS_WORK_AREA_MAX_ALLOC_SZ);
>>
>> This seems unsafe.
>>
>> If you return a buffer smaller than the caller asks for they're likely
>> to read/write past the end of it and corrupt memory.
>
> OK, let's figure out another way to handle this.
>
>> AFAIK genalloc doesn't have guard pages or anything fancy to save us
>> from that - but maybe I'm wrong, I've never used it.
>
> Yeah we would have to build our own thing on top of it. And I don't
> think it could be something that traps on access, it would have to be a
> check in rtas_work_area_free(), after the fact.
I *think* we could use the MMU. We'd just have to allocate whole pages,
and then vmap() them (create a mapping in vmalloc space), and then give
the vmalloc space address back to the caller. They'd then operate on
that address, meaning any overflow would trap. You already have
rtas_work_area_phys() for passing the phys address to RTAS.
But that would be a lot more complicated than your suggestion below.
>> There's only three callers in the end, seems like we should just return
>> NULL if the size is too large and have callers check the return value.
>
> There are more conversions to do, and a property I hope to maintain is
> that requests can't fail. Existing users of rtas_data_buf don't have
> error paths for failure to acquire the buffer.
>
> I believe the allocation size passed to rtas_work_area_alloc() can be
> known at build time in all cases. Maybe we could prevent inappropriate
> requests from being built with a compile-time assertion (untested):
>
> /* rtas-work-area.h */
>
> static inline struct rtas_work_area *rtas_work_area_alloc(size_t sz)
> {
> static_assert(sz < RTAS_WORK_AREA_MAX_ALLOC_SZ);
> return __rtas_work_area_alloc(sz);
> }
>
> I think this would be OK? If I can't make it work I'll fall back to
> returning NULL as you suggest, but it will make for more churn (and
> risk) in the conversions.
Yeah if the sizes are always known at compile time that is a much better
solution.
cheers
Re: [PATCH v2 01/19] powerpc/rtas: handle extended delays safely in early boot
Nathan Lynch writes:
> Michael Ellerman writes:
>> Nathan Lynch via B4 Submission Endpoint
>> writes:
>>> From: Nathan Lynch
>>>
>>> Some code that runs early in boot calls RTAS functions that can return
>>> -2 or 990x statuses, which mean the caller should retry. An example is
>>> pSeries_cmo_feature_init(), which invokes ibm,get-system-parameter but
>>> treats these benign statuses as errors instead of retrying.
>>>
>>> pSeries_cmo_feature_init() and similar code should be made to retry
>>> until they succeed or receive a real error, using the usual pattern:
>>>
>>> do {
>>> rc = rtas_call(token, etc...);
>>> } while (rtas_busy_delay(rc));
>>>
>>> But rtas_busy_delay() will perform a timed sleep on any 990x
>>> status. This isn't safe so early in boot, before the CPU scheduler and
>>> timer subsystem have initialized.
>>>
>>> The -2 RTAS status is much more likely to occur during single-threaded
>>> boot than 990x in practice, at least on PowerVM. This is because -2
>>> usually means that RTAS made progress but exhausted its self-imposed
>>> timeslice, while 990x is associated with concurrent requests from the
>>> OS causing internal contention. Regardless, according to the language
>>> in PAPR, the OS should be prepared to handle either type of status at
>>> any time.
>>>
>>> Add a fallback path to rtas_busy_delay() to handle this as safely as
>>> possible, performing a small delay on 990x. Include a counter to
>>> detect retry loops that aren't making progress and bail out.
>>>
>>> This was found by inspection and I'm not aware of any real
>>> failures. However, the implementation of rtas_busy_delay() before
>>> commit 38f7b7067dae ("powerpc/rtas: rtas_busy_delay() improvements")
>>> was not susceptible to this problem, so let's treat this as a
>>> regression.
>>>
>>> Signed-off-by: Nathan Lynch
>>> Fixes: 38f7b7067dae ("powerpc/rtas: rtas_busy_delay() improvements")
>>> ---
>>> arch/powerpc/kernel/rtas.c | 48
>>> +-
>>> 1 file changed, 47 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
>>> index 795225d7f138..ec2df09a70cf 100644
>>> --- a/arch/powerpc/kernel/rtas.c
>>> +++ b/arch/powerpc/kernel/rtas.c
>>> @@ -606,6 +606,46 @@ unsigned int rtas_busy_delay_time(int status)
>>> return ms;
>>> }
>>>
>>> +/*
>>> + * Early boot fallback for rtas_busy_delay().
>>> + */
>>> +static bool __init rtas_busy_delay_early(int status)
>>> +{
>>> + static size_t successive_ext_delays __initdata;
>>> + bool ret;
>>
>> I think the logic would be easier to read if this was called "wait", but
>> maybe that's just me.
>
> Maybe "retry"? That communicates what the function is telling callers to do.
Yeah, that's even better.
cheers
Re: [PATCH mm-unstable v1 17/26] powerpc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE on 32bit book3s
David Hildenbrand writes:
> We already implemented support for 64bit book3s in commit bff9beaa2e80
> ("powerpc/pgtable: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE for book3s")
>
> Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE also in 32bit by reusing yet
> unused LSB 2 / MSB 29. There seems to be no real reason why that bit cannot
> be used, and reusing it avoids having to steal one bit from the swap
> offset.
>
> While at it, mask the type in __swp_entry().
>
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Christophe Leroy
> Signed-off-by: David Hildenbrand
> ---
> arch/powerpc/include/asm/book3s/32/pgtable.h | 38 +---
> 1 file changed, 33 insertions(+), 5 deletions(-)
I gave this a quick test on a ppc32 machine, everything seems fine.
Your test_swp_exclusive.c passes, and an LTP run looks normal.
Acked-by: Michael Ellerman (powerpc)
cheers
> diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h
> b/arch/powerpc/include/asm/book3s/32/pgtable.h
> index 75823f39e042..0ecb3a58f23f 100644
> --- a/arch/powerpc/include/asm/book3s/32/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
> @@ -42,6 +42,9 @@
> #define _PMD_PRESENT_MASK (PAGE_MASK)
> #define _PMD_BAD (~PAGE_MASK)
>
> +/* We borrow the _PAGE_USER bit to store the exclusive marker in swap PTEs.
> */
> +#define _PAGE_SWP_EXCLUSIVE _PAGE_USER
> +
> /* And here we include common definitions */
>
> #define _PAGE_KERNEL_RO 0
> @@ -363,17 +366,42 @@ static inline void __ptep_set_access_flags(struct
> vm_area_struct *vma,
> #define pmd_page(pmd)pfn_to_page(pmd_pfn(pmd))
>
> /*
> - * Encode and decode a swap entry.
> - * Note that the bits we use in a PTE for representing a swap entry
> - * must not include the _PAGE_PRESENT bit or the _PAGE_HASHPTE bit (if used).
> - * -- paulus
> + * Encode/decode swap entries and swap PTEs. Swap PTEs are all PTEs that
> + * are !pte_none() && !pte_present().
> + *
> + * Format of swap PTEs (32bit PTEs):
> + *
> + * 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
> + * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> + * <- offset > < type -> E H P
> + *
> + * E is the exclusive marker that is not stored in swap entries.
> + * _PAGE_PRESENT (P) and __PAGE_HASHPTE (H) must be 0.
> + *
> + * For 64bit PTEs, the offset is extended by 32bit.
> */
> #define __swp_type(entry)((entry).val & 0x1f)
> #define __swp_offset(entry) ((entry).val >> 5)
> -#define __swp_entry(type, offset)((swp_entry_t) { (type) | ((offset) <<
> 5) })
> +#define __swp_entry(type, offset)((swp_entry_t) { ((type) & 0x1f) |
> ((offset) << 5) })
> #define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte)
> >> 3 })
> #define __swp_entry_to_pte(x)((pte_t) { (x).val << 3 })
>
> +#define __HAVE_ARCH_PTE_SWP_EXCLUSIVE
> +static inline int pte_swp_exclusive(pte_t pte)
> +{
> + return pte_val(pte) & _PAGE_SWP_EXCLUSIVE;
> +}
> +
> +static inline pte_t pte_swp_mkexclusive(pte_t pte)
> +{
> + return __pte(pte_val(pte) | _PAGE_SWP_EXCLUSIVE);
> +}
> +
> +static inline pte_t pte_swp_clear_exclusive(pte_t pte)
> +{
> + return __pte(pte_val(pte) & ~_PAGE_SWP_EXCLUSIVE);
> +}
> +
> /* Generic accessors to PTE bits */
> static inline int pte_write(pte_t pte) { return
> !!(pte_val(pte) & _PAGE_RW);}
> static inline int pte_read(pte_t pte){ return 1; }
> --
> 2.39.0
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH v2 1/2] powerpc/ps3: Change updateboltedpp panic to info
Geoff Levand writes: > On 1/16/23 23:26, Christophe Leroy wrote: >> Le 16/01/2023 à 21:08, Geoff Levand a écrit : >>> >>> As mentioned, I'd really like to keep PS3 included in ppc64_defconfig. My >>> original patch that basically just ignores the call to >>> mmu_hash_ops.updateboltedpp allows that, and I haven't experienced any >>> problems >>> with it yet. >> >> When you say you have not experienced any problems with it, do you mean >> that STRICT_RWX works for you ? When you select CONFIG_DEBUG_RODATA_TEST >> it tells you that it works ? Otherwise it looks incorrect to enable >> something that doesn't work. > > What I mean is that the system boots up, and works as expected. > I have not tried with CONFIG_DEBUG_RODATA_TEST set. > >>> My preference would be to keep PS3 in ppc64_defconfig, and either apply my >>> original patch, or I keep that patch in my ps3-linux repo on kernel.org. >>> Then, >>> if we end up adding runtime support for RWX I then fixup PS3 to use that. >>> >> >> In that case I see two solutions: >> 1/ Implement updateboltedpp for PS3. > > I'm now looking into if this is possible. > >> 2/ Implement arch_parse_debug_rodata() to always set rodata_enabled = >> false on PS3, and update free_initmem() to only call mark_initmem_nx() >> when strict_kernel_rwx_enabled() returns true. > > OK, I'll consider this if I cannot get updateboltedp working. I'll take this series as-is for 6.3, there's no point panicking. Hopefully one of the above options can be implemented in future. cheers
Re: [PATCH v2 18/19] powerpc/rtas: introduce rtas_function_token() API
Nathan Lynch via B4 Submission Endpoint
writes:
> From: Nathan Lynch
>
> Users of rtas_token() supply a string argument that can't be validated
> at build time. A typo or misspelling has to be caught by inspection or
> by observing wrong behavior at runtime.
>
> Since the core RTAS code now has consolidated the names of all
> possible RTAS functions and mapped them to their tokens, token lookup
> can be implemented using symbolic constants to index a static array.
>
> So introduce rtas_function_token(), a replacement API which does that,
> along with a rtas_service_present()-equivalent helper,
> rtas_function_implemented(). Callers supply an opaque predefined
> function handle which is used internally to index the function
> table. Typos or other inappropriate arguments yield build errors, and
> the function handle is a type that can't be easily confused with RTAS
> tokens or other integer types.
Why not go all the way and have the rtas_call() signature be:
int rtas_call(rtas_fn_handle_t fn, int, int, int *, ...);
And have it do the token lookup internally? That way a caller can never
inadvertantly pass a random integer to rtas_call().
And instead of eg:
error = rtas_call(rtas_function_token(RTAS_FN_GET_TIME_OF_DAY), 0, 8,
ret);
we'd just need:
error = rtas_call(RTAS_FN_GET_TIME_OF_DAY, 0, 8, ret);
Doing the conversion all at once might be tricky. So maybe we need to add
rtas_fn_call() which takes rtas_fn_handle_t so we can convert cases
individually?
Anyway just a thought. I guess we could merge this as-is and then do a
further change to use rtas_fn_handle_t later.
> diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
> index 14fe79217c26..fe400438c1fb 100644
> --- a/arch/powerpc/include/asm/rtas.h
> +++ b/arch/powerpc/include/asm/rtas.h
> @@ -103,6 +103,99 @@ enum rtas_function_index {
> rtas_fnidx(WRITE_PCI_CONFIG),
> };
>
> +/*
> + * Opaque handle for client code to refer to RTAS functions. All valid
> + * function handles are build-time constants prefixed with RTAS_FN_.
> + */
> +typedef struct {
> + const enum rtas_function_index index;
> +} rtas_fn_handle_t;
> +
> +#define rtas_fn_handle(x_) ((const rtas_fn_handle_t) { .index =
> rtas_fnidx(x_), })
> +
> +#define RTAS_FN_CHECK_EXCEPTION
> rtas_fn_handle(CHECK_EXCEPTION)
> +#define RTAS_FN_DISPLAY_CHARACTER
> rtas_fn_handle(DISPLAY_CHARACTER)
> +#define RTAS_FN_EVENT_SCANrtas_fn_handle(EVENT_SCAN)
> +#define RTAS_FN_FREEZE_TIME_BASE
> rtas_fn_handle(FREEZE_TIME_BASE)
> +#define RTAS_FN_GET_POWER_LEVEL
> rtas_fn_handle(GET_POWER_LEVEL)
> +#define RTAS_FN_GET_SENSOR_STATE
> rtas_fn_handle(GET_SENSOR_STATE)
> +#define RTAS_FN_GET_TERM_CHAR
> rtas_fn_handle(GET_TERM_CHAR)
> +#define RTAS_FN_GET_TIME_OF_DAY
> rtas_fn_handle(GET_TIME_OF_DAY)
> +#define RTAS_FN_IBM_ACTIVATE_FIRMWARE
> rtas_fn_handle(IBM_ACTIVATE_FIRMWARE)
> +#define RTAS_FN_IBM_CBE_START_PTCAL
> rtas_fn_handle(IBM_CBE_START_PTCAL)
> +#define RTAS_FN_IBM_CBE_STOP_PTCAL
> rtas_fn_handle(IBM_CBE_STOP_PTCAL)
> +#define RTAS_FN_IBM_CHANGE_MSI
> rtas_fn_handle(IBM_CHANGE_MSI)
> +#define RTAS_FN_IBM_CLOSE_ERRINJCT
> rtas_fn_handle(IBM_CLOSE_ERRINJCT)
> +#define RTAS_FN_IBM_CONFIGURE_BRIDGE
> rtas_fn_handle(IBM_CONFIGURE_BRIDGE)
> +#define RTAS_FN_IBM_CONFIGURE_CONNECTOR
> rtas_fn_handle(IBM_CONFIGURE_CONNECTOR)
> +#define RTAS_FN_IBM_CONFIGURE_KERNEL_DUMP
> rtas_fn_handle(IBM_CONFIGURE_KERNEL_DUMP)
> +#define RTAS_FN_IBM_CONFIGURE_PE
> rtas_fn_handle(IBM_CONFIGURE_PE)
> +#define RTAS_FN_IBM_CREATE_PE_DMA_WINDOW
> rtas_fn_handle(IBM_CREATE_PE_DMA_WINDOW)
> +#define RTAS_FN_IBM_DISPLAY_MESSAGE
> rtas_fn_handle(IBM_DISPLAY_MESSAGE)
> +#define RTAS_FN_IBM_ERRINJCT
> rtas_fn_handle(IBM_ERRINJCT)
> +#define RTAS_FN_IBM_EXTI2Crtas_fn_handle(IBM_EXTI2C)
> +#define RTAS_FN_IBM_GET_CONFIG_ADDR_INFO
> rtas_fn_handle(IBM_GET_CONFIG_ADDR_INFO)
> +#define RTAS_FN_IBM_GET_CONFIG_ADDR_INFO2
> rtas_fn_handle(IBM_GET_CONFIG_ADDR_INFO2)
> +#define RTAS_FN_IBM_GET_DYNAMIC_SENSOR_STATE
> rtas_fn_handle(IBM_GET_DYNAMIC_SENSOR_STATE)
> +#define RTAS_FN_IBM_GET_INDICES
> rtas_fn_handle(IBM_GET_INDICES)
> +#define RTAS_FN_IBM_GET_RIO_TOPOLOGY
> rtas_fn_handle(IBM_GET_RIO_TOPOLOGY)
> +#define RTAS_FN_IBM_GET_SYSTEM_PARAMETER
> rtas_fn_handle(IBM_GET_SYSTEM_PARAMETER)
> +#define RTAS_FN_IBM_GET_VPD rtas_fn_handle(IBM_GET_VPD)
> +#define RTAS_FN_IBM_GET_XIVE
> rtas_fn_handle(IBM_GET_XIVE)
> +#define RTAS_FN_IBM_INT_OFF rtas_fn_handle(IBM_INT_OFF)
> +#define
Re: [PATCH v2 11/19] powerpc/rtas: add work area allocator
Nathan Lynch via B4 Submission Endpoint
writes:
> diff --git a/arch/powerpc/include/asm/rtas-work-area.h
> b/arch/powerpc/include/asm/rtas-work-area.h
> new file mode 100644
> index ..76ccb039cc37
> --- /dev/null
> +++ b/arch/powerpc/include/asm/rtas-work-area.h
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef POWERPC_RTAS_WORK_AREA_H
> +#define POWERPC_RTAS_WORK_AREA_H
The usual style would be _ASM_POWERPC_RTAS_WORK_AREA_H.
> diff --git a/arch/powerpc/kernel/rtas-work-area.c
> b/arch/powerpc/kernel/rtas-work-area.c
> new file mode 100644
> index ..75950e13a0fe
> --- /dev/null
> +++ b/arch/powerpc/kernel/rtas-work-area.c
> @@ -0,0 +1,208 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#define pr_fmt(fmt) "rtas-work-area: " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +enum {
> + /*
> + * Ensure the pool is page-aligned.
> + */
> + RTAS_WORK_AREA_ARENA_ALIGN = PAGE_SIZE,
> +
> + RTAS_WORK_AREA_ARENA_SZ = SZ_256K,
> + /*
> + * The smallest known work area size is for ibm,get-vpd's
> + * location code argument, which is limited to 79 characters
> + * plus 1 nul terminator.
> + *
> + * PAPR+ 7.3.20 ibm,get-vpd RTAS Call
> + * PAPR+ 12.3.2.4 Converged Location Code Rules - Length Restrictions
> + */
> + RTAS_WORK_AREA_MIN_ALLOC_SZ = roundup_pow_of_two(80),
> + /*
> + * Don't let a single allocation claim the whole arena.
> + */
> + RTAS_WORK_AREA_MAX_ALLOC_SZ = RTAS_WORK_AREA_ARENA_SZ / 2,
> +};
> +
> +static struct rtas_work_area_allocator_state {
> + struct gen_pool *gen_pool;
> + char *arena;
> + struct mutex mutex; /* serializes allocations */
> + struct wait_queue_head wqh;
> + mempool_t descriptor_pool;
> + bool available;
> +} rwa_state_ = {
> + .mutex = __MUTEX_INITIALIZER(rwa_state_.mutex),
> + .wqh = __WAIT_QUEUE_HEAD_INITIALIZER(rwa_state_.wqh),
> +};
> +static struct rtas_work_area_allocator_state *rwa_state = _state_;
I assumed the pointer was so you could swap this out at runtime or
something, but I don't think you do.
Any reason not to drop the pointer and just use rwa_state.foo accessors?
That would also allow the struct to be anonymous.
Or if you have the pointer you can at least make it NULL prior to init
and avoid the need for "available".
> +/*
> + * A single work area buffer and descriptor to serve requests early in
> + * boot before the allocator is fully initialized.
> + */
> +static bool early_work_area_in_use __initdata;
> +static char early_work_area_buf[SZ_4K] __initdata;
That should be page aligned I think?
> +static struct rtas_work_area early_work_area __initdata = {
> + .buf = early_work_area_buf,
> + .size = sizeof(early_work_area_buf),
> +};
> +
> +
> +static struct rtas_work_area * __init rtas_work_area_alloc_early(size_t size)
> +{
> + WARN_ON(size > early_work_area.size);
> + WARN_ON(early_work_area_in_use);
> + early_work_area_in_use = true;
> + memset(early_work_area.buf, 0, early_work_area.size);
> + return _work_area;
> +}
> +
> +static void __init rtas_work_area_free_early(struct rtas_work_area
> *work_area)
> +{
> + WARN_ON(work_area != _work_area);
> + WARN_ON(!early_work_area_in_use);
> + early_work_area_in_use = false;
> +}
> +
> +struct rtas_work_area * __ref rtas_work_area_alloc(size_t size)
> +{
> + struct rtas_work_area *area;
> + unsigned long addr;
> +
> + might_sleep();
> +
> + WARN_ON(size > RTAS_WORK_AREA_MAX_ALLOC_SZ);
> + size = min_t(size_t, size, RTAS_WORK_AREA_MAX_ALLOC_SZ);
This seems unsafe.
If you return a buffer smaller than the caller asks for they're likely
to read/write past the end of it and corrupt memory.
AFAIK genalloc doesn't have guard pages or anything fancy to save us
from that - but maybe I'm wrong, I've never used it.
There's only three callers in the end, seems like we should just return
NULL if the size is too large and have callers check the return value.
> + if (!rwa_state->available) {
> + area = rtas_work_area_alloc_early(size);
> + goto out;
> + }
> +
> + /*
> + * To ensure FCFS behavior and prevent a high rate of smaller
> + * requests from starving larger ones, use the mutex to queue
> + * allocations.
> + */
> + mutex_lock(_state->mutex);
> + wait_event(rwa_state->wqh,
> +(addr = gen_pool_alloc(rwa_state->gen_pool, size)) != 0);
> + mutex_unlock(_state->mutex);
> +
> + area = mempool_alloc(_state->descriptor_pool, GFP_KERNEL);
> + *area = (typeof(*area)){
> + .size = size,
> + .buf = (char *)addr,
> + };
That is an odd way to write that :)
> +out:
> + pr_devel("%ps -> %s() -> buf=%p size=%zu\n",
> + (void
Re: [PATCH v2 07/19] powerpc/rtas: improve function information lookups
Nathan Lynch via B4 Submission Endpoint
writes:
> From: Nathan Lynch
>
> The core RTAS support code and its clients perform two types of lookup
> for RTAS firmware function information.
>
...
> diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
> index 479a95cb2770..14fe79217c26 100644
> --- a/arch/powerpc/include/asm/rtas.h
> +++ b/arch/powerpc/include/asm/rtas.h
> @@ -16,6 +16,93 @@
> * Copyright (C) 2001 PPC 64 Team, IBM Corp
> */
>
> +#define rtas_fnidx(x_) RTAS_FNIDX__ ## x_
I'd prefer we just spelt it out in full, to aid grepability and
cscope/tags etc.
> +enum rtas_function_index {
> + rtas_fnidx(CHECK_EXCEPTION),
> + rtas_fnidx(DISPLAY_CHARACTER),
> + rtas_fnidx(EVENT_SCAN),
> + rtas_fnidx(FREEZE_TIME_BASE),
> + rtas_fnidx(GET_POWER_LEVEL),
> + rtas_fnidx(GET_SENSOR_STATE),
> + rtas_fnidx(GET_TERM_CHAR),
> + rtas_fnidx(GET_TIME_OF_DAY),
> + rtas_fnidx(IBM_ACTIVATE_FIRMWARE),
> + rtas_fnidx(IBM_CBE_START_PTCAL),
> + rtas_fnidx(IBM_CBE_STOP_PTCAL),
> + rtas_fnidx(IBM_CHANGE_MSI),
cheers
Re: [PATCH v2 01/19] powerpc/rtas: handle extended delays safely in early boot
Nathan Lynch via B4 Submission Endpoint
writes:
> From: Nathan Lynch
>
> Some code that runs early in boot calls RTAS functions that can return
> -2 or 990x statuses, which mean the caller should retry. An example is
> pSeries_cmo_feature_init(), which invokes ibm,get-system-parameter but
> treats these benign statuses as errors instead of retrying.
>
> pSeries_cmo_feature_init() and similar code should be made to retry
> until they succeed or receive a real error, using the usual pattern:
>
> do {
> rc = rtas_call(token, etc...);
> } while (rtas_busy_delay(rc));
>
> But rtas_busy_delay() will perform a timed sleep on any 990x
> status. This isn't safe so early in boot, before the CPU scheduler and
> timer subsystem have initialized.
>
> The -2 RTAS status is much more likely to occur during single-threaded
> boot than 990x in practice, at least on PowerVM. This is because -2
> usually means that RTAS made progress but exhausted its self-imposed
> timeslice, while 990x is associated with concurrent requests from the
> OS causing internal contention. Regardless, according to the language
> in PAPR, the OS should be prepared to handle either type of status at
> any time.
>
> Add a fallback path to rtas_busy_delay() to handle this as safely as
> possible, performing a small delay on 990x. Include a counter to
> detect retry loops that aren't making progress and bail out.
>
> This was found by inspection and I'm not aware of any real
> failures. However, the implementation of rtas_busy_delay() before
> commit 38f7b7067dae ("powerpc/rtas: rtas_busy_delay() improvements")
> was not susceptible to this problem, so let's treat this as a
> regression.
>
> Signed-off-by: Nathan Lynch
> Fixes: 38f7b7067dae ("powerpc/rtas: rtas_busy_delay() improvements")
> ---
> arch/powerpc/kernel/rtas.c | 48
> +-
> 1 file changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
> index 795225d7f138..ec2df09a70cf 100644
> --- a/arch/powerpc/kernel/rtas.c
> +++ b/arch/powerpc/kernel/rtas.c
> @@ -606,6 +606,46 @@ unsigned int rtas_busy_delay_time(int status)
> return ms;
> }
>
> +/*
> + * Early boot fallback for rtas_busy_delay().
> + */
> +static bool __init rtas_busy_delay_early(int status)
> +{
> + static size_t successive_ext_delays __initdata;
> + bool ret;
I think the logic would be easier to read if this was called "wait", but
maybe that's just me.
> + switch (status) {
> + case RTAS_EXTENDED_DELAY_MIN...RTAS_EXTENDED_DELAY_MAX:
> + /*
> + * In the unlikely case that we receive an extended
> + * delay status in early boot, the OS is probably not
> + * the cause, and there's nothing we can do to clear
> + * the condition. Best we can do is delay for a bit
> + * and hope it's transient. Lie to the caller if it
> + * seems like we're stuck in a retry loop.
> + */
> + mdelay(1);
> + ret = true;
> + successive_ext_delays += 1;
> + if (successive_ext_delays > 1000) {
> + pr_err("too many extended delays, giving up\n");
> + dump_stack();
> + ret = false;
Shouldn't we zero successive_ext_delays here?
Otherwise a subsequent (possibly different) RTAS call will immediately
fail out here if it gets a single extended delay from RTAS, won't it?
> + }
> + break;
> + case RTAS_BUSY:
> + ret = true;
> + successive_ext_delays = 0;
> + break;
> + default:
> + ret = false;
> + successive_ext_delays = 0;
> + break;
> + }
> +
> + return ret;
> +}
> +
> /**
> * rtas_busy_delay() - helper for RTAS busy and extended delay statuses
> *
> @@ -624,11 +664,17 @@ unsigned int rtas_busy_delay_time(int status)
> * * false - @status is not @RTAS_BUSY nor an extended delay hint. The
> * caller is responsible for handling @status.
> */
> -bool rtas_busy_delay(int status)
> +bool __ref rtas_busy_delay(int status)
Can you explain the __ref in the change log.
> {
> unsigned int ms;
> bool ret;
>
> + /*
> + * Can't do timed sleeps before timekeeping is up.
> + */
> + if (system_state < SYSTEM_SCHEDULING)
> + return rtas_busy_delay_early(status);
> +
> switch (status) {
> case RTAS_EXTENDED_DELAY_MIN...RTAS_EXTENDED_DELAY_MAX:
> ret = true;
>
cheers
[PATCH v3] powerpc/pci: Add option for using pci_to_OF_bus_map
From: Pali Rohár
The "pci-OF-bus-map" property was declared deprecated in 2006 [1] and to
the best of everyone's knowledge is not used by anything anymore [2].
The creation of the property was disabled on powermac (arch/powerpc) in
2005 by commit 35499c0195e4 ("powerpc: Merge in 64-bit powermac
support."). But it is still created by default on CHRP.
On powermac the actual map (pci_to_OF_bus_map) is still used by default,
even though the device tree property is not created.
Add an option to enable/disable use of the pci_to_OF_bus_map, and
creation of the property (on CHRP).
Disabling the option allows enabling CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT
which allows "normal" bus numbering and more than 256 buses, like 64-bit
and other architectures.
Mark the new option as default n, the intention is that the option and
the code will be removed in a future release.
[1]:
https://lore.kernel.org/linuxppc-dev/1148016268.13249.14.camel@localhost.localdomain/
[2]:
https://lore.kernel.org/all/575f239205e8635add81c9f902b7d9db7beb83ea.ca...@kernel.crashing.org/
Signed-off-by: Pali Rohár
[mpe: Reword commit & help text, shrink option name, rework to fix build errors]
Signed-off-by: Michael Ellerman
---
arch/powerpc/Kconfig | 13 -
arch/powerpc/include/asm/pci-bridge.h | 4 +++-
arch/powerpc/kernel/pci_32.c | 17 -
3 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index fad25aa602c8..7dcb011cebf2 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -388,9 +388,20 @@ config PPC_DCR
depends on PPC_DCR_NATIVE || PPC_DCR_MMIO
default y
+config PPC_PCI_OF_BUS_MAP
+ bool "Use pci_to_OF_bus_map (deprecated)"
+ depends on PPC32
+ depends on PPC_PMAC || PPC_CHRP
+ help
+ This option uses pci_to_OF_bus_map to map OF nodes to PCI devices,
which
+ restricts the system to only having 256 PCI buses. On CHRP it also
causes
+ the "pci-OF-bus-map" property to be created in the device tree.
+
+ If unsure, say "N".
+
config PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT
depends on PPC32
- depends on !PPC_PMAC && !PPC_CHRP
+ depends on !PPC_PCI_OF_BUS_MAP
bool "Assign PCI bus numbers from zero individually for each PCI domain"
default y
help
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch/powerpc/include/asm/pci-bridge.h
index e18c95f4e1d4..71c1d26f2400 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -176,8 +176,10 @@ extern int pci_device_from_OF_node(struct device_node
*node,
#endif
#ifndef CONFIG_PPC64
-#ifdef CONFIG_PPC_CHRP
+#ifdef CONFIG_PPC_PCI_OF_BUS_MAP
extern void pci_create_OF_bus_map(void);
+#else
+static inline void pci_create_OF_bus_map(void) {}
#endif
#else /* CONFIG_PPC64 */
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 855b59892c5c..ce0c8623e563 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -62,7 +62,7 @@ fixup_cpc710_pci64(struct pci_dev* dev)
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_IBM,PCI_DEVICE_ID_IBM_CPC710_PCI64,
fixup_cpc710_pci64);
-#if defined(CONFIG_PPC_PMAC) || defined(CONFIG_PPC_CHRP)
+#ifdef CONFIG_PPC_PCI_OF_BUS_MAP
static u8* pci_to_OF_bus_map;
static int pci_bus_count;
@@ -152,6 +152,7 @@ pcibios_make_OF_bus_map(void)
}
#endif
}
+#endif // CONFIG_PPC_PCI_OF_BUS_MAP
#ifdef CONFIG_PPC_PMAC
@@ -160,7 +161,9 @@ pcibios_make_OF_bus_map(void)
*/
int pci_device_from_OF_node(struct device_node *node, u8 *bus, u8 *devfn)
{
+#ifdef CONFIG_PPC_PCI_OF_BUS_MAP
struct pci_dev *dev = NULL;
+#endif
const __be32 *reg;
int size;
@@ -175,6 +178,9 @@ int pci_device_from_OF_node(struct device_node *node, u8
*bus, u8 *devfn)
*bus = (be32_to_cpup([0]) >> 16) & 0xff;
*devfn = (be32_to_cpup([0]) >> 8) & 0xff;
+#ifndef CONFIG_PPC_PCI_OF_BUS_MAP
+ return 0;
+#else
/* Ok, here we need some tweak. If we have already renumbered
* all busses, we can't rely on the OF bus number any more.
* the pci_to_OF_bus_map is not enough as several PCI busses
@@ -192,11 +198,12 @@ int pci_device_from_OF_node(struct device_node *node, u8
*bus, u8 *devfn)
}
return -ENODEV;
+#endif // CONFIG_PPC_PCI_OF_BUS_MAP
}
EXPORT_SYMBOL(pci_device_from_OF_node);
#endif
-#ifdef CONFIG_PPC_CHRP
+#ifdef CONFIG_PPC_PCI_OF_BUS_MAP
/* We create the "pci-OF-bus-map" property now so it appears in the
* /proc device tree
*/
@@ -221,9 +228,7 @@ pci_create_OF_bus_map(void)
of_node_put(dn);
}
}
-#endif
-
-#endif /* defined(CONFIG_PPC_PMAC) || defined(CONFIG_PPC_CHRP) */
+#endif // CONFIG_PPC_PCI_OF_BUS_MAP
void pc
Re: [PATCH 12/22] powerpc/cpu: Mark start_secondary_resume() __noreturn
Josh Poimboeuf writes: > start_secondary_resume() doesn't return. Annotate it as such. By > extension this also makes arch_cpu_idle_dead() noreturn. Can we also mark arch_cpu_idle_dead() (the C function) __noreturn ? Seems like it would be good documentation, even if it's not required once the generic prototype is __noreturn. But not a show-stopper. Acked-by: Michael Ellerman (powerpc) cheers > diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h > index f63505d74932..cfd42ca8765c 100644 > --- a/arch/powerpc/include/asm/smp.h > +++ b/arch/powerpc/include/asm/smp.h > @@ -66,7 +66,7 @@ void start_secondary(void *unused); > extern int smp_send_nmi_ipi(int cpu, void (*fn)(struct pt_regs *), u64 > delay_us); > extern int smp_send_safe_nmi_ipi(int cpu, void (*fn)(struct pt_regs *), u64 > delay_us); > extern void smp_send_debugger_break(void); > -extern void start_secondary_resume(void); > +extern void __noreturn start_secondary_resume(void); > extern void smp_generic_give_timebase(void); > extern void smp_generic_take_timebase(void); > > -- > 2.39.0
Re: [PATCH v2] powerpc/kexec_file: account hot-pluggable memory while estimating FDT size
On Tue, 31 Jan 2023 08:36:15 +0530, Sourabh Jain wrote: > On Systems where online memory is lesser compared to max memory, the > kexec_file_load system call may fail to load the kdump kernel with the > below errors: > > "Failed to update fdt with linux,drconf-usable-memory property" > "Error setting up usable-memory property for kdump kernel" > > [...] Applied to powerpc/fixes. [1/1] powerpc/kexec_file: account hot-pluggable memory while estimating FDT size https://git.kernel.org/powerpc/c/fc546faa559538fb312c77e055243ece18ab3288 cheers
Re: [PATCH] powerpc/kvm: Fix objtool warning for unannotated intra-function call in booke.o
On Sat, 28 Jan 2023 18:11:58 +0530, Sathvika Vasireddy wrote: > Objtool throws the following warning: > arch/powerpc/kvm/booke.o: warning: objtool: kvmppc_fill_pt_regs+0x30: > unannotated intra-function call > > Fix this warning by allowing the function to set the value of 'nip' field > using _THIS_IP_ macro, without having to use an additional assembly > instruction to save the instruction pointer. > > [...] Applied to powerpc/fixes. [1/1] powerpc/kvm: Fix objtool warning for unannotated intra-function call in booke.o https://git.kernel.org/powerpc/c/fe6de81b610e5d0b9d2231acff2de74a35482e7d cheers
Re: [PATCH v2] powerpc/64: Fix perf profiling asynchronous interrupt handlers
On Sat, 21 Jan 2023 20:01:56 +1000, Nicholas Piggin wrote: > Interrupt entry sets the soft mask to IRQS_ALL_DISABLED to match the > hard irq disabled state. So when should_hard_irq_enable() returns true > because we want PMI interrupts in irq handlers, MSR[EE] is enabled but > PMIs just get soft-masked. Fix this by clearing IRQS_PMI_DISABLED before > enabling MSR[EE]. > > This also tidies some of the warnings, no need to duplicate them in > both should_hard_irq_enable() and do_hard_irq_enable(). > > [...] Applied to powerpc/fixes. [1/1] powerpc/64: Fix perf profiling asynchronous interrupt handlers https://git.kernel.org/powerpc/c/c28548012ee2bac55772ef7685138bd1124b80c3 cheers
Re: [PATCH] powerpc/64s: Fix local irq disable when PMIs are disabled
On Sat, 21 Jan 2023 19:53:52 +1000, Nicholas Piggin wrote:
> When PMI interrupts are soft-masked, local_irq_save() will clear the PMI
> mask bit, allowing PMIs in and causing a race condition. This causes a
> deadlock in native_hpte_insert via hash_preload, which depends on PMIs
> being disabled since commit 8b91cee5eadd ("powerpc/64s/hash: Make hash
> faults work in NMI context"). native_hpte_insert calls local_irq_save().
> It's possible the lpar hash code is also affected when tracing is
> enabled because __trace_hcall_entry() calls local_irq_save().
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/64s: Fix local irq disable when PMIs are disabled
https://git.kernel.org/powerpc/c/bc88ef663265676419555df2dc469a471c0add31
cheers
Re: [PATCH] powerpc: Fix objtool warning for unannotated intra-function call in head_85xx.o
On Sat, 28 Jan 2023 18:11:38 +0530, Sathvika Vasireddy wrote: > Objtool throws the following warning: > arch/powerpc/kernel/head_85xx.o: warning: objtool: .head.text+0x1a6c: > unannotated intra-function call > > Fix this warning by annotating KernelSPE symbol with SYM_FUNC_START_LOCAL > and SYM_FUNC_END macros. > > [...] Applied to powerpc/fixes. [1/1] powerpc: Fix objtool warning for unannotated intra-function call in head_85xx.o https://git.kernel.org/powerpc/c/8afffce6aa3bddc940ac1909627ff1e772b6cbf1 cheers
Re: [PATCH] powerpc/kexec_file: Fix division by zero in extra size estimation
On Mon, 30 Jan 2023 12:47:07 +1100, Michael Ellerman wrote: > In kexec_extra_fdt_size_ppc64() there's logic to estimate how much > extra space will be needed in the device tree for some memory related > properties. > > That logic uses the size of RAM divided by drmem_lmb_size() to do the > estimation. However drmem_lmb_size() can be zero if the machine has no > hotpluggable memory configured, which is the case when booting with qemu > and no maxmem=x parameter is passed (the default). > > [...] Applied to powerpc/fixes. [1/1] powerpc/kexec_file: Fix division by zero in extra size estimation https://git.kernel.org/powerpc/c/7294194b47e994753a86eee8cf1c61f3f36458a3 cheers
Re: [PATCH] powerpc/imc-pmu: Revert nest_init_lock to being a mutex
On Mon, 30 Jan 2023 12:44:01 +1100, Michael Ellerman wrote:
> The recent commit 76d588dddc45 ("powerpc/imc-pmu: Fix use of mutex in
> IRQs disabled section") fixed warnings (and possible deadlocks) in the
> IMC PMU driver by converting the locking to use spinlocks.
>
> It also converted the init-time nest_init_lock to a spinlock, even
> though it's not used at runtime in IRQ disabled sections or while
> holding other spinlocks.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/imc-pmu: Revert nest_init_lock to being a mutex
https://git.kernel.org/powerpc/c/ad53db4acb415976761d7302f5b02e97f2bd097e
cheers
Re: [PATCH] powerpc/64s: Reconnect tlb_flush() to hash__tlb_flush()
On Tue, 31 Jan 2023 22:14:07 +1100, Michael Ellerman wrote:
> Commit baf1ed24b27d ("powerpc/mm: Remove empty hash__ functions")
> removed some empty hash MMU flushing routines, but got a bit overeager
> and also removed the call to hash__tlb_flush() from tlb_flush().
>
> In regular use this doesn't lead to any noticable breakage, which is a
> little concerning. Presumably there are flushes happening via other
> paths such as arch_leave_lazy_mmu_mode(), and/or a bit of luck.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/64s: Reconnect tlb_flush() to hash__tlb_flush()
https://git.kernel.org/powerpc/c/1665c027afb225882a5a0b014c45e84290b826c2
cheers
Re: [PATCH 1/2] powerpc/64s/radix: Fix crash with unaligned relocated kernel
On Tue, 10 Jan 2023 23:47:52 +1100, Michael Ellerman wrote: > If a relocatable kernel is loaded at an address that is not 2MB aligned > and told not to relocate to zero, the kernel can crash due to > mark_rodata_ro() incorrectly changing some read-write data to read-only. > > Scenarios where the misalignment can occur are when the kernel is > loaded by kdump or using the RELOCATABLE_TEST config option. > > [...] Applied to powerpc/fixes. [1/2] powerpc/64s/radix: Fix crash with unaligned relocated kernel https://git.kernel.org/powerpc/c/98d0219e043e09013e883eacde3b93e0b2bf944d [2/2] powerpc/64s/radix: Fix RWX mapping with relocated kernel https://git.kernel.org/powerpc/c/111bcb37385353f0510e5847d5abcd1c613dba23 cheers
[GIT PULL] Please pull powerpc/linux.git powerpc-6.2-4 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some more powerpc fixes for 6.2. It's a bit of a big batch for rc6, but just because I didn't send any fixes the last week or two while I was on vacation, next week should be quieter. cheers The following changes since commit f12cd06109f47c2fb4b23a45ab55404c47ef7fae: powerpc/64s/hash: Make stress_hpt_timer_fn() static (2023-01-12 10:53:37 +1100) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-6.2-4 for you to fetch changes up to 1665c027afb225882a5a0b014c45e84290b826c2: powerpc/64s: Reconnect tlb_flush() to hash__tlb_flush() (2023-02-02 13:25:47 +1100) - -- powerpc fixes for 6.2 #4 - Fix a few objtool warnings since we recently enabled objtool. - Fix a deadlock with the hash MMU vs perf record. - Fix perf profiling of asynchronous interrupt handlers. - Revert the IMC PMU nest_init_lock to being a mutex. - Two commits fixing problems with the kexec_file FDT size estimation. - Two commits fixing problems with strict RWX vs kernels running at non-zero. - Reconnect tlb_flush() to hash__tlb_flush() Thanks to: Kajol Jain, Nicholas Piggin, Sachin Sant Sathvika Vasireddy, Sourabh Jain. - -- Michael Ellerman (5): powerpc/imc-pmu: Revert nest_init_lock to being a mutex powerpc/kexec_file: Fix division by zero in extra size estimation powerpc/64s/radix: Fix crash with unaligned relocated kernel powerpc/64s/radix: Fix RWX mapping with relocated kernel powerpc/64s: Reconnect tlb_flush() to hash__tlb_flush() Nicholas Piggin (2): powerpc/64s: Fix local irq disable when PMIs are disabled powerpc/64: Fix perf profiling asynchronous interrupt handlers Sathvika Vasireddy (2): powerpc/85xx: Fix unannotated intra-function call warning powerpc/kvm: Fix unannotated intra-function call warning Sourabh Jain (1): powerpc/kexec_file: Count hot-pluggable memory in FDT estimate arch/powerpc/include/asm/book3s/64/tlbflush.h | 2 + arch/powerpc/include/asm/hw_irq.h | 43 ++-- arch/powerpc/kernel/dbell.c | 2 +- arch/powerpc/kernel/head_85xx.S | 3 +- arch/powerpc/kernel/irq.c | 2 +- arch/powerpc/kernel/time.c| 2 +- arch/powerpc/kexec/file_load_64.c | 11 +++-- arch/powerpc/kvm/booke.c | 5 +-- arch/powerpc/mm/book3s64/radix_pgtable.c | 24 +++ arch/powerpc/perf/imc-pmu.c | 14 +++ 10 files changed, 77 insertions(+), 31 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmPfBM8ACgkQUevqPMjh pYAFDQ/8CgBQ+Cf7q1yNm35L+IjA2kLub392pXEPVFf5+81hdib8VdSdLVsngXwZ e7bwbId16xzLVGB3MDm8MqokCxwWcd3n8RjCMKal408c1qqcdlLHEi52MmQK2e2W CIfGM5HbrqlEy8y4IfHQZ5W8DdjVh+8EzlfIMYJyyLB6508o1G9BB0ToFo/VtrZH pB2cnXKLpthZ18l9n6t5z49rSOLukndwJif7Dloi8nTkz4NJ+uD8g1eQEQtiXPmC KkBc19HWvHkHYGGg6nHCT0nvUEJ6jY4RBzTTyJnRdSrZwMACwiCqHS4p1EoKuU1+ kC7SN2VpJDSpGpxGItxPA+GgtaPuwWy/bY9ffEbRI46qpS2J/W2ChcAPhhdE1roY IBIPD/p3hiAJNBtK4tpsv0hoErPnOIVKgsAsgKy/4dxojElCGGXn2FqbdFfOmp4u Vh8vy6ploiiuQZjLB/znNyzD72jjqfyNPAaT05rLIgnAYdOnFYHm7KLoEyxL48gj nxsDmXen8JWuVvRMpA7magZ4MHmjJ5GOaZfjqEM5d0nFIuQErlYyztQ88QfMX7Gu TW92hAFe6F5d5FNbN+AG4l/qr6fHJ96ViIED1q+2zNj+Uh/JTMTHk0b/BuSM+6u+ SNeQrlqksha1OlgGtxb5fskdly8lPVytPXgCrWjuvU8K/jaqQN8= =kk/e -END PGP SIGNATURE-
Re: [PATCH 1/2] powerpc/64: Set default CPU in Kconfig
On Wed, 25 Jan 2023 08:38:59 +0100, Christophe Leroy wrote:
> Since 0069f3d14e7a ("powerpc/64e: Tie PPC_BOOK3E_64 to PPC_E500MC"), the
> only possible BOOK3E/64 are E500, so no need of a default CPU over the
> E5500.
>
> When the user selects book3e, they must have an e500 compatible
> compiler, and it won't work anymore with the default -mcpu=power64, see
> commit d6b551b8f90c ("powerpc/64e: Fix build failure with GCC 12
> (unrecognized opcode: `wrteei')").
>
> [...]
Applied to powerpc/next.
[1/2] powerpc/64: Set default CPU in Kconfig
https://git.kernel.org/powerpc/c/45f7091aac3546ef8112bf62836650ca0bbf0b79
[2/2] powerpc/boot: Don't always pass -mcpu=powerpc when building 32-bit uImage
https://git.kernel.org/powerpc/c/ff7c76f66d8bad4e694c264c789249e1d3a8205d
cheers
Re: [PATCH v2 0/4] powerpc/rtas: exports and locking
On Tue, 24 Jan 2023 08:04:44 -0600, Nathan Lynch wrote: > This series began as a single patch[1] to convert the RTAS subsystem's > internal locks to raw spinlocks. The discussion of that patch > identified opportunities to update a few aspects of the RTAS API, so > the series begins with those and ends with a rebased version of the > original patch. > > Changes since v1: > - Unexport the singleton 'rtas' struct. > - Remove lock and args fields from 'struct rtas_t', making them > private to the RTAS subsystem. > - Convert all symbol exports in rtas.c to EXPORT_SYMBOL_GPL. > > [...] Applied to powerpc/next. [1/4] powerpc/rtas: unexport 'rtas' symbol https://git.kernel.org/powerpc/c/5ff92e2f274dc42a9e534473121273cd209d3501 [2/4] powerpc/rtas: make all exports GPL https://git.kernel.org/powerpc/c/9bce6243848dfd0ff7c2be6e8d82ab9b1e6c7858 [3/4] powerpc/rtas: remove lock and args fields from global rtas struct https://git.kernel.org/powerpc/c/599af49155467148afaf0bc3c0114bd80fd4491f [4/4] powerpc/rtas: upgrade internal arch spinlocks https://git.kernel.org/powerpc/c/12fd66651df6c807b7b6f420ee0fd420f54991f4 cheers
Re: [PATCH 0/2] powerpc: Fix livepatch module re-patching issue
On Tue, 24 Jan 2023 19:38:03 -0800, Josh Poimboeuf wrote: > Fix a livepatch bug seen when reloading a patched module. > > This is the powerpc counterpart to Song Liu's fix for a similar issue on > x86: > > https://lkml.kernel.org/lkml/20230121004945.697003-2-s...@kernel.org > > [...] Applied to powerpc/next. [1/2] powerpc/module_64: Improve restore_r2() return semantics https://git.kernel.org/powerpc/c/bc2c6f5695ffa05c838b8b6fc5cd581a672151a1 [2/2] powerpc/module_64: Fix "expected nop" error on module re-patching https://git.kernel.org/powerpc/c/37251c7114e1b743b077ca74b93557c1ad92a97e cheers
Re: [PATCH] powerpc: Check !irq instead of irq == NO_IRQ and remove NO_IRQ
On Mon, 23 Jan 2023 13:26:46 +0100, Christophe Leroy wrote: > NO_IRQ is a relic from the old days. It is not used anymore in core > functions. By the way, function irq_of_parse_and_map() returns value 0 > on error. > > In some drivers, NO_IRQ is erroneously used to check the return of > irq_of_parse_and_map(). > > [...] Applied to powerpc/next. [1/1] powerpc: Check !irq instead of irq == NO_IRQ and remove NO_IRQ https://git.kernel.org/powerpc/c/bab537805a10bdbf55b31324ba4a9599e0651e5e cheers
Re: [PATCH 0/2] powerpc: Fix livepatch module re-patching issue
Josh Poimboeuf writes:
> On Tue, Jan 24, 2023 at 07:38:03PM -0800, Josh Poimboeuf wrote:
>> Fix a livepatch bug seen when reloading a patched module.
>>
>> This is the powerpc counterpart to Song Liu's fix for a similar issue on
>> x86:
>>
>> https://lkml.kernel.org/lkml/20230121004945.697003-2-s...@kernel.org
>>
>> Josh Poimboeuf (2):
>> powerpc/module_64: Improve restore_r2() return semantics
>> powerpc/module_64: Fix "expected nop" error on module re-patching
>>
>> arch/powerpc/kernel/module_64.c | 29 ++---
>> 1 file changed, 18 insertions(+), 11 deletions(-)
>
> Hi Michael,
>
> Ping? Any objections to this?
>
> The x86 counterpart to this is queued for 6.3, it would be nice if this
> also landed. We could take it through the livepatch tree if needed.
It's in my next since about a week. Sorry I forgot to send the
"accepted" emails (which I still don't have automated :/ ).
337251c7114e1 ("powerpc/module_64: Fix "expected nop" error on module
re-patching")
cheers
[PATCH] powerpc: Don't select ARCH_WANTS_NO_INSTR
Commit 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only KASAN
support") added a select of ARCH_WANTS_NO_INSTR, because it also added
some uses of noinstr. However noinstr is always defined, regardless of
ARCH_WANTS_NO_INSTR, so there's no need to select it just for that.
As PeterZ says [1]:
Note that by selecting ARCH_WANTS_NO_INSTR you effectively state to
abide by its rules.
As of now the powerpc code does not abide by those rules, and trips some
new warnings added by Peter in linux-next.
So until the code can be fixed to avoid those warnings, disable
ARCH_WANTS_NO_INSTR.
Note that ARCH_WANTS_NO_INSTR is also used to gate building KCOV and
parts of KCSAN. However none of the noinstr annotations in powerpc were
added for KCOV or KCSAN, instead instrumentation is blocked at the file
level using KCOV_INSTRUMENT_foo.o := n.
[1]:
https://lore.kernel.org/linuxppc-dev/y9t6yoafro5yq...@hirez.programming.kicks-ass.net
Reported-by: Sachin Sant
Suggested-by: Peter Zijlstra
Signed-off-by: Michael Ellerman
---
arch/powerpc/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b8c4ac56bddc..7a5f8dbfbdd0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -163,7 +163,6 @@ config PPC
select ARCH_WANT_IRQS_OFF_ACTIVATE_MM
select ARCH_WANT_LD_ORPHAN_WARN
select ARCH_WANTS_MODULES_DATA_IN_VMALLOC if PPC_BOOK3S_32 ||
PPC_8xx
- select ARCH_WANTS_NO_INSTR
select ARCH_WEAK_RELEASE_ACQUIRE
select BINFMT_ELF
select BUILDTIME_TABLE_SORT
--
2.39.1
Re: [PATCH] powerpc/kexec_file: Fix division by zero in extra size estimation
Sourabh Jain writes:
> On 30/01/23 07:17, Michael Ellerman wrote:
>> In kexec_extra_fdt_size_ppc64() there's logic to estimate how much
>> extra space will be needed in the device tree for some memory related
>> properties.
>>
>> That logic uses the size of RAM divided by drmem_lmb_size() to do the
>> estimation. However drmem_lmb_size() can be zero if the machine has no
>> hotpluggable memory configured, which is the case when booting with qemu
>> and no maxmem=x parameter is passed (the default).
>>
>> The division by zero is reported by UBSAN, and can also lead to an
>> overflow and a warning from kvmalloc, and kdump kernel loading fails:
>>
>>WARNING: CPU: 0 PID: 133 at mm/util.c:596 kvmalloc_node+0x15c/0x160
>>Modules linked in:
>>CPU: 0 PID: 133 Comm: kexec Not tainted 6.2.0-rc5-03455-g07358bd97810 #223
>>Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1200
>> 0xf05 of:SLOF,git-dd0dca pSeries
>>NIP: c041ff4c LR: c041fe58 CTR:
>>REGS: c96ef750 TRAP: 0700 Not tainted
>> (6.2.0-rc5-03455-g07358bd97810)
>>MSR: 8282b033 CR: 24248242
>> XER: 2004011e
>>CFAR: c041fed0 IRQMASK: 0
>>...
>>NIP kvmalloc_node+0x15c/0x160
>>LR kvmalloc_node+0x68/0x160
>>Call Trace:
>> kvmalloc_node+0x68/0x160 (unreliable)
>> of_kexec_alloc_and_setup_fdt+0xb8/0x7d0
>> elf64_load+0x25c/0x4a0
>> kexec_image_load_default+0x58/0x80
>> sys_kexec_file_load+0x5c0/0x920
>> system_call_exception+0x128/0x330
>> system_call_vectored_common+0x15c/0x2ec
>>
>> To fix it, skip the calculation if drmem_lmb_size() is zero.
>>
>> Fixes: 2377c92e37fe ("powerpc/kexec_file: fix FDT size estimation for kdump
>> kernel")
>> Cc: sta...@vger.kernel.org # v5.12+
>> Signed-off-by: Michael Ellerman
>> ---
>> arch/powerpc/kexec/file_load_64.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/kexec/file_load_64.c
>> b/arch/powerpc/kexec/file_load_64.c
>> index af8854f9eae3..3caee570e79b 100644
>> --- a/arch/powerpc/kexec/file_load_64.c
>> +++ b/arch/powerpc/kexec/file_load_64.c
>> @@ -989,10 +989,12 @@ unsigned int kexec_extra_fdt_size_ppc64(struct kimage
>> *image)
>> * linux,drconf-usable-memory properties. Get an approximate on the
>> * number of usable memory entries and use for FDT size estimation.
>> */
>> -usm_entries = ((memblock_end_of_DRAM() / drmem_lmb_size()) +
>> - (2 * (resource_size(_res) / drmem_lmb_size(;
>> -
>> -extra_size = (unsigned int)(usm_entries * sizeof(u64));
>> +if (drmem_lmb_size()) {
>> +usm_entries = ((memblock_end_of_DRAM() / drmem_lmb_size()) +
>> + (2 * (resource_size(_res) /
>> drmem_lmb_size(;
>> +extra_size = (unsigned int)(usm_entries * sizeof(u64));
>> +} else
>> +extra_size = 0;
>>
>> /*
>> * Get the number of CPU nodes in the current DT. This allows to
>
> I failed to replicate this issue.
>
> Qemu command used:
> $ qemu-system-ppc64 -enable-kvm -smp 4,cores=2 -drive
> file=my-image.qcow2 -nographic -m 2G
>
>
> lsmem (inside guest):
> RANGE SIZE STATE REMOVABLE BLOCK
> 0x-0x7fff 2G online yes 0-127
>
> Memory block size: 16M
> Total online memory: 2G
> Total offline memory: 0B
>
> Not sure what I am missing, but changes looks good to me.
Hmm, interesting.
Do you have /proc/device-tree/ibm,dynamic-reconfiguration-memory in the VM?
What version of qemu are you using? I think I tested with 6.2 and 7.1.
cheers
Re: [PATCH v2] powerpc/mce: log the error for all unrecoverable errors
Ganesh Goudar writes: > For all unrecoverable errors we are missing to log the > error, Since machine_check_log_err() is not getting called > for unrecoverable errors. > > Raise irq work in save_mce_event() for unrecoverable errors, > So that we log the error from MCE event handling block in > timer handler. But the patch also removes the irq work raise from machine_check_ue_event(). That's currently done unconditionally, regardless of the disposition. So doesn't this change also drop logging of recoverable UEs? Maybe that's OK, but the change log should explain it. > Log without this change > > MCE: CPU27: machine check (Severe) Real address Load/Store (foreign/control > memory) [Not recovered] > MCE: CPU27: PID: 10580 Comm: inject-ra-err NIP: [1df4] > MCE: CPU27: Initiator CPU > MCE: CPU27: Unknown > > Log with this change > > MCE: CPU24: machine check (Severe) Real address Load/Store (foreign/control > memory) [Not recovered] > MCE: CPU24: PID: 1589811 Comm: inject-ra-err NIP: [1e48] > MCE: CPU24: Initiator CPU > MCE: CPU24: Unknown > RTAS: event: 5, Type: Platform Error (224), Severity: 3 > > Signed-off-by: Ganesh Goudar > Reviewed-by: Mahesh Salgaonkar > --- > V2: Rephrasing the commit message. > --- > arch/powerpc/kernel/mce.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c > index 6c5d30fba766..a1cb2172eb7b 100644 > --- a/arch/powerpc/kernel/mce.c > +++ b/arch/powerpc/kernel/mce.c > @@ -131,6 +131,13 @@ void save_mce_event(struct pt_regs *regs, long handled, > if (mce->error_type == MCE_ERROR_TYPE_UE) > mce->u.ue_error.ignore_event = mce_err->ignore_event; > > + /* > + * Raise irq work, So that we don't miss to log the error for > + * unrecoverable errors. > + */ > + if (mce->disposition == MCE_DISPOSITION_NOT_RECOVERED) > + mce_irq_work_queue(); > + > if (!addr) > return; > > @@ -235,7 +242,6 @@ static void machine_check_ue_event(struct > machine_check_event *evt) > evt, sizeof(*evt)); > > /* Queue work to process this event later. */ This comment is meaningless without the function call it's commenting about, ie. the comment should be removed too. > - mce_irq_work_queue(); > } > cheers
[PATCH] powerpc/64s: Reconnect tlb_flush() to hash__tlb_flush()
Commit baf1ed24b27d ("powerpc/mm: Remove empty hash__ functions")
removed some empty hash MMU flushing routines, but got a bit overeager
and also removed the call to hash__tlb_flush() from tlb_flush().
In regular use this doesn't lead to any noticable breakage, which is a
little concerning. Presumably there are flushes happening via other
paths such as arch_leave_lazy_mmu_mode(), and/or a bit of luck.
Fix it by reinstating the call to hash__tlb_flush().
Fixes: baf1ed24b27d ("powerpc/mm: Remove empty hash__ functions")
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/book3s/64/tlbflush.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h
b/arch/powerpc/include/asm/book3s/64/tlbflush.h
index dd39313242b4..d5cd16270c5d 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
@@ -97,6 +97,8 @@ static inline void tlb_flush(struct mmu_gather *tlb)
{
if (radix_enabled())
radix__tlb_flush(tlb);
+
+ return hash__tlb_flush(tlb);
}
#ifdef CONFIG_SMP
--
2.39.1
Re: [PATCH v2] powerpc: Implement arch_within_stack_frames
Nicholas Miehlbradt writes:
> Walks the stack when copy_{to,from}_user address is in the stack to
> ensure that the object being copied is entirely within a single stack
> frame.
... and that it exists above the parameter save area, so is not pointing
at any stack metadata right?
> Substatially similar to the x86 implementation except using the back
^
n
> chain to traverse the stack and identify stack frame boundaries.
The x86 version does use the back chain (frame pointer) doesn't it?
Possibly this comment is just out of date now?
> Signed-off-by: Nicholas Miehlbradt
> ---
> v2: Rename PARAMETER_SAVE_OFFSET to STACK_FRAME_PARAMS
> Add definitions of STACK_FRAME_PARAMS for PPC32 and remove dependancy on
> PPC64
> Ignore the current stack frame and start with it's parent, similar to x86
>
> v1:
> https://lore.kernel.org/linuxppc-dev/20221214044252.1910657-1-nicho...@linux.ibm.com/
> ---
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/thread_info.h | 36 ++
> 2 files changed, 37 insertions(+)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 2ca5418457ed..97ca54773521 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -198,6 +198,7 @@ config PPC
> select HAVE_ARCH_KASAN_VMALLOC if HAVE_ARCH_KASAN
> select HAVE_ARCH_KFENCE if ARCH_SUPPORTS_DEBUG_PAGEALLOC
> select HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET
> + select HAVE_ARCH_WITHIN_STACK_FRAMES
> select HAVE_ARCH_KGDB
> select HAVE_ARCH_MMAP_RND_BITS
> select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
> diff --git a/arch/powerpc/include/asm/thread_info.h
> b/arch/powerpc/include/asm/thread_info.h
> index af58f1ed3952..c5dce5f239c1 100644
> --- a/arch/powerpc/include/asm/thread_info.h
> +++ b/arch/powerpc/include/asm/thread_info.h
> @@ -186,6 +186,42 @@ static inline bool test_thread_local_flags(unsigned int
> flags)
> #define is_elf2_task() (0)
> #endif
>
> +#if defined(CONFIG_PPC64_ELF_ABI_V1)
> +#define STACK_FRAME_PARAMS 48
> +#elif defined(CONFIG_PPC64_ELF_ABI_V2)
> +#define STACK_FRAME_PARAMS 32
> +#elif defined(CONFIG_PPC32)
> +#define STACK_FRAME_PARAMS 8
> +#endif
Can you please put those in ppc_asm.h?
There's an ifdef starting around line 187 where they should fit nicely,
it has the __STK_PARAM macros already. The ppc32 case is at line 245.
In a subsequent patch we could make the __STK_PARAM macros use your new
#defines for the offsets.
> +
> +/*
> + * Walks up the stack frames to make sure that the specified object is
> + * entirely contained by a single stack frame.
> + *
> + * Returns:
> + * GOOD_FRAME if within a frame
> + * BAD_STACK if placed across a frame boundary (or outside stack)
> + */
> +static inline int arch_within_stack_frames(const void * const stack,
> +const void * const stackend,
> +const void *obj, unsigned long len)
> +{
> + const void *params;
> + const void *frame;
> +
> + params = *(const void * const *)current_stack_pointer +
> STACK_FRAME_PARAMS;
> + frame = **(const void * const * const *)current_stack_pointer;
> +
> + while (stack <= frame && frame < stackend) {
> + if (obj + len <= frame)
> + return obj >= params ? GOOD_FRAME : BAD_STACK;
> + params = frame + STACK_FRAME_PARAMS;
> + frame = *(const void * const *)frame;
> + }
I think the logic here is OK, but the variable naming makes it a bit
hard to follow.
Normally the stack pointer points at the lowest address of a frame, so
the "params" of that frame are at a higher address.
But here we have "frame" pointing at the caller frame (higher address)
as we check that obj sits above the params of the callee frame (lower
address).
So "params" and "frame" are different frames. I can't immediately come
up with a naming that makes it clearer though.
I think it could also be helped with a comment using some ASCII art :)
cheers
Re: [PATCH] powerpc/tlb: Remove BUILD_BUG for book3s/32/tlbflush.h local_flush_tlb_page_psize
Benjamin Gray writes: > On Wed, 2023-01-25 at 22:35 +1100, Michael Ellerman wrote: >> Can't we just fall back to flush_tlb_page(vma, vmaddr)? >> >> I'd guess those CPUs can't flush based on page size anyway. >> >> cheers > > Probably. Do they have a fixed page size? AFAIK yes. cheers
Re: [PATCH v2 4/4] mm, arch: add generic implementation of pfn_valid() for FLATMEM
Mike Rapoport writes: > From: "Mike Rapoport (IBM)" > > Every architecture that supports FLATMEM memory model defines its own > version of pfn_valid() that essentially compares a pfn to max_mapnr. > > Use mips/powerpc version implemented as static inline as a generic > implementation of pfn_valid() and drop its per-architecture definitions. > > Signed-off-by: Mike Rapoport (IBM) > Acked-by: Arnd Bergmann > Acked-by: Guo Ren # csky > Acked-by: Huacai Chen # LoongArch > Acked-by: Stafford Horne# OpenRISC > --- > arch/alpha/include/asm/page.h | 4 > arch/arc/include/asm/page.h| 1 - > arch/csky/include/asm/page.h | 1 - > arch/hexagon/include/asm/page.h| 1 - > arch/ia64/include/asm/page.h | 4 > arch/loongarch/include/asm/page.h | 13 - > arch/m68k/include/asm/page_no.h| 2 -- > arch/microblaze/include/asm/page.h | 1 - > arch/mips/include/asm/page.h | 13 - > arch/nios2/include/asm/page.h | 9 - > arch/openrisc/include/asm/page.h | 2 -- > arch/parisc/include/asm/page.h | 4 > arch/powerpc/include/asm/page.h| 9 - Acked-by: Michael Ellerman (powerpc) cheers
Re: [PATCH v2] powerpc: macio: Make remove callback of macio driver void returned
Dawei Li writes:
> Commit fc7a6209d571 ("bus: Make remove callback return void") forces
> bus_type::remove be void-returned, it doesn't make much sense for any
> bus based driver implementing remove callbalk to return non-void to
> its caller.
>
> This change is for macio bus based drivers.
>
> Signed-off-by: Dawei Li
> ---
> v1 -> v2
> - Revert unneeded changes.
> - Rebased on latest powerpc/next.
>
> v1
> -
> https://lore.kernel.org/all/tycp286mb2323fcdc7ecd87f8d97cb74bca...@tycp286mb2323.jpnp286.prod.outlook.com/
> ---
> arch/powerpc/include/asm/macio.h| 2 +-
> drivers/ata/pata_macio.c| 4 +---
> drivers/macintosh/rack-meter.c | 4 +---
> drivers/net/ethernet/apple/bmac.c | 4 +---
> drivers/net/ethernet/apple/mace.c | 4 +---
> drivers/net/wireless/intersil/orinoco/airport.c | 4 +---
> drivers/scsi/mac53c94.c | 5 +
> drivers/scsi/mesh.c | 5 +
> drivers/tty/serial/pmac_zilog.c | 7 ++-
> sound/aoa/soundbus/i2sbus/core.c| 4 +---
> 10 files changed, 11 insertions(+), 32 deletions(-)
I realise the patch has to be merged via a single subsystem, and powerpc
is probably the most appropriate, but please Cc the relevant lists for
the drivers touched.
AFAICS neither this version or v1 was Cc'ed to relevant lists, eg.
netdev, linux-wireless, linux-scsi, alsa-devel etc.
cheers
Re: [PATCH] powerpc/kexec_file: account hot-pluggable memory while estimating FDT size
Sourabh Jain writes:
> On Systems where online memory is lesser compared to max memory, the
> kexec_file_load system call may fail to load the kdump kernel with the
> below errors:
>
> "Failed to update fdt with linux,drconf-usable-memory property"
> "Error setting up usable-memory property for kdump kernel"
>
> This happens because the size estimation for usable memory properties
> for the kdump kernel's FDT is based on the online memory whereas the
> usable memory properties include max memory. In short, the hot-pluggable
> memory is not accounted for while estimating the size of the usable
> memory properties.
>
> The issue is addressed by calculating usable memory property size using
> max hotplug address instead of the last online memory address.
>
> Fixes: 2377c92e37fe ("powerpc/kexec_file: fix FDT size estimation for kdump
> kernel")
> Signed-off-by: Sourabh Jain
> ---
> arch/powerpc/kexec/file_load_64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Can you please rebase it on top of the fix I posted.
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20230130014707.541110-1-...@ellerman.id.au/
cheers
[PATCH] powerpc/kexec_file: Fix division by zero in extra size estimation
In kexec_extra_fdt_size_ppc64() there's logic to estimate how much
extra space will be needed in the device tree for some memory related
properties.
That logic uses the size of RAM divided by drmem_lmb_size() to do the
estimation. However drmem_lmb_size() can be zero if the machine has no
hotpluggable memory configured, which is the case when booting with qemu
and no maxmem=x parameter is passed (the default).
The division by zero is reported by UBSAN, and can also lead to an
overflow and a warning from kvmalloc, and kdump kernel loading fails:
WARNING: CPU: 0 PID: 133 at mm/util.c:596 kvmalloc_node+0x15c/0x160
Modules linked in:
CPU: 0 PID: 133 Comm: kexec Not tainted 6.2.0-rc5-03455-g07358bd97810 #223
Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1200 0xf05
of:SLOF,git-dd0dca pSeries
NIP: c041ff4c LR: c041fe58 CTR:
REGS: c96ef750 TRAP: 0700 Not tainted
(6.2.0-rc5-03455-g07358bd97810)
MSR: 8282b033 CR: 24248242 XER:
2004011e
CFAR: c041fed0 IRQMASK: 0
...
NIP kvmalloc_node+0x15c/0x160
LR kvmalloc_node+0x68/0x160
Call Trace:
kvmalloc_node+0x68/0x160 (unreliable)
of_kexec_alloc_and_setup_fdt+0xb8/0x7d0
elf64_load+0x25c/0x4a0
kexec_image_load_default+0x58/0x80
sys_kexec_file_load+0x5c0/0x920
system_call_exception+0x128/0x330
system_call_vectored_common+0x15c/0x2ec
To fix it, skip the calculation if drmem_lmb_size() is zero.
Fixes: 2377c92e37fe ("powerpc/kexec_file: fix FDT size estimation for kdump
kernel")
Cc: sta...@vger.kernel.org # v5.12+
Signed-off-by: Michael Ellerman
---
arch/powerpc/kexec/file_load_64.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kexec/file_load_64.c
b/arch/powerpc/kexec/file_load_64.c
index af8854f9eae3..3caee570e79b 100644
--- a/arch/powerpc/kexec/file_load_64.c
+++ b/arch/powerpc/kexec/file_load_64.c
@@ -989,10 +989,12 @@ unsigned int kexec_extra_fdt_size_ppc64(struct kimage
*image)
* linux,drconf-usable-memory properties. Get an approximate on the
* number of usable memory entries and use for FDT size estimation.
*/
- usm_entries = ((memblock_end_of_DRAM() / drmem_lmb_size()) +
- (2 * (resource_size(_res) / drmem_lmb_size(;
-
- extra_size = (unsigned int)(usm_entries * sizeof(u64));
+ if (drmem_lmb_size()) {
+ usm_entries = ((memblock_end_of_DRAM() / drmem_lmb_size()) +
+ (2 * (resource_size(_res) /
drmem_lmb_size(;
+ extra_size = (unsigned int)(usm_entries * sizeof(u64));
+ } else
+ extra_size = 0;
/*
* Get the number of CPU nodes in the current DT. This allows to
--
2.39.1
[PATCH] powerpc/imc-pmu: Revert nest_init_lock to being a mutex
The recent commit 76d588dddc45 ("powerpc/imc-pmu: Fix use of mutex in
IRQs disabled section") fixed warnings (and possible deadlocks) in the
IMC PMU driver by converting the locking to use spinlocks.
It also converted the init-time nest_init_lock to a spinlock, even
though it's not used at runtime in IRQ disabled sections or while
holding other spinlocks.
This leads to warnings such as:
BUG: sleeping function called from invalid context at
include/linux/percpu-rwsem.h:49
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
preempt_count: 1, expected: 0
CPU: 7 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc2-14719-gf12cd06109f4-dirty
#1
Hardware name: Mambo,Simulated-System POWER9 0x4e1203 opal:v6.6.6 PowerNV
Call Trace:
dump_stack_lvl+0x74/0xa8 (unreliable)
__might_resched+0x178/0x1a0
__cpuhp_setup_state+0x64/0x1e0
init_imc_pmu+0xe48/0x1250
opal_imc_counters_probe+0x30c/0x6a0
platform_probe+0x78/0x110
really_probe+0x104/0x420
__driver_probe_device+0xb0/0x170
driver_probe_device+0x58/0x180
__driver_attach+0xd8/0x250
bus_for_each_dev+0xb4/0x140
driver_attach+0x34/0x50
bus_add_driver+0x1e8/0x2d0
driver_register+0xb4/0x1c0
__platform_driver_register+0x38/0x50
opal_imc_driver_init+0x2c/0x40
do_one_initcall+0x80/0x360
kernel_init_freeable+0x310/0x3b8
kernel_init+0x30/0x1a0
ret_from_kernel_thread+0x5c/0x64
Fix it by converting nest_init_lock back to a mutex, so that we can call
sleeping functions while holding it. There is no interaction between
nest_init_lock and the runtime spinlocks used by the actual PMU routines.
Fixes: 76d588dddc45 ("powerpc/imc-pmu: Fix use of mutex in IRQs disabled
section")
Signed-off-by: Michael Ellerman
---
arch/powerpc/perf/imc-pmu.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index 100e97daf76b..9d229ef7f86e 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -22,7 +22,7 @@
* Used to avoid races in counting the nest-pmu units during hotplug
* register and unregister
*/
-static DEFINE_SPINLOCK(nest_init_lock);
+static DEFINE_MUTEX(nest_init_lock);
static DEFINE_PER_CPU(struct imc_pmu_ref *, local_nest_imc_refc);
static struct imc_pmu **per_nest_pmu_arr;
static cpumask_t nest_imc_cpumask;
@@ -1629,7 +1629,7 @@ static void imc_common_mem_free(struct imc_pmu *pmu_ptr)
static void imc_common_cpuhp_mem_free(struct imc_pmu *pmu_ptr)
{
if (pmu_ptr->domain == IMC_DOMAIN_NEST) {
- spin_lock(_init_lock);
+ mutex_lock(_init_lock);
if (nest_pmus == 1) {
cpuhp_remove_state(CPUHP_AP_PERF_POWERPC_NEST_IMC_ONLINE);
kfree(nest_imc_refc);
@@ -1639,7 +1639,7 @@ static void imc_common_cpuhp_mem_free(struct imc_pmu
*pmu_ptr)
if (nest_pmus > 0)
nest_pmus--;
- spin_unlock(_init_lock);
+ mutex_unlock(_init_lock);
}
/* Free core_imc memory */
@@ -1796,11 +1796,11 @@ int init_imc_pmu(struct device_node *parent, struct
imc_pmu *pmu_ptr, int pmu_id
* rest. To handle the cpuhotplug callback unregister, we track
* the number of nest pmus in "nest_pmus".
*/
- spin_lock(_init_lock);
+ mutex_lock(_init_lock);
if (nest_pmus == 0) {
ret = init_nest_pmu_ref();
if (ret) {
- spin_unlock(_init_lock);
+ mutex_unlock(_init_lock);
kfree(per_nest_pmu_arr);
per_nest_pmu_arr = NULL;
goto err_free_mem;
@@ -1808,7 +1808,7 @@ int init_imc_pmu(struct device_node *parent, struct
imc_pmu *pmu_ptr, int pmu_id
/* Register for cpu hotplug notification. */
ret = nest_pmu_cpumask_init();
if (ret) {
- spin_unlock(_init_lock);
+ mutex_unlock(_init_lock);
kfree(nest_imc_refc);
kfree(per_nest_pmu_arr);
per_nest_pmu_arr = NULL;
@@ -1816,7 +1816,7 @@ int init_imc_pmu(struct device_node *parent, struct
imc_pmu *pmu_ptr, int pmu_id
}
}
nest_pmus++;
- spin_unlock(_init_lock);
+ mutex_unlock(_init_lock);
break;
case IMC_DOMAIN_CORE:
ret = core_imc_pmu_cpumask_init();
--
2.39.1
[PATCH] powerpc/rtas: Drop unused export symbols
Some RTAS symbols are never used by modular code, drop their exports.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/rtas.c | 4
1 file changed, 4 deletions(-)
FYI: I'll slot this in prior to Nathan's series changing the exports to GPL.
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 6c5716b19d69..149742119b6d 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -341,7 +341,6 @@ int rtas_service_present(const char *service)
{
return rtas_token(service) != RTAS_UNKNOWN_SERVICE;
}
-EXPORT_SYMBOL(rtas_service_present);
#ifdef CONFIG_RTAS_ERROR_LOGGING
@@ -356,7 +355,6 @@ int rtas_get_error_log_max(void)
{
return rtas_error_log_max;
}
-EXPORT_SYMBOL(rtas_get_error_log_max);
static void __init init_error_log_max(void)
{
@@ -622,7 +620,6 @@ unsigned int rtas_busy_delay_time(int status)
return ms;
}
-EXPORT_SYMBOL(rtas_busy_delay_time);
/**
* rtas_busy_delay() - helper for RTAS busy and extended delay statuses
@@ -820,7 +817,6 @@ bool rtas_indicator_present(int token, int *maxindex)
return false;
}
-EXPORT_SYMBOL(rtas_indicator_present);
int rtas_set_indicator(int indicator, int index, int new_value)
{
--
2.39.1
Re: [PATCH v4 02/24] powerpc/pseries: Fix alignment of PLPKS structures and buffers
Andrew Donnellan writes: > On Thu, 2023-01-26 at 17:31 +, David Laight wrote: >> Changing the size to kzalloc() doesn't help. >> The alignment depends on the allocator and is only required to have >> a relatively small alignment (ARCH_MINALIGN?) regardless of the size. >> >> IIRC one of the allocators adds a small header to every item. >> It won't return 16 byte aligned items at all. > > I'm relying on the behaviour described in Documentation/core- > api/memory-allocation.rst: > > The address of a chunk allocated with kmalloc is aligned to at > least ARCH_KMALLOC_MINALIGN bytes. For sizes which are a power of > two, the alignment is also guaranteed to be at least the respective > size. > > Is this wrong? I believe it's correct. For SLAB and SLUB it boils down to: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/slab_common.c?commit=830b3c68c1fb1e9176028d02ef86f3cf76aa2476#n640 That's where the kmalloc slabs are created (see create_kmalloc_cache()) just below. If you create your own slab (with kmem_cache_create()) then the alignment is up to you, so that's why there's no power-of-2 logic in calculate_alignment(). And SLOB (which we don't use) does something similar: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/slob.c?commit=830b3c68c1fb1e9176028d02ef86f3cf76aa2476#n493 cheers
Re: [PATCH v4 02/24] powerpc/pseries: Fix alignment of PLPKS structures and buffers
Segher Boessenkool writes: > On Thu, Jan 26, 2023 at 12:09:53AM +1100, Michael Ellerman wrote: >> Andrew Donnellan writes: >> > A number of structures and buffers passed to PKS hcalls have alignment >> > requirements, which could on occasion cause problems: >> > >> > - Authorisation structures must be 16-byte aligned and must not cross a >> > page boundary >> > >> > - Label structures must not cross page boundaries >> > >> > - Password output buffers must not cross page boundaries >> > >> > Round up the allocations of these structures/buffers to the next power of >> > 2 to make sure this happens. >> >> It's not the *next* power of 2, it's the *nearest* power of 2, including >> the initial value if it's already a power of 2. > > It's not the nearest either, the nearest power of two to 65 is 64. You > could say "but, round up" to which I would say "round?" :-P OK you got me there :) The function name makes it pretty clear that it will round *up* to the nearest power of 2 but you're right the comment should also make that clear. > "Adjust the allocation size to be the smallest power of two greater than > or equal to the given size." > > "Pad to a power of two" in shorthand. "Padded to a power of two if > necessary" if you want to emphasise it can be a no-op. The initial wording implied that it would always over-allocate so yes I think it's important to make it clear that it doesn't round up if it doesn't need to. cheers
Re: [PATCH] kasan: Fix Oops due to missing calls to kasan_arch_is_ready()
Andrew Morton writes:
> On Thu, 26 Jan 2023 08:04:47 +0100 Christophe Leroy
> wrote:
>
>> On powerpc64, you can build a kernel with KASAN as soon as you build it
>> with RADIX MMU support. However if the CPU doesn't have RADIX MMU,
>> KASAN isn't enabled at init and the following Oops is encountered.
>
> Should we backport to -stable? If so, can we identify a suitable Fixes:
> target?
It would be nice if it went to stable, but I'd defer to the Kasan maintainers.
The kasan_arch_is_ready() checks went in a while back, but there wasn't
a meaningful user until the powerpc support went in, so I'd target that:
Fixes: 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only KASAN support")
Cc: sta...@vger.kernel.org # v5.19+
cheers
Re: [PATCH v4 5/7] mm: replace vma->vm_flags indirect modification in ksm_madvise
Suren Baghdasaryan writes: > Replace indirect modifications to vma->vm_flags with calls to modifier > functions to be able to track flag changes and to keep vma locking > correctness. > > Signed-off-by: Suren Baghdasaryan > Acked-by: Michal Hocko > Acked-by: Mel Gorman > Acked-by: Mike Rapoport (IBM) > --- > arch/powerpc/kvm/book3s_hv_uvmem.c | 6 +- Acked-by: Michael Ellerman (powerpc) cheers
Re: [PATCH 1/2] powerpc/pci: Allow to disable filling deprecated pci-OF-bus-map
Pali Rohár writes: > PING? It is more than 5 months since this patch series is there and it > still has not received any comment. There was some related discussion in another thread. I planned to pick it up last merge window, but it breaks the pmac32_defconfig build when CONFIG_PPC_PCI_OF_BUS_MAP_FILL=n: ld: arch/powerpc/platforms/powermac/feature.o: in function `core99_ata100_enable': feature.c:(.text+0xcd0): undefined reference to `pci_device_from_OF_node' ld: arch/powerpc/platforms/powermac/pci.o: in function `pmac_pci_init': pci.c:(.init.text+0x5d4): undefined reference to `pci_device_from_OF_node' ld: pci.c:(.init.text+0x660): undefined reference to `pci_device_from_OF_node' So I dropped it, and haven't had time to work out a fix. cheers > On Friday 16 December 2022 19:12:06 Pali Rohár wrote: >> PING? >> >> On Saturday 26 November 2022 17:23:45 Pali Rohár wrote: >> > PING? >> > >> > On Tuesday 01 November 2022 23:26:03 Pali Rohár wrote: >> > > Hello! Gentle reminder... >> > > >> > > On Sunday 09 October 2022 13:25:55 Pali Rohár wrote: >> > > > Hello! Any comments on this? It would be nice to take these two patches >> > > > (or at least patch 2) to finally enable >> > > > PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT >> > > > by default where possible. >> > > > >> > > > Per following comment there can be an issue with early powermac so >> > > > seems >> > > > that PPC_PCI_OF_BUS_MAP_FILL still has to be by default enabled (which >> > > > implies that PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT is disabled) on powermac: >> > > > https://lore.kernel.org/linuxppc-dev/575f239205e8635add81c9f902b7d9db7beb83ea.ca...@kernel.crashing.org/ >> > > > >> > > > On Wednesday 17 August 2022 18:39:26 Pali Rohár wrote: >> > > > > Creating or filling pci-OF-bus-map property in the device-tree is >> > > > > deprecated since May 2006 [1]. Allow to disable filling this >> > > > > property by >> > > > > unsetting config option CONFIG_PPC_PCI_OF_BUS_MAP_FILL for remaining >> > > > > chrp >> > > > > and powermac code. >> > > > > >> > > > > Disabling of pci-OF-bus-map property allows to enable new option >> > > > > CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT also for chrp and powermac. >> > > > > >> > > > > [1] - >> > > > > https://lore.kernel.org/linuxppc-dev/1148016268.13249.14.camel@localhost.localdomain/ >> > > > > >> > > > > Signed-off-by: Pali Rohár >> > > > > --- >> > > > > arch/powerpc/Kconfig | 12 +++- >> > > > > arch/powerpc/kernel/pci_32.c | 6 ++ >> > > > > 2 files changed, 17 insertions(+), 1 deletion(-) >> > > > > >> > > > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >> > > > > index 5881441f7672..df2696c406ad 100644 >> > > > > --- a/arch/powerpc/Kconfig >> > > > > +++ b/arch/powerpc/Kconfig >> > > > > @@ -373,9 +373,19 @@ config PPC_DCR >> > > > > depends on PPC_DCR_NATIVE || PPC_DCR_MMIO >> > > > > default y >> > > > > >> > > > > +config PPC_PCI_OF_BUS_MAP_FILL >> > > > > +bool "Fill pci-OF-bus-map property in the device-tree" >> > > > > +depends on PPC32 >> > > > > +depends on PPC_PMAC || PPC_CHRP >> > > > > +default y >> > > > > +help >> > > > > + This option creates and fills pci-OF-bus-map property in the >> > > > > + device-tree which is deprecated and is needed only for old >> > > > > + platforms. >> > > > > + >> > > > > config PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT >> > > > > depends on PPC32 >> > > > > -depends on !PPC_PMAC && !PPC_CHRP >> > > > > +depends on !PPC_PCI_OF_BUS_MAP_FILL >> > > > > bool "Assign PCI bus numbers from zero individually for each >> > > > > PCI domain" >> > > > > help >> > > > >By default on PPC32 were PCI bus numbers unique across all >> > > > > PCI domains. >> > > > > diff --git a/arch/powerpc/kernel/pci_32.c >> > > > > b/arch/powerpc/kernel/pci_32.c >> > > > > index 433965bf37b4..ffc4e1928c80 100644 >> > > > > --- a/arch/powerpc/kernel/pci_32.c >> > > > > +++ b/arch/powerpc/kernel/pci_32.c >> > > > > @@ -64,6 +64,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_IBM, >> > > > > PCI_DEVICE_ID_IBM_CPC710_PCI64, fixu >> > > > > >> > > > > #if defined(CONFIG_PPC_PMAC) || defined(CONFIG_PPC_CHRP) >> > > > > >> > > > > +#ifdef CONFIG_PPC_PCI_OF_BUS_MAP_FILL >> > > > > + >> > > > > static u8* pci_to_OF_bus_map; >> > > > > static int pci_bus_count; >> > > > > >> > > > > @@ -223,6 +225,8 @@ pci_create_OF_bus_map(void) >> > > > > } >> > > > > #endif >> > > > > >> > > > > +#endif /* CONFIG_PPC_PCI_OF_BUS_MAP_FILL */ >> > > > > + >> > > > > #endif /* defined(CONFIG_PPC_PMAC) || defined(CONFIG_PPC_CHRP) */ >> > > > > >> > > > > void pcibios_setup_phb_io_space(struct pci_controller *hose) >> > > > > @@ -264,6 +268,7 @@ static int __init pcibios_init(void) >> > > > > } >> > > > > >> > > > > #if defined(CONFIG_PPC_PMAC) || defined(CONFIG_PPC_CHRP) >> > > > > +#ifdef CONFIG_PPC_PCI_OF_BUS_MAP_FILL >> > > > > pci_bus_count = next_busno; >> > > >
Re: [PATCH v2 05/14] powerpc: Remove linker flag from KBUILD_AFLAGS
Masahiro Yamada writes: > On Thu, Jan 26, 2023 at 11:07 AM Nathan Chancellor wrote: >> >> On Thu, Jan 26, 2023 at 10:29:54AM +0900, Masahiro Yamada wrote: >> > On Wed, Jan 25, 2023 at 1:11 PM Michael Ellerman >> > wrote: >> > > >> > > Nathan Chancellor writes: >> > > > When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it >> > > > points out that KBUILD_AFLAGS contains a linker flag, which will be >> > > > used: >> > > >> > > Should that say "unused" ? >> > >> > >> > >> > Nathan, shall I fix it up locally? >> > (it will change the commit hash, though.) >> >> Yes please, if you would not mind. Sorry about that and thank you for >> spotting it Michael! >> >> Since you have to rebase to fix it, you can include Michael's acks? >> >> Cheers, >> Nathan > > Done. Thanks. cheers
Re: [PATCH v4 04/10] powerpc/8xx: Use a larger CPM1 command check mask
Herve Codina writes: > The CPM1 command mask is defined for use with the standard > CPM1 command register as described in the user's manual: > 0 |13|47|8 11|12 14| 15| > RST|- |OPCODE|CH_NUM| -|FLG| > > In the QMC extension the CPM1 command register is redefined > (QMC supplement user's manuel) with the following mapping: > 0 |13|47|8 13|14| 15| > RST|QMC OPCODE| 1110|CHANNEL_NUMBER| -|FLG| > > Extend the check command mask in order to support both the > standard CH_NUM field and the QMC extension CHANNEL_NUMBER > field. > > Signed-off-by: Herve Codina > Acked-by: Christophe Leroy > --- > arch/powerpc/platforms/8xx/cpm1.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Michael Ellerman (powerpc) cheers > diff --git a/arch/powerpc/platforms/8xx/cpm1.c > b/arch/powerpc/platforms/8xx/cpm1.c > index 8ef1f4392086..6b828b9f90d9 100644 > --- a/arch/powerpc/platforms/8xx/cpm1.c > +++ b/arch/powerpc/platforms/8xx/cpm1.c > @@ -100,7 +100,7 @@ int cpm_command(u32 command, u8 opcode) > int i, ret; > unsigned long flags; > > - if (command & 0xff0f) > + if (command & 0xff03) > return -EINVAL; > > spin_lock_irqsave(_lock, flags); > -- > 2.39.0
Re: [PATCH v4 02/24] powerpc/pseries: Fix alignment of PLPKS structures and buffers
Andrew Donnellan writes:
> A number of structures and buffers passed to PKS hcalls have alignment
> requirements, which could on occasion cause problems:
>
> - Authorisation structures must be 16-byte aligned and must not cross a
> page boundary
>
> - Label structures must not cross page boundaries
>
> - Password output buffers must not cross page boundaries
>
> Round up the allocations of these structures/buffers to the next power of
> 2 to make sure this happens.
It's not the *next* power of 2, it's the *nearest* power of 2, including
the initial value if it's already a power of 2.
That in conjunction with slab's guarantee that power of 2 sized objects
are naturally aligned, and that the relevant structs are smaller than a
page, is what makes this actually work.
So I think the patch is fine, but the change log and comments probably
need to be a bit clearer.
cheers
> Reported-by: Benjamin Gray
> Fixes: 2454a7af0f2a ("powerpc/pseries: define driver for Platform KeyStore")
> Signed-off-by: Andrew Donnellan
> Reviewed-by: Russell Currey
> Signed-off-by: Russell Currey
>
> ---
>
> v3: Merge plpks fixes and signed update series with secvar series
>
> v4: Fix typo in commit message
>
> Move up in series (npiggin)
> ---
> arch/powerpc/platforms/pseries/plpks.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/plpks.c
> b/arch/powerpc/platforms/pseries/plpks.c
> index 9e85b6d85b0b..a01cf2ff140a 100644
> --- a/arch/powerpc/platforms/pseries/plpks.c
> +++ b/arch/powerpc/platforms/pseries/plpks.c
> @@ -126,7 +126,8 @@ static int plpks_gen_password(void)
> u8 *password, consumer = PKS_OS_OWNER;
> int rc;
>
> - password = kzalloc(maxpwsize, GFP_KERNEL);
> + // The password must not cross a page boundary, so we align to the next
> power of 2
> + password = kzalloc(roundup_pow_of_two(maxpwsize), GFP_KERNEL);
> if (!password)
> return -ENOMEM;
>
> @@ -162,7 +163,9 @@ static struct plpks_auth *construct_auth(u8 consumer)
> if (consumer > PKS_OS_OWNER)
> return ERR_PTR(-EINVAL);
>
> - auth = kzalloc(struct_size(auth, password, maxpwsize), GFP_KERNEL);
> + // The auth structure must not cross a page boundary and must be
> + // 16 byte aligned. We align to the next largest power of 2
> + auth = kzalloc(roundup_pow_of_two(struct_size(auth, password,
> maxpwsize)), GFP_KERNEL);
> if (!auth)
> return ERR_PTR(-ENOMEM);
>
> @@ -196,7 +199,8 @@ static struct label *construct_label(char *component, u8
> varos, u8 *name,
> if (component && slen > sizeof(label->attr.prefix))
> return ERR_PTR(-EINVAL);
>
> - label = kzalloc(sizeof(*label), GFP_KERNEL);
> + // The label structure must not cross a page boundary, so we align to
> the next power of 2
> + label = kzalloc(roundup_pow_of_two(sizeof(*label)), GFP_KERNEL);
> if (!label)
> return ERR_PTR(-ENOMEM);
>
> --
> 2.39.0
Re: [PATCH] powerpc/tlb: Remove BUILD_BUG for book3s/32/tlbflush.h local_flush_tlb_page_psize
Benjamin Gray writes:
> Converts the BUILD_BUG to a WARN to allow building with a low/unoptimised
> compiler.
>
> The original expectation was that a compiler would see that the only
> usage of this function was in a function that is only called behind
> radix-only guards. And it worked this way on GCC. It seems Clang does
> not optimise away this call however, so thinks the function may be
> invoked and triggers the build bug as reported by the kernel test robot.
>
> https://lore.kernel.org/llvm/202301212348.edkowvff-...@intel.com
>
> This fix converts the build bug to a warning to allow builds without
> relying on particular compiler optimisation behaviours. The warning is
> not rate limited because this implementation should still never be called
> as-is, and anyone who might invoke it might appreciate it being very
> obvious that it's not behaving as expected.
>
> Fixes: 274d842fa1ef ("powerpc/tlb: Add local flush for page given mm_struct
> and psize")
> Reported-by: kernel test robot
> Signed-off-by: Benjamin Gray
> ---
> arch/powerpc/include/asm/book3s/32/tlbflush.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/32/tlbflush.h
> b/arch/powerpc/include/asm/book3s/32/tlbflush.h
> index 4be572908124..675196884640 100644
> --- a/arch/powerpc/include/asm/book3s/32/tlbflush.h
> +++ b/arch/powerpc/include/asm/book3s/32/tlbflush.h
> @@ -2,7 +2,7 @@
> #ifndef _ASM_POWERPC_BOOK3S_32_TLBFLUSH_H
> #define _ASM_POWERPC_BOOK3S_32_TLBFLUSH_H
>
> -#include
> +#include
>
> #define MMU_NO_CONTEXT (0)
> /*
> @@ -80,7 +80,7 @@ static inline void local_flush_tlb_page(struct
> vm_area_struct *vma,
> static inline void local_flush_tlb_page_psize(struct mm_struct *mm,
> unsigned long vmaddr, int psize)
> {
> - BUILD_BUG();
> + WARN(1, "Unimplemented local TLB flush with psize");
Can't we just fall back to flush_tlb_page(vma, vmaddr)?
I'd guess those CPUs can't flush based on page size anyway.
cheers
Re: arch/powerpc/kernel/head_85xx.o: warning: objtool: .head.text+0x1a6c: unannotated intra-function call
"Naveen N. Rao" writes:
> Sathvika Vasireddy wrote:
>>
> arch/powerpc/kvm/booke.o: warning: objtool: kvmppc_fill_pt_regs+0x30:
> unannotated intra-function call
>>
>> As an attempt to fix it, I tried expanding ANNOTATE_INTRA_FUNCTION_CALL
>> macro to indicate that the branch target is valid. It then threw another
>> warning (arch/powerpc/kvm/booke.o: warning: objtool:
>> kvmppc_fill_pt_regs+0x38: intra_function_call not a direct call). The
>> below diff just removes the warnings for me, but I'm not very sure if
>> this is the best way to fix the objtool warnings seen with this
>> particular file. Please let me know if there are any better ways to fix it.
>>
>> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
>> index 0dce93ccaadf..b6a413824b98 100644
>> --- a/arch/powerpc/kvm/booke.c
>> +++ b/arch/powerpc/kvm/booke.c
>> @@ -917,7 +917,9 @@ static void kvmppc_fill_pt_regs(struct pt_regs *regs)
>> asm("mr %0, 1" : "=r"(r1));
>> asm("mflr %0" : "=r"(lr));
>> asm("mfmsr %0" : "=r"(msr));
>> + asm(".pushsection .discard.intra_function_calls; .long 999f;
>> .popsection; 999:");
>> asm("bl 1f; 1: mflr %0" : "=r"(ip));
>
> I don't think you can assume that there won't be anything in between two
> asm statements.
Yeah, compiler could interleave something theoretically.
> Even if that works, I don't think it is good to expand the macro here.
> That asm statement looks to be trying to grab the current nip. I don't
> know enough about that code, and someone who knows more about KVM may be
> able to help, but it looks like we should be able to simply set 'ip' to
> the address of kvmppc_fill_pt_regs()?
There is _THIS_IP_ which should be sufficient.
cheers
Re: [PATCH v2 06/14] powerpc/vdso: Remove unused '-s' flag from ASFLAGS
Nathan Chancellor writes: > When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it > warns: > > clang-16: error: argument unused during compilation: '-s' > [-Werror,-Wunused-command-line-argument] > > The compiler's '-s' flag is a linking option (it is passed along to the > linker directly), which means it does nothing when the linker is not > invoked by the compiler. The kernel builds all .o files with '-c', which > stops the compilation pipeline before linking, so '-s' can be safely > dropped from ASFLAGS. > > Signed-off-by: Nathan Chancellor > Reviewed-by: Nick Desaulniers > Reviewed-by: Segher Boessenkool > --- > Cc: m...@ellerman.id.au Acked-by: Michael Ellerman (powerpc) cheers
Re: [PATCH v2 05/14] powerpc: Remove linker flag from KBUILD_AFLAGS
Nathan Chancellor writes:
> When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it
> points out that KBUILD_AFLAGS contains a linker flag, which will be
> used:
Should that say "unused" ?
> clang: error: -Wl,-a32: 'linker' input unused
> [-Werror,-Wunused-command-line-argument]
>
> This was likely supposed to be '-Wa,-a$(BITS)'. However, this change is
> unnecessary, as all supported versions of clang and gcc will pass '-a64'
> or '-a32' to GNU as based on the value of '-m'; the behavior of the
> latest stable release of the oldest supported major version of each
> compiler is shown below and each compiler's latest release exhibits the
> same behavior (GCC 12.2.0 and Clang 15.0.6).
>
> $ powerpc64-linux-gcc --version | head -1
> powerpc64-linux-gcc (GCC) 5.5.0
>
> $ powerpc64-linux-gcc -m64 -### -x assembler-with-cpp -c -o /dev/null
> /dev/null &| grep 'as '
> .../as -a64 -mppc64 -many -mbig -o /dev/null /tmp/cctwuBzZ.s
>
> $ powerpc64-linux-gcc -m32 -### -x assembler-with-cpp -c -o /dev/null
> /dev/null &| grep 'as '
> .../as -a32 -mppc -many -mbig -o /dev/null /tmp/ccaZP4mF.sg
>
> $ clang --version | head -1
> Ubuntu clang version
> 11.1.0-++20211011094159+1fdec59bffc1-1~exp1~20211011214622.5
>
> $ clang --target=powerpc64-linux-gnu -fno-integrated-as -m64 -### \
> -x assembler-with-cpp -c -o /dev/null /dev/null &| grep gnu-as
>"/usr/bin/powerpc64-linux-gnu-as" "-a64" "-mppc64" "-many" "-o"
> "/dev/null" "/tmp/null-80267c.s"
>
> $ clang --target=powerpc64-linux-gnu -fno-integrated-as -m64 -### \
> -x assembler-with-cpp -c -o /dev/null /dev/null &| grep gnu-as
>"/usr/bin/powerpc64-linux-gnu-as" "-a32" "-mppc" "-many" "-o" "/dev/null"
> "/tmp/null-ab8f8d.s"
>
> Remove this flag altogether to avoid future issues.
>
> Fixes: 1421dc6d4829 ("powerpc/kbuild: Use flags variables rather than
> overriding LD/CC/AS")
> Signed-off-by: Nathan Chancellor
> Reviewed-by: Nick Desaulniers
> ---
> Cc: m...@ellerman.id.au
Acked-by: Michael Ellerman (powerpc)
cheers
Re: [PATCH v4 21/24] powerpc/pseries: Pass PLPKS password on kexec
Andrew Donnellan writes:
> On Tue, 2023-01-24 at 14:36 +1000, Nicholas Piggin wrote:
>>
>> > + prop = of_find_property(of_chosen, "ibm,plpks-pw", );
>> > + if (prop) {
>> > + ospasswordlength = (u16)len;
>> > + ospassword = kzalloc(ospasswordlength, GFP_KERNEL);
>> > + if (!ospassword) {
>> > + of_remove_property(of_chosen, prop);
>> > + return -ENOMEM;
>> > + }
>> > + memcpy(ospassword, prop->value, len);
>> > + return of_remove_property(of_chosen, prop);
>>
>> Why do you remove the property afterward?
>
> Because otherwise the password will be sitting around in /proc/device-
> tree for the world to go and read.
The above removes it from the unflattened tree, but it will still exist
in the flattened tree, which is readable by root in /sys/firmware/fdt.
I'm not sure if that's a major security problem, but it does seem risky.
To scrub it from the flat tree you'd need to have an early_init_dt style
routine that finds the password early, saves the value somewhere for the
plpks driver, and then zeroes out the value in the flat tree. See the
example of rng-seed in early_init_dt_scan_chosen().
cheers
Re: [PATCH -next] powerpc/64s/hash: change stress_hpt_timer_fn to static
On Wed, 28 Dec 2022 17:36:03 +0800, Yang Yingliang wrote: > stress_hpt_timer_fn is only used in hash_utils.c now, > change it to static. > > Applied to powerpc/fixes. [1/1] powerpc/64s/hash: change stress_hpt_timer_fn to static https://git.kernel.org/powerpc/c/f12cd06109f47c2fb4b23a45ab55404c47ef7fae cheers
Re: [PATCH] powerpc/rtas: upgrade internal arch spinlocks
Nathan Lynch writes:
> Laurent Dufour writes:
>> On 10/01/2023 05:42:55, Nathan Lynch wrote:
>>> --- a/arch/powerpc/include/asm/rtas-types.h
>>> +++ b/arch/powerpc/include/asm/rtas-types.h
>>> @@ -18,7 +18,7 @@ struct rtas_t {
>>> unsigned long entry;/* physical address pointer */
>>> unsigned long base; /* physical address pointer */
>>> unsigned long size;
>>> - arch_spinlock_t lock;
>>> + raw_spinlock_t lock;
>>> struct rtas_args args;
>>> struct device_node *dev;/* virtual address pointer */
>>> };
>>> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
>>> index deded51a7978..a834726f18e3 100644
>>> --- a/arch/powerpc/kernel/rtas.c
>>> +++ b/arch/powerpc/kernel/rtas.c
>>> @@ -61,7 +61,7 @@ static inline void do_enter_rtas(unsigned long args)
>>> }
>>>
>>> struct rtas_t rtas = {
>>> - .lock = __ARCH_SPIN_LOCK_UNLOCKED
>>> + .lock = __RAW_SPIN_LOCK_UNLOCKED(rtas.lock),
>>> };
>>> EXPORT_SYMBOL(rtas);
>>
>> This is not the scope of this patch, but the RTAS's lock is externalized
>> through the structure rtas_t, while it is only used in that file.
>>
>> I think, this would be good, in case of future change about that lock, and
>> in order to not break KABI, to move it out of that structure, and to define
>> it statically in that file.
>
> Thanks for pointing this out.
>
> /* rtas-types.h */
> struct rtas_t {
> unsigned long entry;/* physical address pointer */
> unsigned long base; /* physical address pointer */
> unsigned long size;
> raw_spinlock_t lock;
> struct rtas_args args;
> struct device_node *dev;/* virtual address pointer */
> };
>
> /* rtas.h */
> extern struct rtas_t rtas;
>
> There's C and asm code outside of rtas.c that accesses rtas.entry,
> rtas.base, rtas.size, and rtas.dev. But as you say, rtas.lock is used
> only in rtas.c, and it's hard to imagine any legitimate external
> use. This applies to the args member as well, since accesses must occur
> under the lock.
>
> Making the lock and args private to rtas.c seems desirable on its own,
> so I think that should be done first as a cleanup, followed by the
> riskier arch -> raw lock conversion.
I don't see any reason why `rtas` is exported at all.
There might have been in the past, but I don't see one any more.
So I'd be happy if we removed the EXPORT entirely. If it breaks
something we can always put it back.
cheers
Re: [PATCH v2 1/2] powerpc/ps3: Change updateboltedpp panic to info
Geoff Levand writes: > On 1/9/23 09:41, Christophe Leroy wrote: >> >> >> Le 03/01/2023 à 18:51, Geoff Levand a écrit : >>> Commit fdacae8a84024474afff234bdd1dbe19ad597a10 (powerpc: Activate >>> CONFIG_STRICT_KERNEL_RWX by default) causes ps3_hpte_updateboltedpp() >>> to be called. Change the panic statment in ps3_hpte_updateboltedpp() >>> to a pr_info statement so that bootup can continue. >> >> But if I understand correctly, it means that CONFIG_STRICT_KERNEL_RWX >> won't work then. >> >> So, shouldn't we keep the panic and forbid CONFIG_STRICT_KERNEL_RWX on PS3 ? > > mmu_hash_ops.updateboltedpp returns void, so I can't return an error code to > indicate the feature is not supported. We could change that in the medium term. > I could do something like this in arch/powerpc/Kconfig: > > - select ARCH_HAS_STRICT_KERNEL_RWX if (PPC_BOOK3S || PPC_8xx || > 40x) && !HIBERNATION > + select ARCH_HAS_STRICT_KERNEL_RWX if (PPC_BOOK3S || PPC_8xx || > 40x) && !PPC_PS3 && !HIBERNATION > > But then the ppc64_defconfig would be built without STRICT_KERNEL_RWX. Yeah that would be a pity. We could do the above and disable PS3 in ppc64_defconfig, allowing ppc64_defconfig to still have STRICT_KERNEL_RWX. I assume actual PS3 users would use a ps3_defconfig anyway right? Relatedly are there any actual PS3 users left? ;) > I could do this in ps3_defconfig: > > +# CONFIG_STRICT_KERNEL_RWX is not set > +# CONFIG_STRICT_MODULE_RWX is not set > > But I don't like that way because it seems too easy for users to not add those > into a custom kernel config, and then they need to figure out what to do after > their kernel panics on startup. Yep agreed. > What other 'clean' way is there? If we want to have a multi-platform kernel image that can boot on PS3 and other platforms, and have strict kernel RWX, then we need some runtime logic to deal with that. I'd rather not do that though, because it adds complexity to deal with a pretty obscure corner case, and I suspect no one really boots a ppc64_defconfig on actual PS3 hardware these days. So my preference is we disable PS3 in ppc64_defconfig, and make PS3 incompatible with STRICT_KERNEL_RWX. cheers
[GIT PULL] Please pull powerpc/linux.git powerpc-6.2-3 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some more powerpc fixes for 6.2: The following changes since commit be5f95c8779e19779dd81927c8574fec5aaba36c: powerpc/vmlinux.lds: Don't discard .comment (2023-01-06 00:25:12 +1100) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-6.2-3 for you to fetch changes up to f12cd06109f47c2fb4b23a45ab55404c47ef7fae: powerpc/64s/hash: Make stress_hpt_timer_fn() static (2023-01-12 10:53:37 +1100) - -- powerpc fixes for 6.2 #3 - Fix a build failure with some versions of ld that have an odd version string. - Fix incorrect use of mutex in the IMC PMU driver. Thanks to: Kajol Jain, Michael Petlan, Ojaswin Mujoo, Peter Zijlstra, Yang Yingliang. - -- Kajol Jain (1): powerpc/imc-pmu: Fix use of mutex in IRQs disabled section Ojaswin Mujoo (1): powerpc/boot: Fix incorrect version calculation issue in ld_version Yang Yingliang (1): powerpc/64s/hash: Make stress_hpt_timer_fn() static arch/powerpc/boot/wrapper | 4 + arch/powerpc/include/asm/imc-pmu.h| 2 +- arch/powerpc/mm/book3s64/hash_utils.c | 2 +- arch/powerpc/perf/imc-pmu.c | 136 ++-- 4 files changed, 72 insertions(+), 72 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmPD2sYACgkQUevqPMjh pYDoDQ/9Gl0mGDGQGjbOz4iYKHhlqEB9vWq7NH+++tTSTIUHHuKOPHRWHgZKM+FI 6wxBpc0yU013oyqr+CcVP7NGYSry8pNG5kjC/GxyXcHBNcrmV9QEAYRs4Uo8qTU/ g1IZjrzhaxb3wlKNp0GiwEupGh428CkyziFXKndR9i5uryyzZnupmuQjig3fc4dt ZyqHcK6LKzlgvKgSI+iMijBKvI2hDszlIp+/lkB2H3+9/ORSid/bVhfRuVIzJeum B5cwN3BFnVZuRPtJMSIpdyHrDV5Yak6rkWdWB00NiHptZb13/wgytJwUuBPwnDRU qQYYJwMC9vKTmFGB8h0crC3MapxSVWeXb6OfJGtgdKieLdaFrVV343n699KiqWJD /pjBROJg+kvoR+YKgLVGvef/Nqu0cFI6wVB2JhjRJyuFuq81kXe4Va/CB6HeFKOJ cgr4fBPuxoSY6JRSGJ767ISrRM5K6pKSUUBDtLX2B9Qbyfq9+klu7tlU7cnsEzYr OuM90BE3XrrrquhCLYH7SO5QBbDiUSFP18Dp8ZizhyYjj4GmY8lmKlk/pQAAlwgw udDABrN1gFl4iAGkSAN1pd4YYfHyWOwo+FATkHhvqO1Jg8VbEZQyy8jBCwgKFTYg wHhUVYTnF4dEVUTTADbGpoYNppMzW/6yazZCBC8e2EaGq+o8+/Y= =Qdd5 -END PGP SIGNATURE-
Re: [PATCH v2] powerpc: Fix a wrong version calculation issue in ld_version
On Thu, 5 Jan 2023 01:54:37 +0530, Ojaswin Mujoo wrote: > ** The Issue ** > > The ld_version() function seems to compute the wrong version value for > certain ld versions like the following: > > $ ld --version GNU ld (GNU Binutils; SUSE Linux Enterprise 15) > 2.37.20211103-150100.7.37 > > [...] Applied to powerpc/fixes. [1/1] powerpc: Fix a wrong version calculation issue in ld_version https://git.kernel.org/powerpc/c/3287ebd7fd01e853ca4da8be675322429400e2bd cheers
Re: [PATCH] powerpc/imc-pmu: Fix IMC PMU code of using mutex in IRQs disabled section
On Fri, 6 Jan 2023 12:21:57 +0530, Kajol Jain wrote: > Current imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEP and > CONFIG_PROVE_LOCKING enabled, while running a thread_imc event. > > Command to trigger the warning: > [command]# perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5 > > Performance counter stats for 'sleep 5': > > [...] Applied to powerpc/fixes. [1/1] powerpc/imc-pmu: Fix IMC PMU code of using mutex in IRQs disabled section https://git.kernel.org/powerpc/c/76d588dddc459fefa1da96e0a081a397c5c8e216 cheers
[PATCH] powerpc/secvar: Use u64 in secvar_operations
There's no reason for secvar_operations to use uint64_t vs the more
common kernel type u64.
The types are compatible, but they require different printk format
strings which can lead to confusion.
Change all the secvar related routines to use u64.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/secvar.h| 9 +++--
arch/powerpc/kernel/secvar-sysfs.c | 8
arch/powerpc/platforms/powernv/opal-secvar.c | 9 +++--
security/integrity/platform_certs/load_powerpc.c | 4 ++--
4 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/secvar.h
b/arch/powerpc/include/asm/secvar.h
index 4cc35b58b986..07ba36f868a7 100644
--- a/arch/powerpc/include/asm/secvar.h
+++ b/arch/powerpc/include/asm/secvar.h
@@ -14,12 +14,9 @@
extern const struct secvar_operations *secvar_ops;
struct secvar_operations {
- int (*get)(const char *key, uint64_t key_len, u8 *data,
- uint64_t *data_size);
- int (*get_next)(const char *key, uint64_t *key_len,
- uint64_t keybufsize);
- int (*set)(const char *key, uint64_t key_len, u8 *data,
- uint64_t data_size);
+ int (*get)(const char *key, u64 key_len, u8 *data, u64 *data_size);
+ int (*get_next)(const char *key, u64 *key_len, u64 keybufsize);
+ int (*set)(const char *key, u64 key_len, u8 *data, u64 data_size);
};
#ifdef CONFIG_PPC_SECURE_BOOT
diff --git a/arch/powerpc/kernel/secvar-sysfs.c
b/arch/powerpc/kernel/secvar-sysfs.c
index 1ee4640a2641..001cdbcdb9d2 100644
--- a/arch/powerpc/kernel/secvar-sysfs.c
+++ b/arch/powerpc/kernel/secvar-sysfs.c
@@ -47,7 +47,7 @@ static ssize_t format_show(struct kobject *kobj, struct
kobj_attribute *attr,
static ssize_t size_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
{
- uint64_t dsize;
+ u64 dsize;
int rc;
rc = secvar_ops->get(kobj->name, strlen(kobj->name) + 1, NULL, );
@@ -64,8 +64,8 @@ static ssize_t data_read(struct file *filep, struct kobject
*kobj,
struct bin_attribute *attr, char *buf, loff_t off,
size_t count)
{
- uint64_t dsize;
char *data;
+ u64 dsize;
int rc;
rc = secvar_ops->get(kobj->name, strlen(kobj->name) + 1, NULL, );
@@ -166,9 +166,9 @@ static int update_kobj_size(void)
static int secvar_sysfs_load(void)
{
- char *name;
- uint64_t namesize = 0;
struct kobject *kobj;
+ u64 namesize = 0;
+ char *name;
int rc;
name = kzalloc(NAME_MAX_SIZE, GFP_KERNEL);
diff --git a/arch/powerpc/platforms/powernv/opal-secvar.c
b/arch/powerpc/platforms/powernv/opal-secvar.c
index 14133e120bdd..ef89861569e0 100644
--- a/arch/powerpc/platforms/powernv/opal-secvar.c
+++ b/arch/powerpc/platforms/powernv/opal-secvar.c
@@ -54,8 +54,7 @@ static int opal_status_to_err(int rc)
return err;
}
-static int opal_get_variable(const char *key, uint64_t ksize,
-u8 *data, uint64_t *dsize)
+static int opal_get_variable(const char *key, u64 ksize, u8 *data, u64 *dsize)
{
int rc;
@@ -71,8 +70,7 @@ static int opal_get_variable(const char *key, uint64_t ksize,
return opal_status_to_err(rc);
}
-static int opal_get_next_variable(const char *key, uint64_t *keylen,
- uint64_t keybufsize)
+static int opal_get_next_variable(const char *key, u64 *keylen, u64 keybufsize)
{
int rc;
@@ -88,8 +86,7 @@ static int opal_get_next_variable(const char *key, uint64_t
*keylen,
return opal_status_to_err(rc);
}
-static int opal_set_variable(const char *key, uint64_t ksize, u8 *data,
-uint64_t dsize)
+static int opal_set_variable(const char *key, u64 ksize, u8 *data, u64 dsize)
{
int rc;
diff --git a/security/integrity/platform_certs/load_powerpc.c
b/security/integrity/platform_certs/load_powerpc.c
index a2900cb85357..1e4f80a4e71c 100644
--- a/security/integrity/platform_certs/load_powerpc.c
+++ b/security/integrity/platform_certs/load_powerpc.c
@@ -18,7 +18,7 @@
/*
* Get a certificate list blob from the named secure variable.
*/
-static __init void *get_cert_list(u8 *key, unsigned long keylen, uint64_t
*size)
+static __init void *get_cert_list(u8 *key, unsigned long keylen, u64 *size)
{
int rc;
void *db;
@@ -51,7 +51,7 @@ static __init void *get_cert_list(u8 *key, unsigned long
keylen, uint64_t *size)
static int __init load_powerpc_certs(void)
{
void *db = NULL, *dbx = NULL;
- uint64_t dbsize = 0, dbxsize = 0;
+ u64 dbsize = 0, dbxsize = 0;
int rc = 0;
struct device_node *node;
--
2.39.0
Re: [PATCH rcu 04/27] arch/powerpc/kvm: Remove "select SRCU"
"Paul E. McKenney" writes: > Now that the SRCU Kconfig option is unconditionally selected, there is > no longer any point in selecting it. Therefore, remove the "select SRCU" > Kconfig statements. > > Signed-off-by: Paul E. McKenney > Cc: Michael Ellerman > Cc: Nicholas Piggin > Cc: Christophe Leroy > Cc: > --- > arch/powerpc/kvm/Kconfig | 1 - > 1 file changed, 1 deletion(-) Acked-by: Michael Ellerman (powerpc) cheers > diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig > index a9f57dad6d916..902611954200d 100644 > --- a/arch/powerpc/kvm/Kconfig > +++ b/arch/powerpc/kvm/Kconfig > @@ -22,7 +22,6 @@ config KVM > select PREEMPT_NOTIFIERS > select HAVE_KVM_EVENTFD > select HAVE_KVM_VCPU_ASYNC_IOCTL > - select SRCU > select KVM_VFIO > select IRQ_BYPASS_MANAGER > select HAVE_KVM_IRQ_BYPASS > -- > 2.31.1.189.g2e36527f23
Re: usb.c:undefined reference to `qe_immr'
Randy Dunlap writes: > [adding Cc's] > > > On 1/9/23 23:59, kernel test robot wrote: >> Hi Masahiro, >> >> FYI, the error/warning still remains. >> >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> master >> head: 5a41237ad1d4b62008f93163af1d9b1da90729d8 >> commit: 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b kbuild: link symbol CRCs at >> final link, removing CONFIG_MODULE_REL_CRCS >> date: 8 months ago >> config: powerpc-randconfig-r026-20230110 >> compiler: powerpc-linux-gcc (GCC) 12.1.0 >> reproduce (this is a W=1 build): >> wget >> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O >> ~/bin/make.cross >> chmod +x ~/bin/make.cross >> # >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7b4537199a4a8480b8c3ba37a2d44765ce76cd9b >> git remote add linus >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> git fetch --no-tags linus master >> git checkout 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b >> # save the config file >> mkdir build_dir && cp config build_dir/.config >> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 >> O=build_dir ARCH=powerpc olddefconfig >> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 >> O=build_dir ARCH=powerpc SHELL=/bin/bash >> >> If you fix the issue, kindly add following tag where applicable >> | Reported-by: kernel test robot >> >> All errors (new ones prefixed by >>): >> >>powerpc-linux-ld: powerpc-linux-ld: DWARF error: could not find abbrev >> number 74 >>drivers/soc/fsl/qe/usb.o: in function `qe_usb_clock_set': usb.c:(.text+0x1e): undefined reference to `qe_immr' powerpc-linux-ld: usb.c:(.text+0x2a): undefined reference to `qe_immr' powerpc-linux-ld: usb.c:(.text+0xbc): undefined reference to `qe_setbrg' powerpc-linux-ld: usb.c:(.text+0xca): undefined reference to `cmxgcr_lock' >>powerpc-linux-ld: usb.c:(.text+0xce): undefined reference to `cmxgcr_lock' >> > > .config extract: > > # > # NXP/Freescale QorIQ SoC drivers > # > # CONFIG_QUICC_ENGINE is not set > CONFIG_QE_USB=y > > > This is caused by (drivers/soc/fsl/qe/Kconfig): > > config QE_USB > bool > default y if USB_FSL_QE > help > QE USB Controller support > > which does not depend on QUICC_ENGINE, where the latter build provides > the missing symbols. So QE_USB should depend on QUICC_ENGINE no? cheers
[PATCH 1/2] powerpc/64s/radix: Fix crash with unaligned relocated kernel
If a relocatable kernel is loaded at an address that is not 2MB aligned
and told not to relocate to zero, the kernel can crash due to
mark_rodata_ro() incorrectly changing some read-write data to read-only.
Scenarios where the misalignment can occur are when the kernel is
loaded by kdump or using the RELOCATABLE_TEST config option.
Example crash with the kernel loaded at 5MB:
Run /sbin/init as init process
BUG: Unable to handle kernel data access on write at 0xc0452000
Faulting instruction address: 0xc05b6730
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
CPU: 1 PID: 1 Comm: init Not tainted 6.2.0-rc1-00011-g349188be4841 #166
Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf05
of:SLOF,git-5b4c5a hv:linux,kvm pSeries
NIP: c05b6730 LR: c0ae9ab8 CTR: 0380
REGS: c4503250 TRAP: 0300 Not tainted
(6.2.0-rc1-00011-g349188be4841)
MSR: 80009033 CR: 44288480 XER:
CFAR: c05b66ec DAR: c0452000 DSISR: 0a00 IRQMASK: 0
...
NIP memset+0x68/0x104
LR zero_user_segments.constprop.0+0xa8/0xf0
Call Trace:
ext4_mpage_readpages+0x7f8/0x830
ext4_readahead+0x48/0x60
read_pages+0xb8/0x380
page_cache_ra_unbounded+0x19c/0x250
filemap_fault+0x58c/0xae0
__do_fault+0x60/0x100
__handle_mm_fault+0x1230/0x1a40
handle_mm_fault+0x120/0x300
___do_page_fault+0x20c/0xa80
do_page_fault+0x30/0xc0
data_access_common_virt+0x210/0x220
This happens because mark_rodata_ro() tries to change permissions on the
range _stext..__end_rodata, but _stext sits in the middle of the 2MB
page from 4MB to 6MB:
radix-mmu: Mapped 0x-0x0020 with 2.00 MiB pages
(exec)
radix-mmu: Mapped 0x0020-0x0040 with 2.00 MiB pages
radix-mmu: Mapped 0x0040-0x0240 with 2.00 MiB pages
(exec)
The logic that changes the permissions assumes the linear mapping was
split correctly at boot, so it marks the entire 2MB page read-only. That
leads to the write fault above.
To fix it, the boot time mapping logic needs to consider that if the
kernel is running at a non-zero address then _stext is a boundary where
it must split the mapping.
That leads to the mapping being split correctly, allowing the rodata
permission change to take happen correctly, with no spillover:
radix-mmu: Mapped 0x-0x0020 with 2.00 MiB pages
(exec)
radix-mmu: Mapped 0x0020-0x0040 with 2.00 MiB pages
radix-mmu: Mapped 0x0040-0x0050 with 64.0 KiB pages
radix-mmu: Mapped 0x0050-0x0060 with 64.0 KiB pages
(exec)
radix-mmu: Mapped 0x0060-0x0240 with 2.00 MiB pages
(exec)
If the kernel is loaded at a 2MB aligned address, the mapping continues
to use 2MB pages as before:
radix-mmu: Mapped 0x-0x0020 with 2.00 MiB pages
(exec)
radix-mmu: Mapped 0x0020-0x0040 with 2.00 MiB pages
radix-mmu: Mapped 0x0040-0x02c0 with 2.00 MiB pages
(exec)
radix-mmu: Mapped 0x02c0-0x0001 with 2.00 MiB pages
Fixes: c55d7b5e6426 ("powerpc: Remove STRICT_KERNEL_RWX incompatibility with
RELOCATABLE")
Signed-off-by: Michael Ellerman
---
arch/powerpc/mm/book3s64/radix_pgtable.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c
b/arch/powerpc/mm/book3s64/radix_pgtable.c
index cac727b01799..5a2384ed1727 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -262,6 +262,17 @@ print_mapping(unsigned long start, unsigned long end,
unsigned long size, bool e
static unsigned long next_boundary(unsigned long addr, unsigned long end)
{
#ifdef CONFIG_STRICT_KERNEL_RWX
+ unsigned long stext_phys;
+
+ stext_phys = __pa_symbol(_stext);
+
+ // Relocatable kernel running at non-zero real address
+ if (stext_phys != 0) {
+ // Start of relocated kernel text is a rodata boundary
+ if (addr < stext_phys)
+ return stext_phys;
+ }
+
if (addr < __pa_symbol(__srwx_boundary))
return __pa_symbol(__srwx_boundary);
#endif
--
2.39.0
[PATCH 2/2] powerpc/64s/radix: Fix RWX mapping with relocated kernel
If a relocatable kernel is loaded at a non-zero address and told not to
relocate to zero (kdump or RELOCATABLE_TEST), the mapping of the
interrupt code at zero is left with RWX permissions.
That is a security weakness, and leads to a warning at boot if
CONFIG_DEBUG_WX is enabled:
powerpc/mm: Found insecure W+X mapping at address
056435bc/0xc000
WARNING: CPU: 1 PID: 1 at arch/powerpc/mm/ptdump/ptdump.c:193
note_page+0x484/0x4c0
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc1-1-g8ae8e98aea82-dirty
#175
Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf05
of:SLOF,git-dd0dca hv:linux,kvm pSeries
NIP: c04a1c34 LR: c04a1c30 CTR:
REGS: c3503770 TRAP: 0700 Not tainted
(6.2.0-rc1-1-g8ae8e98aea82-dirty)
MSR: 82029033 CR: 24000220 XER:
CFAR: c0545a58 IRQMASK: 0
...
NIP note_page+0x484/0x4c0
LR note_page+0x480/0x4c0
Call Trace:
note_page+0x480/0x4c0 (unreliable)
ptdump_pmd_entry+0xc8/0x100
walk_pgd_range+0x618/0xab0
walk_page_range_novma+0x74/0xc0
ptdump_walk_pgd+0x98/0x170
ptdump_check_wx+0x94/0x100
mark_rodata_ro+0x30/0x70
kernel_init+0x78/0x1a0
ret_from_kernel_thread+0x5c/0x64
The fix has two parts. Firstly the pages from zero up to the end of
interrupts need to be marked read-only, so that they are left with R-X
permissions. Secondly the mapping logic needs to be taught to ensure
there is a page boundary at the end of the interrupt region, so that the
permission change only applies to the interrupt text, and not the region
following it.
Fixes: c55d7b5e6426 ("powerpc: Remove STRICT_KERNEL_RWX incompatibility with
RELOCATABLE")
Signed-off-by: Michael Ellerman
---
arch/powerpc/mm/book3s64/radix_pgtable.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c
b/arch/powerpc/mm/book3s64/radix_pgtable.c
index 5a2384ed1727..26245aaf12b8 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -234,6 +234,14 @@ void radix__mark_rodata_ro(void)
end = (unsigned long)__end_rodata;
radix__change_memory_range(start, end, _PAGE_WRITE);
+
+ for (start = PAGE_OFFSET; start < (unsigned long)_stext; start +=
PAGE_SIZE) {
+ end = start + PAGE_SIZE;
+ if (overlaps_interrupt_vector_text(start, end))
+ radix__change_memory_range(start, end, _PAGE_WRITE);
+ else
+ break;
+ }
}
void radix__mark_initmem_nx(void)
@@ -268,6 +276,11 @@ static unsigned long next_boundary(unsigned long addr,
unsigned long end)
// Relocatable kernel running at non-zero real address
if (stext_phys != 0) {
+ // The end of interrupts code at zero is a rodata boundary
+ unsigned long end_intr = __pa_symbol(__end_interrupts) -
stext_phys;
+ if (addr < end_intr)
+ return end_intr;
+
// Start of relocated kernel text is a rodata boundary
if (addr < stext_phys)
return stext_phys;
--
2.39.0
[GIT PULL] Please pull powerpc/linux.git powerpc-6.2-2 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull powerpc fixes for 6.2: The following changes since commit 88603b6dc419445847923fcb7fe5080067a30f98: Linux 6.2-rc2 (2023-01-01 13:53:16 -0800) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-6.2-2 for you to fetch changes up to be5f95c8779e19779dd81927c8574fec5aaba36c: powerpc/vmlinux.lds: Don't discard .comment (2023-01-06 00:25:12 +1100) - -- powerpc fixes for 6.2 #2 - Three fixes for various bogosity in our linker script, revealed by the recent commit which changed discard behaviour with some toolchains. - -- Michael Ellerman (3): powerpc/vmlinux.lds: Define RUNTIME_DISCARD_EXIT powerpc/vmlinux.lds: Don't discard .rela* for relocatable builds powerpc/vmlinux.lds: Don't discard .comment arch/powerpc/kernel/vmlinux.lds.S | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmO6u4IACgkQUevqPMjh pYBhsRAAt9QD2PcS4enFnYmXG8XgL/ZY1Cuc0hS7Pt6DhVmV5bJnvGzIF+oA+P4x GVegIN1B9mLYj/TVXLdqvKYFy3Ve6ENrd3lifD47BoISJRp0YbofFCMUepR1LdSq B4yMqz0hDF10PqDot2b9Gt6m7vZADt2ywqIXehypiUil7w3yCd60BUSqZeNL/GBY CylwrZ4J5WEX7j91HovmDpqFSiHnBBUvXHJH+WLwdJkMDcE2fzsrRLUEvOt7zLR1 3pLCMBoQ9HTUyMN6jO4HPaxEcg0uBKCwHQYsSrLp3hW4W2QzVbmmg5sSgALYvCWU olcgO1kML6CeSK+JxeFlX5/CgE6VWRVOCe61cOHyh1b0ey5BkxxWtTkeyGzdVBWB KCO70lgioxP41IQH08a+BLIT/N4H8MNF9wK4cSy6RePnkhhlG0lXU28wVtEaS5FU zWoZXwz9c3q5tyWqWwqWmlvMrO1fTqMgUqOudXIsb+oZI/wM0NeUc6Ud0Kgm0+q4 MiVQdkNRWc6DCP2+U5bDC2L9vu2wAYeXqDJysNrKkuFiZ1XkrOk1b31EIRESEGtL lrDwKeSzvrlvtKtEye3LO/0etYtQGy/GEwAlweQq2bo85vpnK9Luwh/SaTK53gDp ZJJEm7AEnyqz+4Zyu9PuMQiqNvWygURhP1HXKnVoq4cMBQ5qUdA= =7KgK -END PGP SIGNATURE-
Re: [PATCH 1/3] powerpc/vmlinux.lds: Define RUNTIME_DISCARD_EXIT
On Fri, 6 Jan 2023 00:23:47 +1100, Michael Ellerman wrote: > The powerpc linker script explicitly includes .exit.text, because > otherwise the link fails due to references from __bug_table and > __ex_table. The code is freed (discarded) at runtime along with > .init.text and data. > > That has worked in the past despite powerpc not defining > RUNTIME_DISCARD_EXIT because DISCARDS appears late in the powerpc linker > script (line 410), and the explicit inclusion of .exit.text > earlier (line 280) supersedes the discard. > > [...] Applied to powerpc/fixes. [1/3] powerpc/vmlinux.lds: Define RUNTIME_DISCARD_EXIT https://git.kernel.org/powerpc/c/4b9880dbf3bdba3a7c56445137c3d0e30aaa0a40 [2/3] powerpc/vmlinux.lds: Don't discard .rela* for relocatable builds https://git.kernel.org/powerpc/c/07b050f9290ee012a407a0f64151db902a1520f5 [3/3] powerpc/vmlinux.lds: Don't discard .comment https://git.kernel.org/powerpc/c/be5f95c8779e19779dd81927c8574fec5aaba36c cheers
Re: [PATCH 4/4] powerpc/pseries: Implement signed update for PLPKS objects
Andrew Donnellan writes:
> From: Nayna Jain
>
> The Platform Keystore provides a signed update interface which can be used
> to create, replace or append to certain variables in the PKS in a secure
> fashion, with the hypervisor requiring that the update be signed using the
> Platform Key.
>
> Implement an interface to the H_PKS_SIGNED_UPDATE hcall in the plpks
> driver to allow signed updates to PKS objects.
>
> (The plpks driver doesn't need to do any cryptography or otherwise handle
> the actual signed variable contents - that will be handled by userspace
> tooling.)
>
> Signed-off-by: Nayna Jain
> [ajd: split patch, rewrite commit message, add timeout handling]
> Co-developed-by: Andrew Donnellan
> Signed-off-by: Andrew Donnellan
> ---
> arch/powerpc/include/asm/hvcall.h | 3 +-
> arch/powerpc/platforms/pseries/plpks.c | 81 +++---
> arch/powerpc/platforms/pseries/plpks.h | 5 ++
> 3 files changed, 79 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/hvcall.h
> b/arch/powerpc/include/asm/hvcall.h
> index 95fd7f9485d5..33b26c0cb69b 100644
> --- a/arch/powerpc/include/asm/hvcall.h
> +++ b/arch/powerpc/include/asm/hvcall.h
> @@ -336,7 +336,8 @@
> #define H_SCM_FLUSH 0x44C
> #define H_GET_ENERGY_SCALE_INFO 0x450
> #define H_WATCHDOG 0x45C
> -#define MAX_HCALL_OPCODE H_WATCHDOG
> +#define H_PKS_SIGNED_UPDATE 0x454
> +#define MAX_HCALL_OPCODE H_PKS_SIGNED_UPDATE
>
> /* Scope args for H_SCM_UNBIND_ALL */
> #define H_UNBIND_SCOPE_ALL (0x1)
> diff --git a/arch/powerpc/platforms/pseries/plpks.c
> b/arch/powerpc/platforms/pseries/plpks.c
> index c5ae00a8a968..9e4401aabf4f 100644
> --- a/arch/powerpc/platforms/pseries/plpks.c
> +++ b/arch/powerpc/platforms/pseries/plpks.c
> @@ -30,9 +30,9 @@
> #define MAX_NAME_SIZE239
> #define MAX_DATA_SIZE4000
>
> -#define PKS_FLUSH_MAX_TIMEOUT 5000 //msec
> -#define PKS_FLUSH_SLEEP10 //msec
> -#define PKS_FLUSH_SLEEP_RANGE 400
> +#define PKS_MAX_TIMEOUT 5000 // msec
> +#define PKS_FLUSH_SLEEP 10 // msec
> +#define PKS_FLUSH_SLEEP_RANGE400
>
> static u8 *ospassword;
> static u16 ospasswordlength;
> @@ -95,6 +95,12 @@ static int pseries_status_to_err(int rc)
> err = -ENOENT;
> break;
> case H_BUSY:
> + case H_LONG_BUSY_ORDER_1_MSEC:
> + case H_LONG_BUSY_ORDER_10_MSEC:
> + case H_LONG_BUSY_ORDER_100_MSEC:
> + case H_LONG_BUSY_ORDER_1_SEC:
> + case H_LONG_BUSY_ORDER_10_SEC:
> + case H_LONG_BUSY_ORDER_100_SEC:
> err = -EBUSY;
> break;
> case H_AUTHORITY:
> @@ -198,14 +204,17 @@ static struct label *construct_label(char *component,
> u8 varos, u8 *name,
>u16 namelen)
> {
> struct label *label;
> - size_t slen;
> + size_t slen = 0;
>
> if (!name || namelen > MAX_NAME_SIZE)
> return ERR_PTR(-EINVAL);
>
> - slen = strlen(component);
> - if (component && slen > sizeof(label->attr.prefix))
> - return ERR_PTR(-EINVAL);
> + // Support NULL component for signed updates
> + if (component) {
> + slen = strlen(component);
> + if (slen > sizeof(label->attr.prefix))
> + return ERR_PTR(-EINVAL);
> + }
>
> // The label structure must not cross a page boundary, so we align to
> the next power of 2
> label = kzalloc(roundup_pow_of_two(sizeof(*label)), GFP_KERNEL);
> @@ -372,7 +381,7 @@ static int plpks_confirm_object_flushed(struct label
> *label,
> usleep_range(PKS_FLUSH_SLEEP,
>PKS_FLUSH_SLEEP + PKS_FLUSH_SLEEP_RANGE);
> timeout = timeout + PKS_FLUSH_SLEEP;
> - } while (timeout < PKS_FLUSH_MAX_TIMEOUT);
> + } while (timeout < PKS_MAX_TIMEOUT);
>
> if (timed_out)
> rc = -ETIMEDOUT;
> @@ -382,6 +391,60 @@ static int plpks_confirm_object_flushed(struct label
> *label,
> return rc;
> }
>
> +int plpks_signed_update_var(struct plpks_var var, u64 flags)
> +{
I don't see a reason why var is passed by value here? A pointer would be
more typical.
cheers
Re: [PATCH v2 7/7] powerpc/pseries: Implement secvars for dynamic secure boot
Russell Currey writes: > The pseries platform can support dynamic secure boot (i.e. secure boot > using user-defined keys) using variables contained with the PowerVM LPAR > Platform KeyStore (PLPKS). Using the powerpc secvar API, expose the > relevant variables for pseries dynamic secure boot through the existing > secvar filesystem layout. > > The relevant variables for dynamic secure boot are signed in the > keystore, and can only be modified using the H_PKS_SIGNED_UPDATE hcall. > Object labels in the keystore are encoded using ucs2 format. With our > fixed variable names we don't have to care about encoding outside of the > necessary byte padding. > > When a user writes to a variable, the first 8 bytes of data must contain > the signed update flags as defined by the hypervisor. > > When a user reads a variable, the first 4 bytes of data contain the > policies defined for the object. > > Limitations exist due to the underlying implementation of sysfs binary > attributes, as is the case for the OPAL secvar implementation - > partial writes are unsupported and writes cannot be larger than PAGE_SIZE. > > Co-developed-by: Nayna Jain > Signed-off-by: Nayna Jain > Co-developed-by: Andrew Donnellan > Signed-off-by: Andrew Donnellan > Signed-off-by: Russell Currey > --- > v2: Remove unnecessary config vars from sysfs and document the others, > thanks to review from Greg. If we end up needing to expose more, we > can add them later and update the docs. > > Use sysfs_emit() instead of sprintf(), thanks to Greg. > > Change the size of the sysfs binary attributes to include the 8-byte > flags header, preventing truncation of large writes. > > Documentation/ABI/testing/sysfs-secvar| 67 - > arch/powerpc/platforms/pseries/Kconfig| 13 + > arch/powerpc/platforms/pseries/Makefile | 4 +- > arch/powerpc/platforms/pseries/plpks-secvar.c | 245 ++ > 4 files changed, 326 insertions(+), 3 deletions(-) > create mode 100644 arch/powerpc/platforms/pseries/plpks-secvar.c > > diff --git a/Documentation/ABI/testing/sysfs-secvar > b/Documentation/ABI/testing/sysfs-secvar > index feebb8c57294..466a8cb92b92 100644 > --- a/Documentation/ABI/testing/sysfs-secvar > +++ b/Documentation/ABI/testing/sysfs-secvar > @@ -34,7 +34,7 @@ Description:An integer representation of the size > of the content of the > > What:/sys/firmware/secvar/vars//data > Date:August 2019 > -Contact: Nayna Jain h > +Contact: Nayna Jain > Description: A read-only file containing the value of the variable. The size > of the file represents the maximum size of the variable data. > > @@ -44,3 +44,68 @@ Contact: Nayna Jain > Description: A write-only file that is used to submit the new value for the > variable. The size of the file represents the maximum size of > the variable data that can be written. > + > +What:/sys/firmware/secvar/config > +Date:December 2022 > +Contact: Nayna Jain > +Description: This optional directory contains read-only config attributes as > + defined by the secure variable implementation. All data is in > + ASCII format. The directory is only created if the backing > + implementation provides variables to populate it, which at > + present is only PLPKS on the pseries platform. I think it's OK to mention that currently this only exists for PLPKS ... > +What:/sys/firmware/secvar/config/version > +Date:December 2022 > +Contact: Nayna Jain > +Description: RO file, only present if the secvar implementation is PLPKS. ... but I don't think we want to specify that files are only present for PLPKS. Because if another backend wanted to create them in future, that would technically be an ABI change. > + Contains the config version as reported by the hypervisor in > + ASCII decimal format. > + > +What:/sys/firmware/secvar/config/max_object_size > +Date:December 2022 > +Contact: Nayna Jain > +Description: RO file, only present if the secvar implementation is PLPKS. > + > + Contains the maximum allowed size of objects in the keystore > + in bytes, represented in ASCII decimal format. > + > + This is not necessarily the same as the max size that can be > + written to an update file as writes can contain more than > + object data, you should use the size of the update file for > + that purpose. > + > +What:/sys/firmware/secvar/config/total_size > +Date:December 2022 > +Contact: Nayna Jain > +Description: RO file, only present if the secvar implementation is PLPKS. > + > + Contains the total size of the PLPKS in bytes, represented in > + ASCII decimal format.
Re: [PATCH v2 6/7] powerpc/secvar: Extend sysfs to include config vars
Russell Currey writes:
> The forthcoming pseries consumer of the secvar API wants to expose a
> number of config variables. Allowing secvar implementations to provide
> their own sysfs attributes makes it easy for consumers to expose what
> they need to.
>
> This is not being used by the OPAL secvar implementation at present, and
> the config directory will not be created if no attributes are set.
Would it be slightly cleaner if the attributes were just a member of
secvar_operations?
That would avoid the need for some of the separate handling of the ops
and the attributes.
I know "ops" implies it's only methods, but I think that's not a big
problem. The power_pmu struct does something similar, where it combines
ops and attributes.
cheers
> diff --git a/arch/powerpc/include/asm/secvar.h
> b/arch/powerpc/include/asm/secvar.h
> index 92d2c051918b..250e7066b6da 100644
> --- a/arch/powerpc/include/asm/secvar.h
> +++ b/arch/powerpc/include/asm/secvar.h
> @@ -10,6 +10,7 @@
>
> #include
> #include
> +#include
>
> extern const struct secvar_operations *secvar_ops;
>
> @@ -27,10 +28,12 @@ struct secvar_operations {
> #ifdef CONFIG_PPC_SECURE_BOOT
>
> extern void set_secvar_ops(const struct secvar_operations *ops);
> +extern void set_secvar_config_attrs(const struct attribute **attrs);
>
> #else
>
> static inline void set_secvar_ops(const struct secvar_operations *ops) { }
> +static inline void set_secvar_config_attrs(const struct attribute **attrs) {
> }
>
> #endif
>
> diff --git a/arch/powerpc/kernel/secvar-sysfs.c
> b/arch/powerpc/kernel/secvar-sysfs.c
> index aa1daec480e1..ad1e1d72d2ae 100644
> --- a/arch/powerpc/kernel/secvar-sysfs.c
> +++ b/arch/powerpc/kernel/secvar-sysfs.c
> @@ -15,9 +15,17 @@
>
> #define NAME_MAX_SIZE 1024
>
> +const struct attribute **secvar_config_attrs __ro_after_init = NULL;
> +
> static struct kobject *secvar_kobj;
> static struct kset *secvar_kset;
>
> +void set_secvar_config_attrs(const struct attribute **attrs)
> +{
> + WARN_ON_ONCE(secvar_config_attrs);
> + secvar_config_attrs = attrs;
> +}
> +
> static ssize_t format_show(struct kobject *kobj, struct kobj_attribute *attr,
> char *buf)
> {
> @@ -134,6 +142,16 @@ static int update_kobj_size(void)
> return 0;
> }
>
> +static int secvar_sysfs_config(struct kobject *kobj)
> +{
> + struct attribute_group config_group = {
> + .name = "config",
> + .attrs = (struct attribute **)secvar_config_attrs,
> + };
> +
> + return sysfs_create_group(kobj, _group);
> +}
> +
> static int secvar_sysfs_load(void)
> {
> char *name;
> @@ -196,26 +214,38 @@ static int secvar_sysfs_init(void)
>
> rc = sysfs_create_file(secvar_kobj, _attr.attr);
> if (rc) {
> - kobject_put(secvar_kobj);
> - return -ENOMEM;
> + pr_err("secvar: Failed to create format object\n");
> + rc = -ENOMEM;
> + goto err;
> }
>
> secvar_kset = kset_create_and_add("vars", NULL, secvar_kobj);
> if (!secvar_kset) {
> pr_err("secvar: sysfs kobject registration failed.\n");
> - kobject_put(secvar_kobj);
> - return -ENOMEM;
> + rc = -ENOMEM;
> + goto err;
> }
>
> rc = update_kobj_size();
> if (rc) {
> pr_err("Cannot read the size of the attribute\n");
> - return rc;
> + goto err;
> + }
> +
> + if (secvar_config_attrs) {
> + rc = secvar_sysfs_config(secvar_kobj);
> + if (rc) {
> + pr_err("secvar: Failed to create config directory\n");
> + goto err;
> + }
> }
>
> secvar_sysfs_load();
>
> return 0;
> +err:
> + kobject_put(secvar_kobj);
> + return rc;
> }
>
> late_initcall(secvar_sysfs_init);
> --
> 2.38.1
[PATCH 2/3] powerpc/vmlinux.lds: Don't discard .rela* for relocatable builds
Relocatable kernels must not discard relocations, they need to be
processed at runtime. As such they are included for CONFIG_RELOCATABLE
builds in the powerpc linker script (line 340).
However they are also unconditionally discarded later in the
script (line 414). Previously that worked because the earlier inclusion
superseded the discard.
However commit 99cb0d917ffa ("arch: fix broken BuildID for arm64 and
riscv") introduced an earlier use of DISCARD as part of the RO_DATA
macro (line 137). With binutils < 2.36 that causes the DISCARD
directives later in the script to be applied earlier, causing .rela* to
actually be discarded at link time, leading to build warnings and a
kernel that doesn't boot:
ld: warning: discarding dynamic section .rela.init.rodata
Fix it by conditionally discarding .rela* only when CONFIG_RELOCATABLE
is disabled.
Fixes: 99cb0d917ffa ("arch: fix broken BuildID for arm64 and riscv")
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/vmlinux.lds.S | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index c5ea7d03d539..a4c6efadc90c 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -411,9 +411,12 @@ SECTIONS
DISCARDS
/DISCARD/ : {
*(*.EMB.apuinfo)
- *(.glink .iplt .plt .rela* .comment)
+ *(.glink .iplt .plt .comment)
*(.gnu.version*)
*(.gnu.attributes)
*(.eh_frame)
+#ifndef CONFIG_RELOCATABLE
+ *(.rela*)
+#endif
}
}
--
2.39.0
[PATCH 1/3] powerpc/vmlinux.lds: Define RUNTIME_DISCARD_EXIT
The powerpc linker script explicitly includes .exit.text, because
otherwise the link fails due to references from __bug_table and
__ex_table. The code is freed (discarded) at runtime along with
.init.text and data.
That has worked in the past despite powerpc not defining
RUNTIME_DISCARD_EXIT because DISCARDS appears late in the powerpc linker
script (line 410), and the explicit inclusion of .exit.text
earlier (line 280) supersedes the discard.
However commit 99cb0d917ffa ("arch: fix broken BuildID for arm64 and
riscv") introduced an earlier use of DISCARD as part of the RO_DATA
macro (line 136). With binutils < 2.36 that causes the DISCARD
directives later in the script to be applied earlier [1], causing
.exit.text to actually be discarded at link time, leading to build
errors:
'.exit.text' referenced in section '__bug_table' of crypto/algboss.o: defined
in
discarded section '.exit.text' of crypto/algboss.o
'.exit.text' referenced in section '__ex_table' of drivers/nvdimm/core.o:
defined in
discarded section '.exit.text' of drivers/nvdimm/core.o
Fix it by defining RUNTIME_DISCARD_EXIT, which causes the generic
DISCARDS macro to not include .exit.text at all.
1: https://lore.kernel.org/lkml/87fscp2v7k@igel.home/
Fixes: 99cb0d917ffa ("arch: fix broken BuildID for arm64 and riscv")
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/vmlinux.lds.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index 8c3862b4c259..c5ea7d03d539 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -8,6 +8,7 @@
#define BSS_FIRST_SECTIONS *(.bss.prominit)
#define EMITS_PT_NOTE
#define RO_EXCEPTION_TABLE_ALIGN 0
+#define RUNTIME_DISCARD_EXIT
#define SOFT_MASK_TABLE(align) \
. = ALIGN(align); \
--
2.39.0
[PATCH 3/3] powerpc/vmlinux.lds: Don't discard .comment
Although the powerpc linker script mentions .comment in the DISCARD
section, that has never actually caused it to be discarded, because the
earlier ELF_DETAILS macro (previously STABS_DEBUG) explicitly includes
.comment.
However commit 99cb0d917ffa ("arch: fix broken BuildID for arm64 and
riscv") introduced an earlier use of DISCARD as part of the RO_DATA
macro. With binutils < 2.36 that causes the DISCARD directives later in
the script to be applied earlier, causing .comment to actually be
discarded.
It's confusing to explicitly include and discard .comment, and even more
so if the behaviour depends on the toolchain version. So don't discard
.comment in order to maintain the existing behaviour in all cases.
Fixes: 83a092cf95f2 ("powerpc: Link warning for orphan sections")
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index a4c6efadc90c..958e77a24f85 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -411,7 +411,7 @@ SECTIONS
DISCARDS
/DISCARD/ : {
*(*.EMB.apuinfo)
- *(.glink .iplt .plt .comment)
+ *(.glink .iplt .plt)
*(.gnu.version*)
*(.gnu.attributes)
*(.eh_frame)
--
2.39.0
Re: Linux 6.2-rc2
Ard Biesheuvel writes:
> On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> wrote:
>>
>> On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck wrote:
>> >
>> > ... and reverting commit 99cb0d917ff indeed fixes the problem.
>>
>> Hmm. My gut feel is that this just exposes some bug in binutils.
...
>> It really shouldn't matter, but here we are, with a build problem with
>> some random old binutils on an odd platform..
>>
>
> AIUI, the way ld.bfd used to combine output sections may also affect
> the /DISCARD/ pseudo-section, and so introducing it much earlier
> results in these discards to be interpreted in a different order.
>
> The purpose of this change is to prevent .note.GNU-stack from deciding
> the section type of the .notes output section, and so keeping it in
> its own section should be sufficient. E.g.,
>
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -896,7 +896,7 @@
> * Otherwise, the type of .notes section would become PROGBITS
> instead of NOTES.
> */
> #define NOTES \
> - /DISCARD/ : { *(.note.GNU-stack) } \
> + .note.GNU-stack : { *(.note.GNU-stack) }\
> .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> BOUNDED_SECTION_BY(.note.*, _notes) \
> } NOTES_HEADERS \
This also fixes errors seen in the powerpc build with binutils <= 2.35.
Tested-by: Michael Ellerman (powerpc)
cheers
Re: [PATCH net v2] powerpc: dts: t208x: Disable 10G on MAC1 and MAC2
Jakub Kicinski writes: > On Thu, 22 Dec 2022 15:41:00 + Camelia Alexandra Groza wrote: >> > Reviewed-by: Camelia Groza >> > Tested-by: Camelia Groza >> >> I see the patch marked Not Applicable in the netdev patchwork. >> What tree will it go through? > > I could be wrong but I think DTS patches are supposed to go via the > platform / arch trees. We mostly take bindings via the networking trees > (and DTS changes if they are part of a larger code+binding+dts set). > But we can obviously apply this patch if that's the preference of > the PowerPC maintainers.. The commit it Fixes went in via the networking tree, so I think it would make sense for you to take this also via the networking tree. cheers
Re: [RFC PATCH] mm: remove zap_page_range and change callers to use zap_vma_page_range
Mike Kravetz writes: > zap_page_range was originally designed to unmap pages within an address > range that could span multiple vmas. While working on [1], it was > discovered that all callers of zap_page_range pass a range entirely within > a single vma. In addition, the mmu notification call within zap_page > range does not correctly handle ranges that span multiple vmas as calls > should be vma specific. > > Instead of fixing zap_page_range, change all callers to use the new > routine zap_vma_page_range. zap_vma_page_range is just a wrapper around > zap_page_range_single passing in NULL zap details. The name is also > more in line with other exported routines that operate within a vma. > We can then remove zap_page_range. > > Also, change madvise_dontneed_single_vma to use this new routine. > > [1] > https://lore.kernel.org/linux-mm/20221114235507.294320-2-mike.krav...@oracle.com/ > Suggested-by: Peter Xu > Signed-off-by: Mike Kravetz > --- > arch/arm64/kernel/vdso.c| 4 ++-- > arch/powerpc/kernel/vdso.c | 2 +- > arch/powerpc/platforms/book3s/vas-api.c | 2 +- > arch/powerpc/platforms/pseries/vas.c| 2 +- Acked-by: Michael Ellerman (powerpc) cheers
Re: [PATCH] powerpc/code-patching: Fix oops with DEBUG_VM enabled
On Fri, 16 Dec 2022 23:59:13 +1100, Michael Ellerman wrote: > Nathan reported that the new per-cpu mm patching oopses if DEBUG_VM is > enabled: > > [ cut here ] > kernel BUG at arch/powerpc/mm/pgtable.c:333! > Oops: Exception in kernel mode, sig: 5 [#1] > LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc2+ #1 > Hardware name: IBM PowerNV (emulated by qemu) POWER9 0x4e1200 opal:v7.0 > PowerNV > ... > NIP assert_pte_locked+0x180/0x1a0 > LR assert_pte_locked+0x170/0x1a0 > Call Trace: > 0x6000 (unreliable) > patch_instruction+0x618/0x6d0 > arch_prepare_kprobe+0xfc/0x2d0 > register_kprobe+0x520/0x7c0 > arch_init_kprobes+0x28/0x3c > init_kprobes+0x108/0x184 > do_one_initcall+0x60/0x2e0 > kernel_init_freeable+0x1f0/0x3e0 > kernel_init+0x34/0x1d0 > ret_from_kernel_thread+0x5c/0x64 > > [...] Applied to powerpc/next. [1/1] powerpc/code-patching: Fix oops with DEBUG_VM enabled https://git.kernel.org/powerpc/c/980411a4d1bb925d28cd9e8d8301dc982ece788d cheers
[GIT PULL] Please pull powerpc/linux.git powerpc-6.2-1 tag
00: convert to using gpiod API and facelift Finn Thain (1): macintosh/via-pmu: Avoid compiler warnings when CONFIG_PROC_FS is disabled Geert Uytterhoeven (1): powerpc/dts/fsl: Fix pca954x i2c-mux node names Gustavo A. R. Silva (1): powerpc/xmon: Fix -Wswitch-unreachable warning in bpt_cmds Haowen Bai (5): macintosh/windfarm_pm81: Fix warning comparing pointer to 0 macintosh/adb: Fix warning comparing pointer to 0 macintosh/windfarm_pm91: Fix warning comparing pointer to 0 macintosh/windfarm_pm121: Fix warning comparing pointer to 0 macintosh/macio-adb: Fix warning comparing pointer to 0 Joel Stanley (1): powerpc/microwatt: Add litesd Jordan Niethe (1): powerpc: Allow clearing and restoring registers independent of saved breakpoint state Julia Lawall (1): cxl: fix typo in comment Kajol Jain (2): powerpc/kvm: Remove unused references for MMCR3/SIER2/SIER3 registers powerpc/hv-gpci: Fix hv_gpci event list Laurent Dufour (4): powerpc: export the CPU node count powerpc: Take in account addition CPU node when building kexec FDT powerpc/pseries: reset the RCU watchdogs after a LPM powerpc/pseries: unregister VPA when hot unplugging a CPU Li zeming (2): macintosh/ams/ams: Add header file macro definition macintosh/windfarm_pid: Add header file macro definition Miaoqian Lin (2): cxl: Fix refcount leak in cxl_calc_capp_routing selftests/powerpc: Fix resource leaks Michael Ellerman (10): objtool/powerpc: Implement arch_pc_relative_reloc() Merge branch i2c/client_device_id_helper-immutable of wsa/linux into next powerpc: Make instruction dump work with scripts/decodecode powerpc: Print instruction dump on a single line Merge branch 'topic/ppc-kvm' into next Merge branch 'fixes' into next Merge branch 'topic/qspinlock' into next powerpc/prom: Fix 32-bit build Merge branch 'topic/objtool' into next powerpc/code-patching: Fix oops with DEBUG_VM enabled Michael Jeanson (1): powerpc/ftrace: fix syscall tracing on PPC64_ELF_ABI_V1 Nathan Lynch (9): powerpc/rtas: document rtas_call() powerpc/rtasd: use correct OF API for event scan rate powerpc/rtas: avoid device tree lookups in rtas_os_term() powerpc/rtas: avoid scheduling in rtas_os_term() powerpc/pseries/eeh: use correct API for error log size powerpc/rtas: clean up rtas_error_log_max initialization powerpc/rtas: clean up includes powerpc/rtas: define pr_fmt and convert printk call sites powerpc/rtas: mandate RTAS syscall filtering Naveen N. Rao (7): powerpc/ftrace: Ignore weak functions powerpc/kprobes: Remove preempt disable around call to get_kprobe() in arch_prepare_kprobe() powerpc/kprobes: Have optimized_callback() use preempt_enable() powerpc/kprobes: Use preempt_enable() rather than the no_resched variant selftests/powerpc: Move perror closer to its use selftests/powerpc: Bump up rlimit for perf-hwbreak test selftests/powerpc: Account for offline cpus in perf-hwbreak test Nayna Jain (6): powerpc/pseries: fix the object owners enum value in plpks driver powerpc/pseries: Fix the H_CALL error code in PLPKS driver powerpc/pseries: Return -EIO instead of -EINTR for H_ABORTED error powerpc/pseries: cleanup error logs in plpks driver powerpc/pseries: replace kmalloc with kzalloc in PLPKS driver powerpc/pseries: fix plpks_read_var() code for different consumers Nicholas Miehlbradt (1): docs: powerpc: add POWER9 and POWER10 to CPU families Nicholas Piggin (43): powerpc: add compile-time support for lbarx, lharx powerpc: remove the last remnants of cputime_t KVM: PPC: Book3E: Fix CONFIG_TRACE_IRQFLAGS support powerpc/qspinlock: powerpc qspinlock implementation powerpc/qspinlock: add mcs queueing for contended waiters powerpc/qspinlock: use a half-word store to unlock to avoid larx/stcx. powerpc/qspinlock: convert atomic operations to assembly powerpc/qspinlock: allow new waiters to steal the lock before queueing powerpc/qspinlock: theft prevention to control latency powerpc/qspinlock: store owner CPU in lock word powerpc/qspinlock: paravirt yield to lock owner powerpc/qspinlock: implement option to yield to previous node powerpc/qspinlock: allow stealing when head of queue yields powerpc/qspinlock: allow propagation of yield CPU down the queue powerpc/qspinlock: add ability to prod new queue head CPU powerpc/qspinlock: allow lock stealing in trylock and lock fastpath powerpc/qspinlock: use spin_begin/end API powerpc/qspinlock: reduce remote node steal spins powerpc/qspinlock: allow indefinite spinning on a preempted owner powerpc/qspinlock: provide accounting and options for sleepy locks powerpc/qspinloc
[PATCH] powerpc/code-patching: Fix oops with DEBUG_VM enabled
Nathan reported that the new per-cpu mm patching oopses if DEBUG_VM is
enabled:
[ cut here ]
kernel BUG at arch/powerpc/mm/pgtable.c:333!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc2+ #1
Hardware name: IBM PowerNV (emulated by qemu) POWER9 0x4e1200 opal:v7.0
PowerNV
...
NIP assert_pte_locked+0x180/0x1a0
LR assert_pte_locked+0x170/0x1a0
Call Trace:
0x6000 (unreliable)
patch_instruction+0x618/0x6d0
arch_prepare_kprobe+0xfc/0x2d0
register_kprobe+0x520/0x7c0
arch_init_kprobes+0x28/0x3c
init_kprobes+0x108/0x184
do_one_initcall+0x60/0x2e0
kernel_init_freeable+0x1f0/0x3e0
kernel_init+0x34/0x1d0
ret_from_kernel_thread+0x5c/0x64
It's caused by the assert_spin_locked() failing in assert_pte_locked().
The assert fails because the PTE was unlocked in text_area_cpu_up_mm(),
and never relocked.
The PTE page shouldn't be freed, the patching_mm is only used for
patching on this CPU, only that single PTE is ever mapped, and it's only
unmapped at CPU offline.
In fact assert_pte_locked() has a special case to ignore init_mm
entirely, and the patching_mm is more-or-less like init_mm, so possibly
the check could be skipped for patching_mm too.
But for now be conservative, and use the proper PTE accessors at
patching time, so that the PTE lock is held while the PTE is used. That
also avoids the warning in assert_pte_locked().
With that it's no longer necessary to save the PTE in
cpu_patching_context for the mm_patch_enabled() case.
Fixes: c28c15b6d28a ("powerpc/code-patching: Use temporary mm for Radix MMU")
Reported-by: Nathan Chancellor
Signed-off-by: Michael Ellerman
---
arch/powerpc/lib/code-patching.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 73ce4b90bb1b..b00112d7ad46 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -178,7 +178,6 @@ static int text_area_cpu_up_mm(unsigned int cpu)
this_cpu_write(cpu_patching_context.mm, mm);
this_cpu_write(cpu_patching_context.addr, addr);
- this_cpu_write(cpu_patching_context.pte, pte);
return 0;
@@ -195,7 +194,6 @@ static int text_area_cpu_down_mm(unsigned int cpu)
this_cpu_write(cpu_patching_context.mm, NULL);
this_cpu_write(cpu_patching_context.addr, 0);
- this_cpu_write(cpu_patching_context.pte, NULL);
return 0;
}
@@ -289,12 +287,16 @@ static int __do_patch_instruction_mm(u32 *addr,
ppc_inst_t instr)
unsigned long pfn = get_patch_pfn(addr);
struct mm_struct *patching_mm;
struct mm_struct *orig_mm;
+ spinlock_t *ptl;
patching_mm = __this_cpu_read(cpu_patching_context.mm);
- pte = __this_cpu_read(cpu_patching_context.pte);
text_poke_addr = __this_cpu_read(cpu_patching_context.addr);
patch_addr = (u32 *)(text_poke_addr + offset_in_page(addr));
+ pte = get_locked_pte(patching_mm, text_poke_addr, );
+ if (!pte)
+ return -ENOMEM;
+
__set_pte_at(patching_mm, text_poke_addr, pte, pfn_pte(pfn,
PAGE_KERNEL), 0);
/* order PTE update before use, also serves as the hwsync */
@@ -321,6 +323,8 @@ static int __do_patch_instruction_mm(u32 *addr, ppc_inst_t
instr)
*/
local_flush_tlb_page_psize(patching_mm, text_poke_addr,
mmu_virtual_psize);
+ pte_unmap_unlock(pte, ptl);
+
return err;
}
--
2.38.1
Re: Mass-building defconfigs: many fail with assembler errors
Jan-Benedict Glaw writes:
> On Tue, 2022-12-13 14:49:20 +1100, Michael Ellerman
> wrote:
> [...]
>> Both treeboot-akebono.c and treeboot-currituck.c are for 476 so should
>> probably be built with -mcpu=476. eg:
>>
>> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
>> index d32d95aea5d6..acb6eddace8f 100644
>> --- a/arch/powerpc/boot/Makefile
>> +++ b/arch/powerpc/boot/Makefile
>> @@ -88,8 +88,8 @@ $(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=440
>> $(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=440
>> $(obj)/cuboot-acadia.o: BOOTCFLAGS += -mcpu=405
>> $(obj)/treeboot-iss4xx.o: BOOTCFLAGS += -mcpu=405
>> -$(obj)/treeboot-currituck.o: BOOTCFLAGS += -mcpu=405
>> -$(obj)/treeboot-akebono.o: BOOTCFLAGS += -mcpu=405
>> +$(obj)/treeboot-currituck.o: BOOTCFLAGS += -mcpu=476
>> +$(obj)/treeboot-akebono.o: BOOTCFLAGS += -mcpu=476
>>
>> # The pre-boot decompressors pull in a lot of kernel headers and other
>> source
>> # files. This creates a bit of a dependency headache since we need to copy
>
> With this patch applied, it seems this fixes these asm-related builds:
>
> linux-powerpc-bamboo_defconfig
> linux-powerpc-cell_defconfig
> linux-powerpc-ebony_defconfig
> linux-powerpc-katmai_defconfig
> linux-powerpc-ppc44x_defconfig
> linux-powerpc-rainier_defconfig
> linux-powerpc-sam440ep_defconfig
> linux-powerpc-sequoia_defconfig
> linux-powerpc-taishan_defconfig
Thanks.
> ...while three remain unresolved:
>
> linux-powerpc-asp8347_defconfig
OK. Patch below which I believe fixes that.
diff --git a/arch/powerpc/include/asm/reg_fsl_emb.h
b/arch/powerpc/include/asm/reg_fsl_emb.h
index a21f529c43d9..8359c06d92d9 100644
--- a/arch/powerpc/include/asm/reg_fsl_emb.h
+++ b/arch/powerpc/include/asm/reg_fsl_emb.h
@@ -12,9 +12,16 @@
#ifndef __ASSEMBLY__
/* Performance Monitor Registers */
#define mfpmr(rn) ({unsigned int rval; \
- asm volatile("mfpmr %0," __stringify(rn) \
+ asm volatile(".machine push; " \
+".machine e300; " \
+"mfpmr %0," __stringify(rn) ";" \
+".machine pop; " \
: "=r" (rval)); rval;})
-#define mtpmr(rn, v) asm volatile("mtpmr " __stringify(rn) ",%0" : : "r" (v))
+#define mtpmr(rn, v) asm volatile(".machine push; " \
+".machine e300; " \
+"mtpmr " __stringify(rn) ",%0; " \
+".machine pop; " \
+: : "r" (v))
#endif /* __ASSEMBLY__ */
/* Freescale Book E Performance Monitor APU Registers */
> linux-powerpc-mvme5100_defconfig
And another:
diff --git a/arch/powerpc/kernel/epapr_hcalls.S
b/arch/powerpc/kernel/epapr_hcalls.S
index 69a912550577..1ed73ab30288 100644
--- a/arch/powerpc/kernel/epapr_hcalls.S
+++ b/arch/powerpc/kernel/epapr_hcalls.S
@@ -21,7 +21,10 @@ _GLOBAL(epapr_ev_idle)
ori r4, r4,_TLF_NAPPING /* so when we take an exception */
PPC_STL r4, TI_LOCAL_FLAGS(r2) /* it will return to our caller */
+ .machine push
+ .machine booke
wrteei 1
+ .machine pop
idle_loop:
LOAD_REG_IMMEDIATE(r11, EV_HCALL_TOKEN(EV_IDLE))
Not sure if that's the best solution, but it will at least unblock you
and allow you to actually test GCC which is I assume your goal.
> linux-powerpc-ppc64e_defconfig
TBD.
> Of course I cannot verify the resulting kernel binaries, but I guess
> you'd push this patch.
I don't have the hardware for most of these old boards, but I'll test
what I can, and yes I'd take the patch.
cheers
Re: sched/debug: CPU hotplug operation suffers in a large cpu systems
Phil Auld writes:
> On Tue, Dec 13, 2022 at 07:23:54AM +0100 Greg Kroah-Hartman wrote:
>> On Mon, Dec 12, 2022 at 02:17:58PM -0500, Phil Auld wrote:
>> > Hi,
>> >
>> > On Tue, Nov 08, 2022 at 01:24:39PM +0100 Greg Kroah-Hartman wrote:
>> > > On Tue, Nov 08, 2022 at 03:30:46PM +0530, Vishal Chourasia wrote:
>> > > >
>> > > > Thanks Greg & Peter for your direction.
>> > > >
>> > > > While we pursue the idea of having debugfs based on kernfs, we thought
>> > > > about
>> > > > having a boot time parameter which would disable creating and updating
>> > > > of the
>> > > > sched_domain debugfs files and this would also be useful even when the
>> > > > kernfs
>> > > > solution kicks in, as users who may not care about these debugfs files
>> > > > would
>> > > > benefit from a faster CPU hotplug operation.
>> > >
>> > > Ick, no, you would be adding a new user/kernel api that you will be
>> > > required to support for the next 20+ years. Just to get over a
>> > > short-term issue before you solve the problem properly.
>> >
>> > I'm not convinced moving these files from debugfs to kernfs is the right
>> > fix. That will take it from ~50 back to ~20 _minutes_ on these systems.
>> > I don't think either of those numbers is reasonable.
>> >
>> > The issue as I see it is the full rebuild for every change with no way to
>> > batch the changes. How about something like the below?
>> >
>> > This puts the domains/* files under the sched_verbose flag. About the only
>> > thing under that flag now are the detailed topology discovery printks
>> > anyway
>> > so this fits together nicely.
>> >
>> > This way the files would be off by default (assuming you don't boot with
>> > sched_verbose) and can be created at runtime by enabling verbose. Multiple
>> > changes could also be batched by disabling/makeing changes/re-enabling.
>> >
>> > It does not create a new API, uses one that is already there.
>>
>> The idea seems good, the implementation might need a bit of work :)
>
> More than the one comment below? Let me know.
>
>>
>> > > If you really do not want these debugfs files, just disable debugfs from
>> > > your system. That should be a better short-term solution, right?
>> >
>> > We do find these files useful at times for debugging issue and looking
>> > at what's going on on the system.
>> >
>> > >
>> > > Or better yet, disable SCHED_DEBUG, why can't you do that?
>> >
>> > Same with this... useful information with (modulo issues like this)
>> > small cost. There are also tuning knobs that are only available
>> > with SCHED_DEBUG.
>> >
>> >
>> > Cheers,
>> > Phil
>> >
>> > ---
>> >
>> > sched/debug: Put sched/domains files under verbose flag
>> >
>> > The debug files under sched/domains can take a long time to regenerate,
>> > especially when updates are done one at a time. Move these files under
>> > the verbose debug flag. Allow changes to verbose to trigger generation
>> > of the files. This lets a user batch the updates but still have the
>> > information available. The detailed topology printk messages are also
>> > under verbose.
>> >
>> > Signed-off-by: Phil Auld
>> > ---
>> > kernel/sched/debug.c | 68 ++--
>> > 1 file changed, 66 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
>> > index 1637b65ba07a..2eb51ee3ccab 100644
>> > --- a/kernel/sched/debug.c
>> > +++ b/kernel/sched/debug.c
>> > @@ -280,6 +280,31 @@ static const struct file_operations
>> > sched_dynamic_fops = {
>> >
>> > __read_mostly bool sched_debug_verbose;
>> >
>> > +static ssize_t sched_verbose_write(struct file *filp, const char __user
>> > *ubuf,
>> > + size_t cnt, loff_t *ppos);
>> > +
>> > +static int sched_verbose_show(struct seq_file *m, void *v)
>> > +{
>> > + if (sched_debug_verbose)
>> > + seq_puts(m,"Y\n");
>> > + else
>> > + seq_puts(m,"N\n");
>> > + return 0;
>> > +}
>> > +
>> > +static int sched_verbose_open(struct inode *inode, struct file *filp)
>> > +{
>> > + return single_open(filp, sched_verbose_show, NULL);
>> > +}
>> > +
>> > +static const struct file_operations sched_verbose_fops = {
>> > + .open = sched_verbose_open,
>> > + .write = sched_verbose_write,
>> > + .read = seq_read,
>> > + .llseek = seq_lseek,
>> > + .release= seq_release,
>> > +};
>> > +
>> > static const struct seq_operations sched_debug_sops;
>> >
>> > static int sched_debug_open(struct inode *inode, struct file *filp)
>> > @@ -303,7 +328,7 @@ static __init int sched_init_debug(void)
>> >debugfs_sched = debugfs_create_dir("sched", NULL);
>> >
>> >debugfs_create_file("features", 0644, debugfs_sched, NULL,
>> > _feat_fops);
>> > - debugfs_create_bool("verbose", 0644, debugfs_sched,
>> > _debug_verbose);
>> > + debugfs_create_file("verbose", 0644, debugfs_sched, NULL,
>> > _verbose_fops);
>> > #ifdef
Re: Mass-building defconfigs: many fail with assembler errors
Jan-Benedict Glaw writes:
> Hi!
>
> Is anybody else routinely building current Binutils + GCC, to try to
> build all the Linux defconfigs?
I did for several years, but eventually stopped because it was taking
too much time I needed to spend on other things.
> For PPC, a good number of those fail,
> and I probably don't understand PPC well enough to propose patches. Or
> did I pick wrongly targeted toolchains? Most of the time, my suspicion
> is that we're not giving the correct -m flags in
> ./arch/powerpc/boot/? (My setup for doing test builds is fairly automated, I
> can easily throw in patches for testing.)
All the results against .config are invalid or at least
dubious. Those files are not standalone defconfigs, they're fragments of
defconfigs that are assembled together by arch/powerpc/Makefile using
merge_config.sh.
So your script should exclude all files that end in ".config".
To find the names of the generated configs you can use something like:
$ awk '/PHONY \+= .*config/ {print $3}' arch/powerpc/Makefile
> 64-bit.config
> powerpc64-linux-gcc -Wp,-MD,arch/powerpc/boot/.opal-calls.o.d
> -D__ASSEMBLY__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
> -fno-strict-aliasing -O2 -msoft-float -mno-altivec -mno-vsx -pipe
> -fomit-frame-pointer -fno-builtin -fPIC -nostdinc -I./arch/powerpc/include
> -I./arch/powerpc/include/generated -I./include -I./arch/powerpc/include/uapi
> -I./arch/powerpc/include/generated/uapi -I./include/uapi
> -I./include/generated/uapi -include ./include/linux/compiler-version.h
> -include ./include/linux/kconfig.h -m32 -mcpu=powerpc -isystem
> /var/lib/laminar/run/linux-powerpc-64-bit.config/12/toolchain/bin/../lib/gcc/powerpc64-linux/13.0.0/include
> -mbig-endian -nostdinc -c -o arch/powerpc/boot/opal-calls.o
> arch/powerpc/boot/opal-calls.S
> arch/powerpc/boot/opal-calls.S: Assembler messages:
> arch/powerpc/boot/opal-calls.S:20: Error: unrecognized opcode: `ld'
> arch/powerpc/boot/opal-calls.S:21: Error: unrecognized opcode: `ld'
> arch/powerpc/boot/opal-calls.S:32: Error: unrecognized opcode: `std'
> arch/powerpc/boot/opal-calls.S:49: Error: unrecognized opcode: `ld'
> arch/powerpc/boot/opal-calls.S:50: Error: unrecognized opcode: `ld'
> arch/powerpc/boot/opal-calls.S:52: Error: unrecognized opcode: `hrfid'
> arch/powerpc/boot/opal-calls.S:55: Error: unrecognized opcode: `tdi'
> arch/powerpc/boot/opal-calls.S:58: Error: unrecognized opcode: `ld'
> make[1]: *** [arch/powerpc/boot/Makefile:232:
> arch/powerpc/boot/opal-calls.o] Error 1
> make: *** [arch/powerpc/Makefile:247: zImage] Error 2
...
> bamboo_defconfig
> powerpc-linux-gcc -Wp,-MD,arch/powerpc/boot/.treeboot-akebono.o.d
> -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -O2
> -msoft-float -mno-altivec -mno-vsx -pipe -fomit-frame-pointer -fno-builtin
> -fPIC -nostdinc -I./arch/powerpc/include -I./arch/powerpc/include/generated
> -I./include -I./arch/powerpc/include/uapi
> -I./arch/powerpc/include/generated/uapi -I./include/uapi
> -I./include/generated/uapi -include ./include/linux/compiler-version.h
> -include ./include/linux/kconfig.h -m32 -mcpu=powerpc -isystem
> /var/lib/laminar/run/linux-powerpc-bamboo_defconfig/12/toolchain/bin/../lib/gcc/powerpc-linux/13.0.0/include
> -mbig-endian -fno-stack-protector -include
> ./include/linux/compiler_attributes.h -I./arch/powerpc/boot
> -I./arch/powerpc/boot -mcpu=405 -c -o arch/powerpc/boot/treeboot-akebono.o
> arch/powerpc/boot/treeboot-akebono.c
> {standard input}: Assembler messages:
> {standard input}:94: Error: unrecognized opcode: `mtdcrx'
> {standard input}:101: Error: unrecognized opcode: `mfdcrx'
> {standard input}:107: Error: unrecognized opcode: `mtdcrx'
> {standard input}:306: Error: unrecognized opcode: `mfdcrx'
> make[1]: *** [arch/powerpc/boot/Makefile:229:
> arch/powerpc/boot/treeboot-akebono.o] Error 1
> make: *** [arch/powerpc/Makefile:247: zImage] Error 2
Both treeboot-akebono.c and treeboot-currituck.c are for 476 so should
probably be built with -mcpu=476. eg:
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index d32d95aea5d6..acb6eddace8f 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -88,8 +88,8 @@ $(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=440
$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=440
$(obj)/cuboot-acadia.o: BOOTCFLAGS += -mcpu=405
$(obj)/treeboot-iss4xx.o: BOOTCFLAGS += -mcpu=405
-$(obj)/treeboot-currituck.o: BOOTCFLAGS += -mcpu=405
-$(obj)/treeboot-akebono.o: BOOTCFLAGS += -mcpu=405
+$(obj)/treeboot-currituck.o: BOOTCFLAGS += -mcpu=476
+$(obj)/treeboot-akebono.o: BOOTCFLAGS += -mcpu=476
# The pre-boot decompressors pull in a lot of kernel headers and other source
# files. This creates a bit of a dependency headache since we need to copy
> cell_defconfig
> powerpc64-linux-gcc
Re: [PATCH] powerpc/qspinlock: Fix 32-bit build
On Thu, 8 Dec 2022 22:32:25 +1000, Nicholas Piggin wrote: > Some 32-bit configurations don't pull in the spin_begin/end/relax > definitions. Fix is to restore a lost include. > > Applied to powerpc/next. [1/1] powerpc/qspinlock: Fix 32-bit build https://git.kernel.org/powerpc/c/13959373e9c9021cc80730c7bd1242e07b10b328 cheers
Re: [PATCH v1 5/5] powerpc/64e: Fix build failure with GCC 12 (unrecognized opcode: `wrteei')
Christophe Leroy writes:
> Le 11/12/2022 à 18:32, Pali Rohár a écrit :
>> On Monday 11 July 2022 16:19:33 Christophe Leroy wrote:
>>> With GCC 12, corenet64_smp_defconfig leads to the following build errors:
>>>
>>>CC arch/powerpc/kernel/irq.o
>>> {standard input}: Assembler messages:
>>> {standard input}:3616: Error: unrecognized opcode: `wrteei'
>>> {standard input}:5689: Error: unrecognized opcode: `wrteei'
>>>CC arch/powerpc/kernel/pmc.o
>>> {standard input}: Assembler messages:
>>> {standard input}:42: Error: unrecognized opcode: `mfpmr'
>>> {standard input}:53: Error: unrecognized opcode: `mtpmr'
>>>CC arch/powerpc/kernel/io.o
>>> {standard input}: Assembler messages:
>>> {standard input}:376: Error: unrecognized opcode: `mbar'
>>> ...
>>>CC arch/powerpc/mm/nohash/book3e_hugetlbpage.o
>>> {standard input}: Assembler messages:
>>> {standard input}:291: Error: unrecognized opcode: `tlbsx'
>>> {standard input}:482: Error: unrecognized opcode: `tlbwe'
>>> {standard input}:608: Error: unrecognized opcode: `lbarx'
>>> {standard input}:608: Error: unrecognized opcode: `stbcx.'
>>>
>>> -mpcu=powerpc64 cannot be used anymore for book3e, it must be a booke CPU.
>>>
>>> But then we get:
>>>
>>>CC arch/powerpc/lib/xor_vmx.o
>>> cc1: error: AltiVec not supported in this target
>>>
>>> Altivec is not supported with -mcpu=e5500 so don't allow selection
>>> of altivec when e5500 is selected.
>>>
>>> Signed-off-by: Christophe Leroy
>>> ---
>>> arch/powerpc/Makefile | 8 +---
>>> arch/powerpc/platforms/Kconfig.cputype | 8
>>> 2 files changed, 5 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
>>> index d54e1fe03551..02742facf895 100644
>>> --- a/arch/powerpc/Makefile
>>> +++ b/arch/powerpc/Makefile
>>> @@ -168,13 +168,7 @@ endif
>>> CFLAGS-$(CONFIG_TARGET_CPU_BOOL) += $(call
>>> cc-option,-mcpu=$(CONFIG_TARGET_CPU))
>>> AFLAGS-$(CONFIG_TARGET_CPU_BOOL) += $(call
>>> cc-option,-mcpu=$(CONFIG_TARGET_CPU))
>>>
>>> -# Altivec option not allowed with e500mc64 in GCC.
>>> -ifdef CONFIG_ALTIVEC
>>> -E5500_CPU := -mcpu=powerpc64
>>> -else
>>> -E5500_CPU := $(call cc-option,-mcpu=e500mc64,-mcpu=powerpc64)
>>> -endif
>>> -CFLAGS-$(CONFIG_E5500_CPU) += $(E5500_CPU)
>>> +CFLAGS-$(CONFIG_E5500_CPU) += $(call
>>> cc-option,-mcpu=e500mc64,-mcpu=powerpc64)
>>> CFLAGS-$(CONFIG_E6500_CPU) += $(call cc-option,-mcpu=e6500,$(E5500_CPU))
>>
>> Hello! I think that there is an issue. After removal of E5500_CPU
>> variable few line above, it cannot be used in CFLAGS-$(CONFIG_E6500_CPU)
>> assignment, because it is empty.
>>
>
> Ah yes, you are right.
>
> It should be fixed by
> https://github.com/linuxppc/linux/commit/f2636eaac7dee1d7d096cc115ff4f5111b0c508c
>
> Michael, I see the patch is in next-test. Can you add:
>
> Fixes: d6b551b8f90c ("powerpc/64e: Fix build failure with GCC 12
> (unrecognized opcode: `wrteei')")
Yep, will do.
cheers
Re: [PATCH v6 00/16] objtool: Enable and implement --mcount option on powerpc
On Mon, 14 Nov 2022 23:27:38 +0530, Sathvika Vasireddy wrote: > This patchset enables and implements objtool --mcount > option on powerpc. This applies atop powerpc/merge branch. > > Changelog: > > > v6: > > [...] Applied to powerpc/next (and topic/objtool). [01/16] powerpc: Fix __WARN_FLAGS() for use with Objtool https://git.kernel.org/powerpc/c/93e3f45a26310e3f3f8558be40df411e23ab742c [02/16] powerpc: Override __ALIGN and __ALIGN_STR macros https://git.kernel.org/powerpc/c/01f2cf0b990e58ae89142f57c7e02d33621311d2 [03/16] powerpc: Fix objtool unannotated intra-function call warnings https://git.kernel.org/powerpc/c/29a011fc79e625b2b02f25262657f7c4c59ae9f7 [04/16] powerpc: Curb objtool unannotated intra-function call warnings https://git.kernel.org/powerpc/c/8d0c21b50655bfe136a76cf384495ba1f9c87224 [05/16] powerpc: Skip objtool from running on drivers/crypto/vmx/aesp8-ppc.o https://git.kernel.org/powerpc/c/1c137323e9a2a970b4a5bf8cf3c50e0ea1cefbeb [06/16] powerpc: Fix objtool unannotated intra-function call warnings on PPC32 https://git.kernel.org/powerpc/c/2da37761671b5bdedbe04e6469cfa57cd6b6ae45 [07/16] powerpc: Skip objtool from running on VDSO files https://git.kernel.org/powerpc/c/d0160bd5d389da247fb5affb6a35ea393d22fedb [08/16] objtool: Fix SEGFAULT https://git.kernel.org/powerpc/c/efb11fdb3e1a9f694fa12b70b21e69e55ec59c36 [09/16] objtool: Use target file endianness instead of a compiled constant https://git.kernel.org/powerpc/c/0646c28b417b7fe307c9da72ca1c508e43b57dc0 [10/16] objtool: Use target file class size instead of a compiled constant https://git.kernel.org/powerpc/c/86ea7f361537f825a699e86fdc9e49be19f128d1 [11/16] objtool: Add --mnop as an option to --mcount https://git.kernel.org/powerpc/c/280981d6994e0700abd36647b141e73059851e66 [12/16] objtool: Read special sections with alts only when specific options are selected https://git.kernel.org/powerpc/c/de6fbcedf5abce4c321eeb15d7d286b79804b8b6 [13/16] objtool: Use macros to define arch specific reloc types https://git.kernel.org/powerpc/c/c1449735211dd8c4c2d54fa0ece6890ecbd74e24 [14/16] objtool: Add arch specific function arch_ftrace_match() https://git.kernel.org/powerpc/c/4ca993d498987332ceeedee5380101b84accaf35 [15/16] objtool/powerpc: Enable objtool to be built on ppc https://git.kernel.org/powerpc/c/e52ec98c5ab18c0710ea22bf52f45e60a725adaf [16/16] objtool/powerpc: Add --mcount specific implementation https://git.kernel.org/powerpc/c/c984aef8c8326035570ff6e01d0ff9e79a5dfa76 cheers
Re: [PATCH] powerpc/64s: Add missing declaration for machine_check_early_boot()
On Sat, 26 Nov 2022 00:25:21 +1100, Michael Ellerman wrote: > There's no declaration for machine_check_early_boot(), which leads to a > build failure with W=1. Add one. > > Applied to powerpc/fixes. [1/1] powerpc/64s: Add missing declaration for machine_check_early_boot() https://git.kernel.org/powerpc/c/2e7ec190a0e38aaa8a6d87fd5f804ec07947febc cheers
Re: [PATCH v2] powerpc/bpf/32: Fix Oops on tail call tests
On Thu, 24 Nov 2022 09:37:27 +0100, Christophe Leroy wrote: > test_bpf tail call tests end up as: > > test_bpf: #0 Tail call leaf jited:1 85 PASS > test_bpf: #1 Tail call 2 jited:1 111 PASS > test_bpf: #2 Tail call 3 jited:1 145 PASS > test_bpf: #3 Tail call 4 jited:1 170 PASS > test_bpf: #4 Tail call load/store leaf jited:1 190 PASS > test_bpf: #5 Tail call load/store jited:1 > BUG: Unable to handle kernel data access on write at 0xf1b4e000 > Faulting instruction address: 0xbe86b710 > Oops: Kernel access of bad area, sig: 11 [#1] > BE PAGE_SIZE=4K MMU=Hash PowerMac > Modules linked in: test_bpf(+) > CPU: 0 PID: 97 Comm: insmod Not tainted 6.1.0-rc4+ #195 > Hardware name: PowerMac3,1 750CL 0x87210 PowerMac > NIP: be86b710 LR: be857e88 CTR: be86b704 > REGS: f1b4df20 TRAP: 0300 Not tainted (6.1.0-rc4+) > MSR: 9032 CR: 28008242 XER: > DAR: f1b4e000 DSISR: 4200 > GPR00: 0001 f1b4dfe0 c11d2280 0002 > > GPR08: f1b4e000 be86b704 f1b4e000 100d816a f244 > fe73baa8 > GPR16: f2458000 c1941ae4 f1fe2248 0045 c0de f2458030 > > GPR24: 03e8 000f f2458000 f1b4dc90 3e584b46 f24466a0 > c1941a00 > NIP [be86b710] 0xbe86b710 > LR [be857e88] __run_one+0xec/0x264 [test_bpf] > Call Trace: > [f1b4dfe0] [0002] 0x2 (unreliable) > Instruction dump: > > > ---[ end trace ]--- > > [...] Applied to powerpc/fixes. [1/1] powerpc/bpf/32: Fix Oops on tail call tests https://git.kernel.org/powerpc/c/89d21e259a94f7d5582ec675aa445f5a79f347e4 cheers
Re: [PATCH v2] powerpc/83xx/mpc832x_rdb: call platform_device_put() in error case in of_fsl_spi_probe()
On Sat, 29 Oct 2022 19:16:26 +0800, Yang Yingliang wrote: > If platform_device_add() is not called or failed, it can not call > platform_device_del() to clean up memory, it should call > platform_device_put() in error case. > > Applied to powerpc/next. [1/1] powerpc/83xx/mpc832x_rdb: call platform_device_put() in error case in of_fsl_spi_probe() https://git.kernel.org/powerpc/c/4d0eea415216fe3791da2f65eb41399e70c7bedf cheers
Re: [PATCH] selftests: powerpc: Use "grep -E" instead of "egrep"
On Thu, 1 Dec 2022 10:49:57 +0800, Tiezhu Yang wrote: > The latest version of grep claims the egrep is now obsolete so the build > now contains warnings that look like: > egrep: warning: egrep is obsolescent; using grep -E > fix this using "grep -E" instead. > > sed -i "s/egrep/grep -E/g" `grep egrep -rwl tools/testing/selftests/powerpc` > > [...] Applied to powerpc/next. [1/1] selftests: powerpc: Use "grep -E" instead of "egrep" https://git.kernel.org/powerpc/c/5921eb36d2a1b276b16a24e529788550e6a65449 cheers
Re: [PATCH] KVM: PPC: Use the arg->size directly for kvm_vm_ioctl_create_spapr_tce
On Sun, 3 Jul 2022 13:29:32 -0400, Deming Wang wrote: > Use arg->size directly may be better for code readability.Because, the > variable of size has not been found for special purpose at present. > Also,We can reduce the use of a variable. > > Applied to powerpc/next. [1/1] KVM: PPC: Use the arg->size directly for kvm_vm_ioctl_create_spapr_tce https://git.kernel.org/powerpc/c/6fa1efeaa6671fb7339a6c62ceeec19e8e787963 cheers
Re: [PATCH v5 1/7] powerpc/64: Add INTERRUPT_SANITIZE_REGISTERS Kconfig
On Thu, 1 Dec 2022 18:10:13 +1100, Rohan McLure wrote: > Add Kconfig option for enabling clearing of registers on arrival in an > interrupt handler. This reduces the speculation influence of registers > on kernel internals. The option will be consumed by 64-bit systems that > feature speculation and wish to implement this mitigation. > > This patch only introduces the Kconfig option, no actual mitigations. > > [...] Applied to powerpc/next. [1/7] powerpc/64: Add INTERRUPT_SANITIZE_REGISTERS Kconfig https://git.kernel.org/powerpc/c/0e23347f1e0f2b1c98f87a4088231d0d6f59b962 [2/7] powerpc/64: Add interrupt register sanitisation macros https://git.kernel.org/powerpc/c/cbf892ba56677b942020d2bc7ca9b79281fa0bcc [3/7] powerpc/64: Sanitise common exit code for interrupts https://git.kernel.org/powerpc/c/75c5d6b1e194c341371639469fcb8691afa0e254 [4/7] powerpc/64s: IOption for MSR stored in r12 https://git.kernel.org/powerpc/c/2487fd2e6d61b5293eed8ecd25add3cc78593d38 [5/7] powerpc/64s: Zeroise gprs on interrupt routine entry on Book3S https://git.kernel.org/powerpc/c/1df45d78b8a89da6544fab5267e8f5da15073d28 [6/7] powerpc/64e: Clear gprs on interrupt routine entry on Book3E https://git.kernel.org/powerpc/c/efe1691ac814e4cf3653538b701662cbd905bddc [7/7] powerpc/64: Sanitise user registers on interrupt in pseries, POWERNV https://git.kernel.org/powerpc/c/7cd882df9485988f7d9b3fae04fde4e95a4c7a74 cheers
Re: [PATCH] powerpc/fsl-pci: Choose PCI host bridge with alias pci0 as the primary
On Sat, 20 Aug 2022 14:33:27 +0200, Pali Rohár wrote: > If there's no PCI host bridge with ISA then check for PCI host bridge with > alias "pci0" (first PCI host bridge) and if it exists then choose it as the > primary PCI host bridge. > > This makes choice of primary PCI host bridge more stable across boots and > updates as the last fallback candidate for primary PCI host bridge (if > there is no choice) is selected arbitrary. > > [...] Applied to powerpc/next. [1/1] powerpc/fsl-pci: Choose PCI host bridge with alias pci0 as the primary https://git.kernel.org/powerpc/c/e082e99f6f87f5204b2531d5a3db7bbd929d23b1 cheers
