* RE: [PATCH 04/14] x86: use more conventional access_ok() definition
From: David Laight @ 2022-02-14 22:13 UTC (permalink / raw)
To: 'Linus Torvalds', Arnd Bergmann
Cc: Mark Rutland, Rich Felker, linux-ia64@vger.kernel.org,
Linux-sh list, Peter Zijlstra, Linux Kernel Mailing List,
Max Filippov, Guo Ren, sparclinux, linux-riscv, Will Deacon,
Ard Biesheuvel, linux-arch, linux-s390, Brian Cain,
open list:QUALCOMM HEXAGON..., Helge Deller,
the arch/x86 maintainers, Russell King - ARM Linux,
linux-csky@vger.kernel.org, Christoph Hellwig, Christoph Hellwig,
Ingo Molnar, Geert Uytterhoeven,
open list:SYNOPSYS ARC ARCHITECTURE,
open list:TENSILICA XTENSA PORT (xtensa), Arnd Bergmann,
Heiko Carstens, alpha, linux-um, linux-m68k, Openrisc,
Greentime Hu, Stafford Horne, Linux ARM, Michal Simek,
Thomas Bogendoerfer, Parisc List, Nick Hu, Linux-MM, Linux API,
open list:BROADCOM NVRAM DRIVER, Dinh Nguyen, Eric W . Biederman,
Richard Weinberger, Andrew Morton, linuxppc-dev, David Miller,
Al Viro
In-Reply-To: <CAHk-=wgYu67OwP4LhcrPdDVxv2mOsx-Xsc2DKoVW6GZwKFtOYQ@mail.gmail.com>
From: Linus Torvalds
> Sent: 14 February 2022 20:24
> >
> > x86-64 has always(*) used TASK_SIZE_MAX for access_ok(), and the
> > get_user() assembler implementation does the same.
>
> Side note: we could just check the sign bit instead, and avoid big
> constants that way.
The cheap test for most 64bit is (addr | size) >> 62 != 0.
I did some tests last week and the compilers correctly optimise
out constant size.
Doesn't sparc64 still need a wrap test?
Or is that assumed because there is always an unmapped page
and transfer are 'adequately' done on increasing addresses?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH 05/14] uaccess: add generic __{get,put}_kernel_nofault
From: Al Viro @ 2022-02-15 0:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: mark.rutland, dalias, linux-ia64, linux-sh, peterz, linux-mips,
linux-mm, guoren, sparclinux, linux-hexagon, linux-riscv, will,
Christoph Hellwig, linux-arch, linux-s390, bcain, deller, x86,
linux, linux-csky, ardb, mingo, geert, linux-snps-arc,
linux-xtensa, arnd, hca, linux-alpha, linux-um, linuxppc-dev,
linux-m68k, openrisc, green.hu, shorne, linux-arm-kernel, monstr,
tsbogend, linux-parisc, nickhu, jcmvbkbc, linux-api, linux-kernel,
dinguyen, ebiederm, richard, akpm, Linus Torvalds, davem
In-Reply-To: <20220214163452.1568807-6-arnd@kernel.org>
On Mon, Feb 14, 2022 at 05:34:43PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> All architectures that don't provide __{get,put}_kernel_nofault() yet
> can implement this on top of __{get,put}_user.
>
> Add a generic version that lets everything use the normal
> copy_{from,to}_kernel_nofault() code based on these, removing the last
> use of get_fs()/set_fs() from architecture-independent code.
I'd put the list of those architectures (AFAICS, that's alpha, ia64,
microblaze, nds32, nios2, openrisc, sh, sparc32, xtensa) into commit
message - it's not that hard to find out, but...
And AFAICS, you've missed nios2 - see
#define __put_user(x, ptr) put_user(x, ptr)
in there. nds32 oddities are dealt with earlier in the series, this
one is not...
^ permalink raw reply
* Re: [PATCH 09/14] m68k: drop custom __access_ok()
From: Al Viro @ 2022-02-15 0:37 UTC (permalink / raw)
To: Arnd Bergmann
Cc: mark.rutland, dalias, linux-ia64, linux-sh, peterz, linux-mips,
linux-mm, guoren, sparclinux, linux-hexagon, linux-riscv, will,
Christoph Hellwig, linux-arch, linux-s390, bcain, deller, x86,
linux, linux-csky, ardb, mingo, geert, linux-snps-arc,
linux-xtensa, arnd, hca, linux-alpha, linux-um, linuxppc-dev,
linux-m68k, openrisc, green.hu, shorne, linux-arm-kernel, monstr,
tsbogend, linux-parisc, nickhu, jcmvbkbc, linux-api, linux-kernel,
dinguyen, ebiederm, richard, akpm, Linus Torvalds, davem
In-Reply-To: <20220214163452.1568807-10-arnd@kernel.org>
On Mon, Feb 14, 2022 at 05:34:47PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> While most m68k platforms use separate address spaces for user
> and kernel space, at least coldfire does not, and the other
> ones have a TASK_SIZE that is less than the entire 4GB address
> range.
>
> Using the generic implementation of __access_ok() stops coldfire
> user space from trivially accessing kernel memory, and is probably
> the right thing elsewhere for consistency as well.
Perhaps simply wrap that sucker into #ifdef CONFIG_CPU_HAS_ADDRESS_SPACES
(and trim the comment down to "coldfire and 68000 will pick generic
variant")?
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/m68k/include/asm/uaccess.h | 13 -------------
> 1 file changed, 13 deletions(-)
>
> diff --git a/arch/m68k/include/asm/uaccess.h b/arch/m68k/include/asm/uaccess.h
> index d6bb5720365a..64914872a5c9 100644
> --- a/arch/m68k/include/asm/uaccess.h
> +++ b/arch/m68k/include/asm/uaccess.h
> @@ -10,19 +10,6 @@
> #include <linux/compiler.h>
> #include <linux/types.h>
> #include <asm/extable.h>
> -
> -/* We let the MMU do all checking */
> -static inline int __access_ok(const void __user *addr,
> - unsigned long size)
> -{
> - /*
> - * XXX: for !CONFIG_CPU_HAS_ADDRESS_SPACES this really needs to check
> - * for TASK_SIZE!
> - * Removing this helper is probably sufficient.
> - */
> - return 1;
> -}
> -#define __access_ok __access_ok
> #include <asm-generic/access_ok.h>
>
> /*
> --
> 2.29.2
>
^ permalink raw reply
* Re: [PATCH 11/14] sparc64: remove CONFIG_SET_FS support
From: Al Viro @ 2022-02-15 0:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: mark.rutland, dalias, linux-ia64, linux-sh, peterz, linux-mips,
linux-mm, guoren, sparclinux, linux-hexagon, linux-riscv, will,
Christoph Hellwig, linux-arch, linux-s390, bcain, deller, x86,
linux, linux-csky, ardb, mingo, geert, linux-snps-arc,
linux-xtensa, arnd, hca, linux-alpha, linux-um, linuxppc-dev,
linux-m68k, openrisc, green.hu, shorne, linux-arm-kernel, monstr,
tsbogend, linux-parisc, nickhu, jcmvbkbc, linux-api, linux-kernel,
dinguyen, ebiederm, richard, akpm, Linus Torvalds, davem
In-Reply-To: <20220214163452.1568807-12-arnd@kernel.org>
On Mon, Feb 14, 2022 at 05:34:49PM +0100, Arnd Bergmann wrote:
> -/*
> - * Sparc64 is segmented, though more like the M68K than the I386.
> - * We use the secondary ASI to address user memory, which references a
> - * completely different VM map, thus there is zero chance of the user
> - * doing something queer and tricking us into poking kernel memory.
Actually, this part of comment probably ought to stay - it is relevant
for understanding what's going on (e.g. why is access_ok() always true, etc.)
^ permalink raw reply
* Re: [PATCH] powerpc/module_64: use module_init_section instead of patching names
From: Wedson Almeida Filho @ 2022-02-15 1:49 UTC (permalink / raw)
To: Michael Ellerman; +Cc: paulus, linuxppc-dev, linux-kernel
In-Reply-To: <20220202055123.2144842-1-wedsonaf@google.com>
Hi Michael,
On Wed, 2 Feb 2022 at 05:53, Wedson Almeida Filho <wedsonaf@google.com> wrote:
>
> Without this patch, module init sections are disabled by patching their
> names in arch-specific code when they're loaded (which prevents code in
> layout_sections from finding init sections). This patch uses the new
> arch-specific module_init_section instead.
>
> This allows modules that have .init_array sections to have the
> initialisers properly called (on load, before init). Without this patch,
> the initialisers are not called because .init_array is renamed to
> _init_array, and thus isn't found by code in find_module_sections().
>
> Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com>
> ---
> arch/powerpc/kernel/module_64.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
> index 5d77d3f5fbb5..6a45e6ddbe58 100644
> --- a/arch/powerpc/kernel/module_64.c
> +++ b/arch/powerpc/kernel/module_64.c
> @@ -277,6 +277,12 @@ static Elf64_Sym *find_dot_toc(Elf64_Shdr *sechdrs,
> return NULL;
> }
>
> +bool module_init_section(const char *name)
> +{
> + /* We don't handle .init for the moment: always return false. */
> + return false;
> +}
> +
> int module_frob_arch_sections(Elf64_Ehdr *hdr,
> Elf64_Shdr *sechdrs,
> char *secstrings,
> @@ -286,7 +292,6 @@ int module_frob_arch_sections(Elf64_Ehdr *hdr,
>
> /* Find .toc and .stubs sections, symtab and strtab */
> for (i = 1; i < hdr->e_shnum; i++) {
> - char *p;
> if (strcmp(secstrings + sechdrs[i].sh_name, ".stubs") == 0)
> me->arch.stubs_section = i;
> else if (strcmp(secstrings + sechdrs[i].sh_name, ".toc") == 0) {
> @@ -298,10 +303,6 @@ int module_frob_arch_sections(Elf64_Ehdr *hdr,
> dedotify_versions((void *)hdr + sechdrs[i].sh_offset,
> sechdrs[i].sh_size);
>
> - /* We don't handle .init for the moment: rename to _init */
> - while ((p = strstr(secstrings + sechdrs[i].sh_name, ".init")))
> - p[0] = '_';
> -
> if (sechdrs[i].sh_type == SHT_SYMTAB)
> dedotify((void *)hdr + sechdrs[i].sh_offset,
> sechdrs[i].sh_size / sizeof(Elf64_Sym),
> --
> 2.35.0.rc2.247.g8bbb082509-goog
Would any additional clarification from my part be helpful here?
I got an email saying it was under review (and checks passed) but
nothing appears to have happened since.
Cheers,
-Wedson
^ permalink raw reply
* Re: [PATCH 04/14] x86: use more conventional access_ok() definition
From: Al Viro @ 2022-02-15 2:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: Mark Rutland, Rich Felker, linux-ia64, Linux-sh list,
Peter Zijlstra, open list:BROADCOM NVRAM DRIVER, Max Filippov,
Guo Ren, sparclinux, linux-riscv, Will Deacon, Ard Biesheuvel,
linux-arch, linux-s390, Brian Cain, open list:QUALCOMM HEXAGON...,
Helge Deller, the arch/x86 maintainers, Russell King - ARM Linux,
linux-csky, Christoph Hellwig, Christoph Hellwig, Ingo Molnar,
Geert Uytterhoeven, open list:SYNOPSYS ARC ARCHITECTURE,
open list:TENSILICA XTENSA PORT (xtensa), Arnd Bergmann,
Heiko Carstens, linux-um, Richard Weinberger, linux-m68k,
Openrisc, Greentime Hu, Stafford Horne, Linux ARM, Arnd Bergmann,
Michal Simek, Thomas Bogendoerfer, Nick Hu, Parisc List, Linux-MM,
Linux API, Linux Kernel Mailing List, Dinh Nguyen,
Eric W . Biederman, alpha, Andrew Morton, linuxppc-dev,
David Miller
In-Reply-To: <Ygq4wy9fikDYmuHU@zeniv-ca.linux.org.uk>
On Mon, Feb 14, 2022 at 08:17:07PM +0000, Al Viro wrote:
> On Mon, Feb 14, 2022 at 12:01:05PM -0800, Linus Torvalds wrote:
> > On Mon, Feb 14, 2022 at 11:46 AM Arnd Bergmann <arnd@kernel.org> wrote:
> > >
> > > As Al pointed out, they turned out to be necessary on sparc64, but the only
> > > definitions are on sparc64 and x86, so it's possible that they serve a similar
> > > purpose here, in which case changing the limit from TASK_SIZE to
> > > TASK_SIZE_MAX is probably wrong as well.
> >
> > x86-64 has always(*) used TASK_SIZE_MAX for access_ok(), and the
> > get_user() assembler implementation does the same.
> >
> > I think any __range_not_ok() users that use TASK_SIZE are entirely
> > historical, and should be just fixed.
>
> IIRC, that was mostly userland stack trace collection in perf.
> I'll try to dig in archives and see what shows up - it's been
> a while ago...
After some digging:
access_ok() needs only to make sure that MMU won't go anywhere near
the kernel page tables; address limit for 32bit threads is none of its
concern, so TASK_SIZE_MAX is right for it.
valid_user_frame() in arch/x86/events/core.c: used while walking
the userland call chain. The reason it's not access_ok() is only that
perf_callchain_user() might've been called from interrupt that came while
we'd been under KERNEL_DS.
That had been back in 2015 and it had been obsoleted since 2017, commit
88b0193d9418 (perf/callchain: Force USER_DS when invoking perf_callchain_user()).
We had been guaranteed USER_DS ever since.
IOW, it could've reverted to use of access_ok() at any point after that.
TASK_SIZE vs TASK_SIZE_MAX is pretty much an accident there - might've been
TASK_SIZE_MAX from the very beginning.
copy_stack_frame() in arch/x86/kernel/stacktrace.c: similar story,
except the commit that made sure callers will have USER_DS - cac9b9a4b083
(stacktrace: Force USER_DS for stack_trace_save_user()) in this case.
Also could've been using access_ok() just fine. Amusingly, access_ok()
used to be there, until it had been replaced with explicit check on
Jul 22 2019 - 4 days after that had been made useless by fix in the caller...
copy_from_user_nmi(). That one is a bit more interesting.
We have a call chain from perf_output_sample_ustack() (covered by
force_uaccess_begin() these days, not that it mattered for x86 now),
there's something odd in dumpstack.c:copy_code() (with explicit check
for TASK_SIZE_MAX in the caller) and there's a couple of callers in
Intel PMU code.
AFAICS, there's no reason whatsoever to use TASK_SIZE
in that one - the point is to prevent copyin from the kernel
memory, and in that respect TASK_SIZE_MAX isn't any worse.
The check in copy_code() probably should go.
So all of those guys should be simply switched to access_ok().
Might be worth making that a preliminary patch - it's independent
from everything else and there's no point folding it into any of the
patches in the series.
^ permalink raw reply
* Re: [PATCH 14/14] uaccess: drop set_fs leftovers
From: Al Viro @ 2022-02-15 3:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: mark.rutland, dalias, linux-ia64, linux-sh, peterz, linux-mips,
linux-mm, guoren, sparclinux, linux-hexagon, linux-riscv, will,
Christoph Hellwig, linux-arch, linux-s390, bcain, deller, x86,
linux, linux-csky, ardb, mingo, geert, linux-snps-arc,
linux-xtensa, arnd, hca, linux-alpha, linux-um, linuxppc-dev,
linux-m68k, openrisc, green.hu, shorne, linux-arm-kernel, monstr,
tsbogend, linux-parisc, nickhu, jcmvbkbc, linux-api, linux-kernel,
dinguyen, ebiederm, richard, akpm, Linus Torvalds, davem
In-Reply-To: <20220214163452.1568807-15-arnd@kernel.org>
On Mon, Feb 14, 2022 at 05:34:52PM +0100, Arnd Bergmann wrote:
> diff --git a/arch/parisc/include/asm/futex.h b/arch/parisc/include/asm/futex.h
> index b5835325d44b..2f4a1b1ef387 100644
> --- a/arch/parisc/include/asm/futex.h
> +++ b/arch/parisc/include/asm/futex.h
> @@ -99,7 +99,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
> /* futex.c wants to do a cmpxchg_inatomic on kernel NULL, which is
> * our gateway page, and causes no end of trouble...
> */
> - if (uaccess_kernel() && !uaddr)
> + if (!uaddr)
> return -EFAULT;
Huh? uaccess_kernel() is removed since it becomes always false now,
so this looks odd.
AFAICS, the comment above that check refers to futex_detect_cmpxchg()
-> cmpxchg_futex_value_locked() -> futex_atomic_cmpxchg_inatomic() call chain.
Which had been gone since commit 3297481d688a (futex: Remove futex_cmpxchg
detection). The comment *and* the check should've been killed off back
then.
Let's make sure to get both now...
^ permalink raw reply
* Re: [PATCH V2] powerpc/perf: Fix task context setting for trace imc
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: mpe, Athira Rajeev; +Cc: kjain, maddy, linuxppc-dev, npiggin, rnsastry
In-Reply-To: <20220202041837.65968-1-atrajeev@linux.vnet.ibm.com>
On Wed, 2 Feb 2022 09:48:37 +0530, Athira Rajeev wrote:
> Trace IMC (In-Memory collection counters) in powerpc is
> useful for application level profiling. For trace_imc,
> presently task context (task_ctx_nr) is set to
> perf_hw_context. But perf_hw_context is to be used for
> cpu PMU. So for trace_imc, even though it is per thread
> PMU, it is preferred to use sw_context inorder to be able
> to do application level monitoring. Hence change the
> task_ctx_nr to use perf_sw_context.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/perf: Fix task context setting for trace imc
https://git.kernel.org/powerpc/c/0198322379c25215b2778482bf1221743a76e2b5
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: dts: t104xrdb: fix phy type for FMAN 4/5
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Maxim Kiselev
Cc: devicetree, linux-kernel, fido_max, Rob Herring, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20211230151123.1258321-1-bigunclemax@gmail.com>
On Thu, 30 Dec 2021 18:11:21 +0300, Maxim Kiselev wrote:
> T1040RDB has two RTL8211E-VB phys which requires setting
> of internal delays for correct work.
>
> Changing the phy-connection-type property to `rgmii-id`
> will fix this issue.
>
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: dts: t104xrdb: fix phy type for FMAN 4/5
https://git.kernel.org/powerpc/c/17846485dff91acce1ad47b508b633dffc32e838
cheers
^ permalink raw reply
* Re: [PATCH v3] powerpc: dts: t1040rdb: fix ports names for Seville Ethernet switch
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: mpe, Maxim Kiselev
Cc: devicetree, andrew, vladimir.oltean, linux-kernel, fido_max,
robh+dt, paulus, linuxppc-dev, davem
In-Reply-To: <20220121091447.3412907-1-bigunclemax@gmail.com>
On Fri, 21 Jan 2022 12:14:47 +0300, Maxim Kiselev wrote:
> On board rev A, the network interface labels for the switch ports
> written on the front panel are different than on rev B and later.
>
> This patch fixes network interface names for the switch ports according
> to labels that are written on the front panel of the board rev B.
> They start from ETH3 and end at ETH10.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: dts: t1040rdb: fix ports names for Seville Ethernet switch
https://git.kernel.org/powerpc/c/5ebb74749202a25da4b3cc2eb15470225a05527c
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/kasan: Fix early region not updated correctly
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Chen Jingwen, kasan-dev, linuxppc-dev,
Michael Ellerman, Paul Mackerras, linux-kernel, Christophe Leroy
In-Reply-To: <20211229035226.59159-1-chenjingwen6@huawei.com>
On Wed, 29 Dec 2021 11:52:26 +0800, Chen Jingwen wrote:
> The shadow's page table is not updated when PTE_RPN_SHIFT is 24
> and PAGE_SHIFT is 12. It not only causes false positives but
> also false negative as shown the following text.
>
> Fix it by bringing the logic of kasan_early_shadow_page_entry here.
>
> 1. False Positive:
> ==================================================================
> BUG: KASAN: vmalloc-out-of-bounds in pcpu_alloc+0x508/0xa50
> Write of size 16 at addr f57f3be0 by task swapper/0/1
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/kasan: Fix early region not updated correctly
https://git.kernel.org/powerpc/c/dd75080aa8409ce10d50fb58981c6b59bf8707d3
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/32s: Make pte_update() non atomic on 603 core
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Christophe Leroy,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cc89d3c11fc9c742d0df3454a657a3a00be24046.1643538554.git.christophe.leroy@csgroup.eu>
On Sun, 30 Jan 2022 10:29:34 +0000, Christophe Leroy wrote:
> On 603 core, TLB miss handler don't do any change to the
> page tables so pte_update() doesn't need to be atomic.
>
>
Applied to powerpc/next.
[1/1] powerpc/32s: Make pte_update() non atomic on 603 core
https://git.kernel.org/powerpc/c/4291d085b0b07a78403e845c187428b038c901cd
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/603: Clear C bit when PTE is read only
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Christophe Leroy,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <bbb13848ff0100a76ee9ea95118058c30ae95f2c.1643613343.git.christophe.leroy@csgroup.eu>
On Mon, 31 Jan 2022 07:17:57 +0000, Christophe Leroy wrote:
> On book3s/32 MMU, PP bits don't offer kernel RO protection,
> kernel pages are always RW.
>
> However, on the 603 a page fault is always generated when the
> C bit (change bit = dirty bit) is not set.
>
> Enforce kernel RO protection by clearing C bit in TLB miss
> handler when the page doesn't have _PAGE_RW flag.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/603: Clear C bit when PTE is read only
https://git.kernel.org/powerpc/c/4634bf4455fe26f07dabf97c3585c9ccb86353c4
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/603: Remove outdated comment
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Christophe Leroy,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <38b1ffefd2146fa56bf8aa605d476ad9736bbb37.1643613296.git.christophe.leroy@csgroup.eu>
On Mon, 31 Jan 2022 07:15:12 +0000, Christophe Leroy wrote:
> Since commit 84de6ab0e904 ("powerpc/603: don't handle PAGE_ACCESSED
> in TLB miss handlers.") page table is not updated anymore by
> TLB miss handlers.
>
> Remove the comment.
>
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/603: Remove outdated comment
https://git.kernel.org/powerpc/c/9872cbfb4558bf68219c5a8a65fd5c29b593323d
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/xive: Add some error handling code to 'xive_spapr_init()'
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Christophe JAILLET, paulus, mpe, groug, benh, tglx,
christophe.leroy, clg, allison
Cc: linuxppc-dev, kernel-janitors, linux-kernel
In-Reply-To: <564998101804886b151235c8a9f93020923bfd2c.1643718324.git.christophe.jaillet@wanadoo.fr>
On Tue, 1 Feb 2022 13:31:16 +0100, Christophe JAILLET wrote:
> 'xive_irq_bitmap_add()' can return -ENOMEM.
> In this case, we should free the memory already allocated and return
> 'false' to the caller.
>
> Also add an error path which undoes the 'tima = ioremap(...)'
>
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/xive: Add some error handling code to 'xive_spapr_init()'
https://git.kernel.org/powerpc/c/e414e2938ee26e734f19e92a60cd090ebaff37e6
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/nohash: Remove pte_same()
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Christophe Leroy,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <83c97bd58a3596ef1b0ff28b1e41fd492d005520.1643616989.git.christophe.leroy@csgroup.eu>
On Mon, 31 Jan 2022 08:16:48 +0000, Christophe Leroy wrote:
> arch/powerpc/include/asm/nohash/{32/64}/pgtable.h has
>
> #define __HAVE_ARCH_PTE_SAME
> #define pte_same(A,B) ((pte_val(A) ^ pte_val(B)) == 0)
>
> include/linux/pgtable.h has
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/nohash: Remove pte_same()
https://git.kernel.org/powerpc/c/535bda36dbf2d271f59e06fe252c32eff452666d
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/ptdump: Fix sparse warning in hashpagetable.c
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Christophe Leroy,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel, kernel test robot
In-Reply-To: <bbc196451dd34521d239023ccca488db35b8fff1.1643567900.git.christophe.leroy@csgroup.eu>
On Sun, 30 Jan 2022 18:39:18 +0000, Christophe Leroy wrote:
> arch/powerpc/mm/ptdump/hashpagetable.c:264:29: warning: restricted __be64 degrades to integer
> arch/powerpc/mm/ptdump/hashpagetable.c:265:49: warning: restricted __be64 degrades to integer
> arch/powerpc/mm/ptdump/hashpagetable.c:267:36: warning: incorrect type in assignment (different base types)
> arch/powerpc/mm/ptdump/hashpagetable.c:267:36: expected unsigned long long [usertype]
> arch/powerpc/mm/ptdump/hashpagetable.c:267:36: got restricted __be64 [usertype] v
> arch/powerpc/mm/ptdump/hashpagetable.c:268:36: warning: incorrect type in assignment (different base types)
> arch/powerpc/mm/ptdump/hashpagetable.c:268:36: expected unsigned long long [usertype]
> arch/powerpc/mm/ptdump/hashpagetable.c:268:36: got restricted __be64 [usertype] r
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/ptdump: Fix sparse warning in hashpagetable.c
https://git.kernel.org/powerpc/c/961f649fb3ad9a9e384c695a050d776d970ddabd
cheers
^ permalink raw reply
* Re: [PATCH] macintosh: macio_asic: remove useless cast for driver.name
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Corentin Labbe, benh; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20220125135421.4081740-1-clabbe@baylibre.com>
On Tue, 25 Jan 2022 13:54:21 +0000, Corentin Labbe wrote:
> pci_driver name is const char pointer, so the cast it not necessary.
>
>
Applied to powerpc/next.
[1/1] macintosh: macio_asic: remove useless cast for driver.name
https://git.kernel.org/powerpc/c/ccafe7c20b7de330d9091a114c9985305759f1ee
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Fix debug print in smp_setup_cpu_maps
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Fabiano Rosas, linuxppc-dev
In-Reply-To: <20210120181847.952106-1-farosas@linux.ibm.com>
On Wed, 20 Jan 2021 15:18:47 -0300, Fabiano Rosas wrote:
> When figuring out the number of threads, the debug message prints "1
> thread" for the first iteration of the loop, instead of the actual
> number of threads calculated from the length of the
> "ibm,ppc-interrupt-server#s" property.
>
> * /cpus/PowerPC,POWER8@20...
> ibm,ppc-interrupt-server#s -> 1 threads <--- WRONG
> thread 0 -> cpu 0 (hard id 32)
> thread 1 -> cpu 1 (hard id 33)
> thread 2 -> cpu 2 (hard id 34)
> thread 3 -> cpu 3 (hard id 35)
> thread 4 -> cpu 4 (hard id 36)
> thread 5 -> cpu 5 (hard id 37)
> thread 6 -> cpu 6 (hard id 38)
> thread 7 -> cpu 7 (hard id 39)
> * /cpus/PowerPC,POWER8@28...
> ibm,ppc-interrupt-server#s -> 8 threads
> thread 0 -> cpu 8 (hard id 40)
> thread 1 -> cpu 9 (hard id 41)
> thread 2 -> cpu 10 (hard id 42)
> thread 3 -> cpu 11 (hard id 43)
> thread 4 -> cpu 12 (hard id 44)
> thread 5 -> cpu 13 (hard id 45)
> thread 6 -> cpu 14 (hard id 46)
> thread 7 -> cpu 15 (hard id 47)
> (...)
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Fix debug print in smp_setup_cpu_maps
https://git.kernel.org/powerpc/c/b53c86105919d4136591e3bee198a4829c0f5062
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/spufs: adjust list element pointer type
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Jeremy Kerr, Julia Lawall
Cc: Nic Volanschi, Arnd Bergmann, kernel-janitors, linux-kernel,
Paul Mackerras, linuxppc-dev
In-Reply-To: <1588929176-28527-1-git-send-email-Julia.Lawall@inria.fr>
On Fri, 08 May 2020 09:12:56 +0000, Julia Lawall wrote:
> Other uses of &gang->aff_list_head, eg in spufs_assert_affinity, indicate
> that the list elements have type spu_context, not spu as used here. Change
> the type of tmp accordingly.
>
> This has no impact on the execution, because tmp is not used in the body of
> the loop.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/spufs: adjust list element pointer type
https://git.kernel.org/powerpc/c/925f76c55784fdc17ab41aecde06b30439ceb73a
cheers
^ permalink raw reply
* Re: [PATCH v5] powerpc/pseries: read the lpar name from the firmware
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Laurent Dufour, linux-kernel, linuxppc-dev; +Cc: Nathan Lynch, tyreld
In-Reply-To: <20220106161339.74656-1-ldufour@linux.ibm.com>
On Thu, 6 Jan 2022 17:13:39 +0100, Laurent Dufour wrote:
> The LPAR name may be changed after the LPAR has been started in the HMC.
> In that case lparstat command is not reporting the updated value because it
> reads it from the device tree which is read at boot time.
>
> However this value could be read from RTAS.
>
> Adding this value in the /proc/powerpc/lparcfg output allows to read the
> updated value.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/pseries: read the lpar name from the firmware
https://git.kernel.org/powerpc/c/eddaa9a402758d379520f6511fb61e89990698aa
cheers
^ permalink raw reply
* Re: [PATCH] rpadlpar_io:Add MODULE_DESCRIPTION entries to kernel modules
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Mamatha Inamdar, linux-kernel; +Cc: bhelgaas, linuxppc-dev, linux-pci, tyreld
In-Reply-To: <20200924051343.16052.9571.stgit@localhost.localdomain>
On Thu, 24 Sep 2020 10:44:16 +0530, Mamatha Inamdar wrote:
> This patch adds a brief MODULE_DESCRIPTION to rpadlpar_io kernel modules
> (descriptions taken from Kconfig file)
>
>
Applied to powerpc/next.
[1/1] rpadlpar_io:Add MODULE_DESCRIPTION entries to kernel modules
https://git.kernel.org/powerpc/c/be7be1c6c6f8bd348f0d83abe7a8f0e21bdaeac8
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: add link stack flush mitigation status in debugfs.
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Michal Suchanek, linuxppc-dev
Cc: Geert Uytterhoeven, Anthony Steinhauser, Gustavo L. F. Walbon,
Christopher M. Riedl, YueHaibing, linux-kernel, Diana Craciun,
Josh Poimboeuf, Paul Mackerras
In-Reply-To: <20191127220959.6208-1-msuchanek@suse.de>
On Wed, 27 Nov 2019 23:09:59 +0100, Michal Suchanek wrote:
> The link stack flush status is not visible in debugfs. It can be enabled
> even when count cache flush is disabled. Add separate file for its
> status.
>
>
Applied to powerpc/next.
[1/1] powerpc: add link stack flush mitigation status in debugfs.
https://git.kernel.org/powerpc/c/b2a6f6043577e09d51a4b5577fff9fc9f5b14b1c
cheers
^ permalink raw reply
* Re: [PATCH]powerpc/xive: Export XIVE IPI information for online-only processors.
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Sachin Sant, linuxppc-dev; +Cc: clg
In-Reply-To: <164146703333.19039.10920919226094771665.sendpatchset@MacBook-Pro.local>
On Thu, 06 Jan 2022 16:33:53 +0530, Sachin Sant wrote:
> Cédric pointed out that XIVE IPI information exported via sysfs
> (debug/powerpc/xive) display empty lines for processors which are
> not online.
>
> Switch to using for_each_online_cpu() so that information is
> displayed for online-only processors.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/xive: Export XIVE IPI information for online-only processors.
https://git.kernel.org/powerpc/c/279d1a72c0f8021520f68ddb0a1346ff9ba1ea8c
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: dts: Fix some I2C unit addresses
From: Michael Ellerman @ 2022-02-15 5:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Thierry Reding,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20211220134036.683309-1-thierry.reding@gmail.com>
On Mon, 20 Dec 2021 14:40:36 +0100, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> The unit-address for the Maxim MAX1237 ADCs on XPedite5200 boards don't
> match the value in the "reg" property and cause a DTC warning.
>
>
Applied to powerpc/next.
[1/1] powerpc: dts: Fix some I2C unit addresses
https://git.kernel.org/powerpc/c/d5342fdd163ae0553a14820021a107e03eb1ea72
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox