Michael Ellerman writes:
>
> Rob's point is that commit fee3ff99bc67 only moved existing code, the
> bug already existed.
>
> The function was introduced in:
>
> 467d27824920 ("powerpc: ima: get the kexec buffer passed by the previous
> kernel")
>
> So that's where the Fixes tag should
Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
ima-kexec-buffer lies outside the addressable memory range. This can result
in a kernel panic if the new kernel is booted with 'mem=X' arg and the
ima-kexec-buffer was allocated beyond that range by the previous kernel.
The
When CONFIG_PPC_64S_HASH_MMU is not set, slice.c is not built and
arch_get_unmapped_area() and arch_get_unmapped_area_topdown() are
not provided because RADIX uses the generic ones.
Therefore, neither set HAVE_ARCH_UNMAPPED_AREA nor
HAVE_ARCH_UNMAPPED_AREA_TOPDOWN.
Reported-by: Laurent Dufour
Include of_adresses.h to get of_iomap() prototype.
Fixes: 86c38fec69a4 ("powerpc: Remove asm/prom.h from all files that don't need
it")
Signed-off-by: Christophe Leroy
---
arch/powerpc/sysdev/xics/ics-native.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Michael Ellerman writes:
> Brian W Hart writes:
>> On Thu, May 19, 2022 at 12:26:29AM +1000, Michael Ellerman wrote:
>>> Rather than waiting for the bots to fix these one-by-one, fix all
>>> occurences of "the the" throughout arch/powerpc.
> ...
>>> diff --git
"Naveen N. Rao" writes:
> Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next bboot of the powerpc pseries_le_defconfig build
>> produced these different kernel messages (diff from yesterday's tree):
>>
>> - ftrace: allocating 33658 entries in 13 pages
>> - ftrace: allocated 13 pages
https://bugzilla.kernel.org/show_bug.cgi?id=215803
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|RESOLVED|CLOSED
---
On 19/05/2022 16:20, Scott Branden wrote:
> [...]
>> Hi Scott / Desmond, thanks for the detailed answer! Is this adapter
>> designed to run in x86 only or you have other architectures' use cases?
> The adapter may be used in any PCIe design that supports DMA.
> So it may be possible to run in
> > I also tested linux-next, it's okay:
> >
> > rv64_rootfs:
> > # uname -a
> > Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT
> > 2022 riscv64 GNU/Linux
> > #
>
> That is is ok with one setup doesn't mean it is ok with
> al
palmer/for-next) riscv: Don't output a
> > > bogus mmu-type on a no MMU kernel
> > >
> > > I also tested linux-next, it's okay:
> > >
> > > rv64_rootfs:
> > > # uname -a
> > > Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 1
On 28/04/2022 13:55, Helge Deller wrote:
> [...]
> You may add:
> Acked-by: Helge Deller # parisc
>
> Helge
Hi Helge, do you think would be possible to still pick this one for
v5.19 or do you prefer to hold for the next release?
I'm working on V2, so if it's merged for 5.19 I won't send it
On Sat, 21 May 2022 10:44:30 -0700 Jakub Kicinski wrote:
> > Well, I say the contrary.
> >
> > On the mainline the patch may be applied as is, it won't harm.
> >
> > However, it is gets applied to kernel 4.9 (based on the fixes: tag), it
> > will break the driver for at least powerpc 8xx.
>
On Sat, May 21, 2022 at 11:07:52PM -0700, Christoph Hellwig wrote:
> On Fri, May 20, 2022 at 02:06:56PM +0530, Maninder Singh wrote:
> > kallsyms functionality depends on KSYM_NAME_LEN directly.
> > but if user passed array length lesser than it, sprintf
> > can cause issues of buffer overflow
This patch enables objtool --mcount on powerpc, and
adds implementation specific to powerpc.
Signed-off-by: Sathvika Vasireddy
---
arch/powerpc/Kconfig| 1 +
tools/objtool/arch/powerpc/decode.c | 14 ++
tools/objtool/check.c | 12 +++-
This patch adds [stub] implementations for required
functions, inorder to enable objtool build on powerpc.
Signed-off-by: Sathvika Vasireddy
---
arch/powerpc/Kconfig | 1 +
tools/objtool/arch/powerpc/Build | 2 +
tools/objtool/arch/powerpc/decode.c
These patches are rebased on top of objtool/core
branch of the tip tree, and work only on ppc64le
for now.
Note: With this patch set, there are still some
warnings seen with ppc64le kernel build.
Sathvika Vasireddy (4):
objtool: Add --mnop as an option to --mcount
objtool: Enable objtool
Architectures can select HAVE_NOP_MCOUNT if they choose
to nop out mcount call sites. If that config option is
selected, then --mnop is passed as an option to objtool,
along with --mcount.
Also, make sure that --mnop can be passed as an option
to objtool only when --mcount is passed.
This patch makes sure objtool runs only on the object files
that have ftrace enabled, instead of running on all the object
files.
Signed-off-by: Naveen N. Rao
Signed-off-by: Sathvika Vasireddy
---
scripts/Makefile.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Athira Rajeev
[ Upstream commit 8994e97be3eb3c3a7b59d6223018ffab8c272e2d ]
Perf BPF filter test fails in environment where "clang" is not
installed.
Test failure logs:
<<>>
42: BPF filter:
42.1: Basic BPF filtering : Skip
42.2: BPF pinning
From: Athira Rajeev
[ Upstream commit 451ed8058c69a3fee29fa9e2967a4e22a221fe75 ]
"perf all PMU test" picks the input events from "perf list --raw-dump
pmu" list and runs "perf stat -e" for each of the event in the list. In
case of powerpc, the PowerVM environment supports events from hv_24x7
On 23/05/2022, 17:18:10, Christophe Leroy wrote:
>
>
> Le 23/05/2022 à 14:27, Laurent Dufour a écrit :
>> On 09/04/2022, 19:17:34, Christophe Leroy wrote:
>>> hugetlb_get_unmapped_area() is now identical to the
>>> generic version if only RADIX is enabled, so move it
>>> to slice.c and let it
There is no need to read the H_BLOCK_REMOVE characteristics when running in
Radix mode because this hcall is never called.
Furthermore since the commit 387e220a2e5e ("powerpc/64s: Move hash MMU
support code under CONFIG_PPC_64S_HASH_MMU") define
pseries_lpar_read_hblkrm_characteristics as un
On 5/23/22 08:18, Guo Ren wrote:
I tested Palmer's branch, it's okay:
8810d7feee5a (HEAD -> for-next, palmer/for-next) riscv: Don't output a
bogus mmu-type on a no MMU kernel
I also tested linux-next, it's okay:
rv64_rootfs:
# uname -a
Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23
On 20/05/2022, 18:15:39, Christophe Leroy wrote:
>
>
> Le 20/05/2022 à 17:57, Laurent Dufour a écrit :
>> There is no need to read the H_BLOCK_REMOVE characteristics when running in
>> Radix mode because this hcall is never called.
>>
>> Signed-off-by: Laurent Dufour
>> ---
>>
I tested Palmer's branch, it's okay:
8810d7feee5a (HEAD -> for-next, palmer/for-next) riscv: Don't output a
bogus mmu-type on a no MMU kernel
I also tested linux-next, it's okay:
rv64_rootfs:
# uname -a
Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT
2022 riscv64 GNU/Li
Le 23/05/2022 à 14:27, Laurent Dufour a écrit :
> On 09/04/2022, 19:17:34, Christophe Leroy wrote:
>> hugetlb_get_unmapped_area() is now identical to the
>> generic version if only RADIX is enabled, so move it
>> to slice.c and let it fallback on the generic one
>> when HASH MMU is not compiled
On 5/20/22 7:11 PM, Nicholas Piggin wrote:
Excerpts from Paul E Murphy's message of May 21, 2022 12:21 am:
On 5/20/22 12:15 AM, Nicholas Piggin via Gcc wrote:
+PPC_FEATURE2_TAR
+VSX facility is available.
Was manipulating the tar spr was once a privileged instruction, is this
a hint
If early cpu to node mapping finds an invalid node id, return
the first online node instead of node 0. On ppc, we can find node 0
not present.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/topology.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
numa_setup_cpu can return nodes that are not online. But setup_node_data()
only initialize NODE_DATA for only online numa nodes. Hence avoid returning
nodes that are not online.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hello:
This patch was applied to netdev/net-next.git (master)
by David S. Miller :
On Wed, 18 May 2022 20:13:45 -0700 you wrote:
> Looks like almost all changes to this driver had been tree-wide
> refactoring since git era begun. There is one commit from Al
> 15 years ago which could potentially
On Fri, 20 May 2022 at 00:06, Nicholas Piggin wrote:
>
> Excerpts from Joel Stanley's message of May 19, 2022 10:57 pm:
> > In commit 5402e239d09f ("powerpc/64s: Get LPID bit width from device
> > tree") the kernel tried to determine the pid and lpid bits from the
> > device tree. If they are not
On Fri, 2022-05-20 at 10:06 +1000, Nicholas Piggin wrote:
> Excerpts from Joel Stanley's message of May 19, 2022 10:57 pm:
> > In commit 5402e239d09f ("powerpc/64s: Get LPID bit width from device
> > tree") the kernel tried to determine the pid and lpid bits from the
> > device tree. If they are
While booting linux-next (5.18.0-rc7-next-20220520) on a Power10 LPAR
configure with pmem following oops is seen. The LPAR fails to boot to
login prompt.
[ 10.948211] papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Permission
denied while accessing performance stats
[ 10.948536] Kernel
Le 29/03/2022 à 13:22, Petr Mladek a écrit :
> On Mon 2022-03-28 08:26:48, Christophe Leroy wrote:
>> All three versions of klp_arch_set_pc() do exactly the same: they
>> call ftrace_instruction_pointer_set().
>>
>> Call ftrace_instruction_pointer_set() directly and remove
>> klp_arch_set_pc().
34 matches
Mail list logo
