tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: bc63de6e6ba0b16652c5fb4b9c9916b9e7ca1f23 Add linux-next specific
files for 20231208
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202312081716.luuhsns4-...@intel.com
https
Hi Christophe,
On Wed, Dec 06, 2023 at 11:24:03PM +0100, Christophe Leroy wrote:
> sparse reports an error on some data that gets converted from be32.
>
> That's because that data is typed u32 instead of __be32.
>
> The type is correct, the be32_to_cpu() conversion is not.
>
> Remove the conver
[+cc Jonathan]
On Wed, Dec 06, 2023 at 04:42:28PM -0600, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Clean up some minor AER logging issues:
>
> - Log as "Correctable errors", not "Corrected errors"
>
> - Decode the Requester ID when we couldn't find detail error info
>
> Bjorn Helgaas
Replace seven spaces with a tab character to fix an indentation issue
reported by the kernel test robot.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202311221731.aluwtdim-...@intel.com/
Signed-off-by: Naveen N Rao
---
arch/powerpc/include/asm/ftrace.h | 2 +-
1
Add powerpc 32-bit and 64-bit samples for ftrace direct. This serves to
show the sample instruction sequence to be used by ftrace direct calls
to adhere to the ftrace ABI.
On 64-bit powerpc, TOC setup requires some additional work.
Signed-off-by: Naveen N Rao
---
arch/powerpc/Kconfig
Add support for DYNAMIC_FTRACE_WITH_DIRECT_CALLS similar to the arm64
implementation.
ftrace direct calls allow custom trampolines to be called into directly
from function ftrace call sites, bypassing the ftrace trampoline
completely. This functionality is currently utilized by BPF trampolines
to
Implement support for DYNAMIC_FTRACE_WITH_CALL_OPS similar to the
arm64 implementation.
This works by patching-in a pointer to an associated ftrace_ops
structure before each traceable function. If multiple ftrace_ops are
associated with a call site, then a special ftrace_list_ops is used to
enable
Function profile sequence on powerpc includes two instructions at the
beginning of each function:
mflrr0
bl ftrace_caller
The call to ftrace_caller() gets nop'ed out during kernel boot and is
patched in when ftrace is enabled.
There are two issues with this:
1. The 'mflr
Rather than hard-coding the offset into a function to be used to
determine if a kprobe is at function entry, use ftrace_location() to
determine the ftrace location within the function and categorize all
instructions till that offset to be function entry.
For functions that cannot be traced, we fal
From: Sathvika Vasireddy
Commit d49a0626216b95 ("arch: Introduce CONFIG_FUNCTION_ALIGNMENT")
introduced a generic function-alignment infrastructure. Move to using
FUNCTION_ALIGNMENT_4B on powerpc, to use the same alignment as that of
the existing _GLOBAL macro.
Signed-off-by: Sathvika Vasireddy
ftrace_stub is within the same CU, so there is no need for a subsequent
nop instruction.
Signed-off-by: Naveen N Rao
---
arch/powerpc/kernel/trace/ftrace_entry.S | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/kernel/trace/ftrace_entry.S
b/arch/powerpc/kernel/trace/ftrace_entr
On 32-bit powerpc, gcc generates a three instruction sequence for
function profiling:
mflrr0
stw r0, 4(r1)
bl _mcount
On kernel boot, the call to _mcount() is nop-ed out, to be patched back
in when ftrace is actually enabled. The 'stw' instruction therefore is
Early RFC.
This series attempts to address couple of issues with the existing
support for ftrace on powerpc, with a view towards improving performance
when ftrace is not enabled. See patch 6 for more details.
Patches 7 and 8 implement support for ftrace direct calls, through
adding support for
On Wed, 6 Dec 2023 16:42:29 -0600
Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> The PCIe spec classifies errors as either "Correctable" or "Uncorrectable".
> Previously we printed these as "Corrected" or "Uncorrected". To avoid
> confusion, use the same terms as the spec.
>
> One confusing
On Thu, Dec 7, 2023 at 5:37 PM Christophe Leroy
wrote:
>
> The subject says "riscv:" but it changes core part and several arch.
> Maybe this commit should be split in two commits, one for API changes
> that changes flush_tlb_fix_spurious_fault() to
> flush_tlb_fix_spurious_write_fault() and adds
>
On Wed, 6 Dec 2023 16:42:31 -0600
Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> aer_irq() reads the AER Root Error Status and Error Source Identification
> (PCI_ERR_ROOT_STATUS and PCI_ERR_ROOT_ERR_SRC) registers directly into
> struct aer_err_source. Both registers are 32 bits, so declare t
On Wed, 6 Dec 2023 16:42:30 -0600
Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> When a device with AER detects an error, it logs error information in its
> own AER Error Status registers. It may send an Error Message to the Root
> Port (RCEC in the case of an RCiEP), which logs the fact that
On Thu, Dec 7, 2023 at 4:55 PM Christophe Leroy
wrote:
>
>
>
> Le 07/12/2023 à 16:03, Alexandre Ghiti a écrit :
> > This mechanism allows to completely bypass the sfence.vma introduced by
> > the previous commit for uarchs that do not cache invalid TLB entries.
> >
> > Signed-off-by: Alexandre Ghi
Hi Christophe,
On Thu, Dec 7, 2023 at 4:52 PM Christophe Leroy
wrote:
>
>
>
> Le 07/12/2023 à 16:03, Alexandre Ghiti a écrit :
> > In 6.5, we removed the vmalloc fault path because that can't work (see
> > [1] [2]). Then in order to make sure that new page table entries were
> > seen by the page
Hi Aneesh,
Thanks for looking into this patch. My responses inline below:
"Aneesh Kumar K.V (IBM)" writes:
> Vaibhav Jain writes:
>
>> From: Jordan Niethe
>>
>> An L0 must invalidate the L2's RPT during H_GUEST_DELETE if this has not
>> already been done. This is a slow operation that means
The patch titled ("powerpc: make fadump resilient with memory add/remove
events") has made significant changes to the implementation of fadump,
particularly on elfcorehdr creation and fadump crash info header
structure. Therefore, updating the fadump implementation documentation
to reflect those ch
The elfcorehdr describes the CPUs and memory of the crashed kernel to
the kernel that captures the dump, known as the second or fadump kernel.
The elfcorehdr needs to be updated if the system's memory changes due to
memory hotplug or online/offline events.
Currently, memory hotplug events are moni
Due to changes in memory resources caused by either memory hotplug or
online/offline events, the elfcorehdr, which describes the CPUs and
memory of the crashed kernel to the kernel that collects the dump (known
as second/fadump kernel), becomes outdated. Consequently, attempting
dump collection wit
Problem:
Due to changes in memory resources caused by either memory hotplug or
online/offline events, the elfcorehdr, which describes the cpus and
memory of the crashed kernel to the kernel that collects the dump (known
as second/fadump kernel), becomes outdated. Consequently, attempting
d
Acked-By: Jochen Friedrich
Am 06.12.2023 um 23:24 schrieb Christophe Leroy:
sparse reports an error on some data that gets converted from be32.
That's because that data is typed u32 instead of __be32.
The type is correct, the be32_to_cpu() conversion is not.
Remove the conversion.
Reported-
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.
Add a null pointer check, and release 'ent' to avoid memory leaks.
Fixes: bfd2f0d49aef ("powerpc/powernv: Get rid of old scom_controller
abstraction")
Cc: Kunwu Chan
Signed-off-by: Kunwu Chan
---
arch
Vaibhav Jain writes:
> From: Jordan Niethe
>
> H_COPY_TOFROM_GUEST is part of the nestedv1 API and so should not be
> called by a nestedv2 host. Do not attempt to call it.
>
May be we should use
firmware_has_feature(FW_FEATURE_H_COPY_TOFROM_GUEST))?
the nestedv2 can end up using the above hcal
27 matches
Mail list logo
