For systems having CONFIG_NR_CPUS set to > 1024 in kernel config
the selftest fails even though the current number of online cpus
is less. For example, on powerpc the default value for
CONFIG_NR_CPUS is set to 8192.
get_nprocs() is used to get the number of available cpus in test
driver code and t
The existing code for emitting bpf atomic instruction sequences for
atomic operations such as XCHG, CMPXCHG, ADD, AND, OR, and XOR has been
refactored into a reusable function, bpf_jit_emit_ppc_atomic_op().
It also computes the jump offset and tracks the instruction index for jited
LDARX/LWARX to b
powerpc supports BPF atomic operations using a loop around
Load-And-Reserve(LDARX/LWARX) and Store-Conditional(STDCX/STWCX)
instructions gated by sync instructions to enforce full ordering.
To implement arena_atomics, arena vm start address is added to the
dst_reg to be used for both the LDARX/LWA
bpf_jit_emit_probe_mem_store() is introduced to emit instructions for
storing memory values depending on the size (byte, halfword,
word, doubleword).
Signed-off-by: Saket Kumar Bhaskar
---
arch/powerpc/net/bpf_jit_comp64.c | 30 ++
1 file changed, 30 insertions(+)
di
LLVM generates bpf_addr_space_cast instruction while translating
pointers between native (zero) address space and
__attribute__((address_space(N))). The addr_space=0 is reserved as
bpf_arena address space.
rY = addr_space_cast(rX, 0, 1) is processed by the verifier and
converted to normal 32-bit m
Add support for [LDX | STX | ST], PROBE_MEM32, [B | H | W | DW]
instructions. They are similar to PROBE_MEM instructions with the
following differences:
- PROBE_MEM32 supports store.
- PROBE_MEM32 relies on the verifier to clear upper 32-bit of the
src/dst register
- PROBE_MEM32 adds 64-bit kern_v
Hi,
Could you please apply commit 5a821e2d69e2 ("powerpc/boot: Fix build
with gcc 15") to stable kernels, just like you did with commit
ee2ab467bddf ("x86/boot: Use '-std=gnu11' to fix build with GCC 15")
Ref: https://bugzilla.kernel.org/show_bug.cgi?id=220407
Thanks
Christophe
* Shrikanth Hegde [2025-08-01 19:27:22]:
>
> On 7/16/25 16:15, Srikar Dronamraju wrote:
> > Systems can now be partitioned into resource groups. By default all
> > systems will be part of default resource group. Once a resource group is
> > created, and resources allocated to the resource group,
On Tue, Aug 05, 2025 at 01:49:31PM +0900, Simon Richter wrote:
> Hi,
>
> On 8/5/25 07:59, Eric Biggers wrote:
>
> > > md5sum uses the kernel's MD5 code:
>
> > What? That's crazy. Userspace MD5 code would be faster and more
> > reliable. No need to make syscalls, transfer data to and from the
Hi,
On 8/5/25 07:59, Eric Biggers wrote:
md5sum uses the kernel's MD5 code:
What? That's crazy. Userspace MD5 code would be faster and more
reliable. No need to make syscalls, transfer data to and from the
kernel, have an external dependency, etc. Is this the coreutils md5sum?
We need to
POWER8 support a maximum of 16 subcrq indirect descriptor entries per
H_SEND_SUB_CRQ_INDIRECT call, while POWER9 and newer hypervisors
support up to 128 entries. Increasing the max number of indirect
descriptor entries improves batching efficiency and reduces
hcall overhead, which enhances throug
On Mon, Aug 04, 2025 at 10:59:01PM +, Eric Biggers wrote:
> On Mon, Aug 04, 2025 at 09:02:27PM +0200, Christophe Leroy wrote:
> >
> >
> > Le 04/08/2025 à 20:09, Eric Biggers a écrit :
> > > On Mon, Aug 04, 2025 at 07:42:15PM +0200, Christophe Leroy wrote:
> > > >
> > > >
> > > > Le 03/08/20
On Mon, Aug 04, 2025 at 09:02:27PM +0200, Christophe Leroy wrote:
>
>
> Le 04/08/2025 à 20:09, Eric Biggers a écrit :
> > On Mon, Aug 04, 2025 at 07:42:15PM +0200, Christophe Leroy wrote:
> > >
> > >
> > > Le 03/08/2025 à 22:44, Eric Biggers a écrit :
> > > > MD5 is insecure, is no longer commo
Le 04/08/2025 à 20:09, Eric Biggers a écrit :
On Mon, Aug 04, 2025 at 07:42:15PM +0200, Christophe Leroy wrote:
Le 03/08/2025 à 22:44, Eric Biggers a écrit :
MD5 is insecure, is no longer commonly used, and has never been
optimized for the most common architectures in the kernel. Only mip
https://bugzilla.kernel.org/show_bug.cgi?id=220407
--- Comment #2 from Avraham Hollander (anhollander...@gmail.com) ---
(In reply to Christophe Leroy from comment #1)
> This is fixed with commit
> https://github.com/torvalds/linux/commit/
> 5a821e2d69e26b51b7f3740b6b0c3462b8cacaff
Oh now I see th
https://bugzilla.kernel.org/show_bug.cgi?id=220407
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
On Mon, Aug 04, 2025 at 07:42:15PM +0200, Christophe Leroy wrote:
>
>
> Le 03/08/2025 à 22:44, Eric Biggers a écrit :
> > MD5 is insecure, is no longer commonly used, and has never been
> > optimized for the most common architectures in the kernel. Only mips,
> > powerpc, and sparc have optimize
Le 03/08/2025 à 22:44, Eric Biggers a écrit :
MD5 is insecure, is no longer commonly used, and has never been
optimized for the most common architectures in the kernel. Only mips,
powerpc, and sparc have optimized MD5 code in the kernel. Of these,
only the powerpc one is actually testable in
On 8/4/25 10:12, Breno Leitao wrote:
...
> +- These errros are divided by are, which includes CPU, Memory, PCI, CXL and
> + others.
There's a double typo in there I think:
errros => errors
and
are,=>area,
> --- a/include/linux/vmcore_info.h
> +++ b/include/linux/vmcore_info.h
>
On Mon, Aug 04, 2025 at 09:44:06AM -0700, Kees Cook wrote:
> While tracking down a problem where constant expressions used by
> BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
> initializer was convincing the compiler that it couldn't track the state
> of the prior statica
On Fri, Aug 01, 2025 at 10:06:51AM -0700, Dave Hansen wrote:
> On 8/1/25 10:00, Breno Leitao wrote:
> > Would a solution like this look better?
> >
> > enum hwerr_error_type {
> > HWERR_RECOV_CPU,
> > HWERR_RECOV_MEMORY,
> > HWERR_RECOV_PCI,
> >
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
Hello Sathyanarayanan
On Mon, Aug 04, 2025 at 09:11:27AM -0700, Sathyanarayanan Kuppuswamy wrote:
>
> On 8/4/25 8:35 AM, Breno Leitao wrote:
> > Hello Sathyanarayanan,
> >
> > On Mon, Aug 04, 2025 at 06:50:30AM -0700, Sathyanarayanan Kuppuswamy wrote:
> > > On 8/4/25 2:17 AM, Breno Leitao wrote:
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
Add KUnit tests for ffs()-family bit scanning functions: ffs(), __ffs(),
fls(), __fls(), fls64(), __ffs64(), and ffz(). The tests validate
mathematical relationships (e.g. ffs(x) == __ffs(x) + 1), and test zero
values, power-of-2 patterns, maximum values, and sparse bit patterns.
Build and run tes
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
Hi,
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was
While tracking down a problem where constant expressions used by
BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
initializer was convincing the compiler that it couldn't track the state
of the prior statically initialized value. Tracing this down found that
ffs() was used
I am using the R580 chip which is the Radeon X1950 XT.
The board i am using is a T1042 PowerPC based one with e5500 core.
I also lost the ability to start Xorg and therefore just a blank screen.
Dave
Op ma 4 aug 2025, 18:04 schreef Christian Zigotzky :
>
> On 04 August 2025 at 04:42 pm, Al
On 8/4/25 8:35 AM, Breno Leitao wrote:
Hello Sathyanarayanan,
On Mon, Aug 04, 2025 at 06:50:30AM -0700, Sathyanarayanan Kuppuswamy wrote:
On 8/4/25 2:17 AM, Breno Leitao wrote:
Similarly to pci_dev_aer_stats_incr(), pci_print_aer() may be called
when dev->aer_info is NULL. Add a NULL check b
On 04 August 2025 at 04:42 pm, Alex Deucher wrote:
On Sun, Aug 3, 2025 at 11:28 AM Christian Zigotzky
wrote:
Hello,
I have the same issue on another machine either. Blank screen during the
boot. The Radeon graphics framebuffer device doesn't work anymore.
Here is the modifed code from the
Hello Sathyanarayanan,
On Mon, Aug 04, 2025 at 06:50:30AM -0700, Sathyanarayanan Kuppuswamy wrote:
>
> On 8/4/25 2:17 AM, Breno Leitao wrote:
> > Similarly to pci_dev_aer_stats_incr(), pci_print_aer() may be called
> > when dev->aer_info is NULL. Add a NULL check before proceeding to avoid
> > ca
Le 22/07/2025 à 10:56, Aditya Bodkhe a écrit :
commit a1be9ccc57f0 ("function_graph: Support recording and printing the
return value of function") introduced support for function graph return
value tracing.
Additionally, commit a3ed4157b7d8 ("fgraph: Replace fgraph_ret_regs with
ftrace_regs")
On Sun, Aug 3, 2025 at 11:28 AM Christian Zigotzky
wrote:
>
> Hello,
>
> I have the same issue on another machine either. Blank screen during the
> boot. The Radeon graphics framebuffer device doesn't work anymore.
>
> Here is the modifed code from the DRM updates (drm-next-2025-07-30):
>
> -
> ht
https://bugzilla.kernel.org/show_bug.cgi?id=220407
Christophe Leroy (christophe.le...@csgroup.eu) changed:
What|Removed |Added
CC||christoph
https://bugzilla.kernel.org/show_bug.cgi?id=220407
Bug ID: 220407
Summary: arch/powerpc/boot/types.h:43:13: error: 'bool' cannot
be defined via 'typedef' when building with GCC 15
Product: Platform Specific/Hardware
Version: 2.5
On 8/4/25 2:17 AM, Breno Leitao wrote:
Similarly to pci_dev_aer_stats_incr(), pci_print_aer() may be called
when dev->aer_info is NULL. Add a NULL check before proceeding to avoid
calling aer_ratelimit() with a NULL aer_info pointer, returning 1, which
does not rate limit, given this is fatal.
"Nicholas Piggin" writes:
> Hmm, interesting bug. Impressive work to track it down.
>
Thanks Nick for taking a look at it.
> On Fri Aug 1, 2025 at 8:37 PM AEST, Donet Tom wrote:
>> On systems using the hash MMU, there is a software SLB preload cache that
>> mirrors the entries loaded into the h
On Mon, Aug 4, 2025 at 5:04 PM Christophe Leroy
wrote:
>
> Hi,
>
> Le 03/08/2025 à 21:27, Sabyrzhan Tasbolatov a écrit :
> > On Wed, Jul 23, 2025 at 10:33 PM Andrey Ryabinin
> > wrote:
> >>
> >> ...
> >>
> >> I don't know if it's a real problem or not. I'm just pointing out that we
> >> might
>
From: Leon Romanovsky
Make sure that CPU is not synced and IOMMU is configured to take
MMIO path by providing newly introduced DMA_ATTR_MMIO attribute.
Signed-off-by: Leon Romanovsky
---
block/blk-mq-dma.c | 13 +++--
include/linux/blk-mq-dma.h | 6 +-
include/linux/blk_ty
From: Leon Romanovsky
Block layer maps MMIO memory through dma_map_phys() interface
with help of DMA_ATTR_MMIO attribute. There is a need to unmap
that memory with the appropriate unmap function.
Signed-off-by: Leon Romanovsky
---
drivers/nvme/host/pci.c | 18 +-
1 file changed
From: Leon Romanovsky
After introduction of dma_map_phys(), there is no need to convert
from physical address to struct page in order to map page. So let's
use it directly.
Signed-off-by: Leon Romanovsky
---
block/blk-mq-dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --g
From: Leon Romanovsky
In case peer-to-peer transaction traverses through host bridge,
the IOMMU needs to have IOMMU_MMIO flag, together with skip of
CPU sync.
The latter was handled by provided DMA_ATTR_SKIP_CPU_SYNC flag,
but IOMMU flag was missed, due to assumption that such memory
can be trea
From: Leon Romanovsky
General dma_direct_map_resource() is going to be removed
in next patch, so simply open-code it in xen driver.
Signed-off-by: Leon Romanovsky
---
drivers/xen/swiotlb-xen.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/xen
From: Leon Romanovsky
Convert HMM DMA operations from the legacy page-based API to the new
physical address-based dma_map_phys() and dma_unmap_phys() functions.
This demonstrates the preferred approach for new code that should use
physical addresses directly rather than page+offset parameters.
T
From: Leon Romanovsky
Introduce new DMA mapping functions dma_map_phys() and dma_unmap_phys()
that operate directly on physical addresses instead of page+offset
parameters. This provides a more efficient interface for drivers that
already have physical addresses available.
The new functions are
From: Leon Romanovsky
Convert the KMSAN DMA handling function from page-based to physical
address-based interface.
The refactoring renames kmsan_handle_dma() parameters from accepting
(struct page *page, size_t offset, size_t size) to (phys_addr_t phys,
size_t size). A PFN_VALID check is added t
From: Leon Romanovsky
Extend base DMA page API to handle MMIO flow.
Signed-off-by: Leon Romanovsky
---
kernel/dma/mapping.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 709405d46b2b4..f5f051737e5
From: Leon Romanovsky
Rename the IOMMU DMA mapping functions to better reflect their actual
calling convention. The functions iommu_dma_map_page() and
iommu_dma_unmap_page() are renamed to iommu_dma_map_phys() and
iommu_dma_unmap_phys() respectively, as they already operate on physical
addresses
From: Leon Romanovsky
Convert the DMA direct mapping functions to accept physical addresses
directly instead of page+offset parameters. The functions were already
operating on physical addresses internally, so this change eliminates
the redundant page-to-physical conversion at the API boundary.
From: Leon Romanovsky
Combine iommu_dma_*map_phys with iommu_dma_*map_resource interfaces in
order to allow single phys_addr_t flow.
Signed-off-by: Leon Romanovsky
---
drivers/iommu/dma-iommu.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/io
From: Leon Romanovsky
As a preparation for following map_page -> map_phys API conversion,
let's rename trace_dma_*map_page() to be trace_dma_*map_phys().
Signed-off-by: Leon Romanovsky
---
include/trace/events/dma.h | 4 ++--
kernel/dma/mapping.c | 4 ++--
2 files changed, 4 insertions(+
From: Leon Romanovsky
This patch introduces the DMA_ATTR_MMIO attribute to mark DMA buffers
that reside in memory-mapped I/O (MMIO) regions, such as device BARs
exposed through the host bridge, which are accessible for peer-to-peer
(P2P) DMA.
This attribute is especially useful for exporting dev
From: Leon Romanovsky
Convert the DMA debug infrastructure from page-based to physical address-based
mapping as a preparation to rely on physical address for DMA mapping routines.
The refactoring renames debug_dma_map_page() to debug_dma_map_phys() and
changes its signature to accept a phys_addr
From: Leon Romanovsky
Make sure that CPU is not synced if MMIO path is taken.
Signed-off-by: Leon Romanovsky
---
drivers/iommu/dma-iommu.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index ea2e
Changelog:
v1:
* Added new DMA_ATTR_MMIO attribute to indicate
PCI_P2PDMA_MAP_THRU_HOST_BRIDGE path.
* Rewrote dma_map_* functions to use thus new attribute
v0: https://lore.kernel.org/all/cover.1750854543.git.l...@kernel.org/
---
Hmm, interesting bug. Impressive work to track it down.
On Fri Aug 1, 2025 at 8:37 PM AEST, Donet Tom wrote:
> On systems using the hash MMU, there is a software SLB preload cache that
> mirrors the entries loaded into the hardware SLB buffer. This preload
> cache is subject to periodic eviction —
Hi,
Le 03/08/2025 à 21:27, Sabyrzhan Tasbolatov a écrit :
On Wed, Jul 23, 2025 at 10:33 PM Andrey Ryabinin wrote:
...
I don't know if it's a real problem or not. I'm just pointing out that we might
have tricky use case here and maybe that's a problem, because nobody had such
use
case in min
On Fri, Aug 01, 2025 at 04:07:47PM +0530, Donet Tom wrote:
> On systems using the hash MMU, there is a software SLB preload cache that
> mirrors the entries loaded into the hardware SLB buffer. This preload
> cache is subject to periodic eviction — typically after every 256 context
> switches — to
On Thu, 2025-07-31 at 15:01 +0200, Lukas Wunner wrote:
> On Wed, Jul 30, 2025 at 10:24:07PM +0200, Lukas Wunner wrote:
> > On Wed, Jul 30, 2025 at 10:01:50PM +0200, Lukas Wunner wrote:
> > > On Wed, Jul 30, 2025 at 01:20:57PM +0200, Niklas Schnelle wrote:
> > > > Since commit 7b42d97e99d3 ("PCI/ERR
Hello, Lorenzo!
> So sorry Ulad, I meant to get back to you on this sooner!
>
> On Tue, Jul 29, 2025 at 08:39:01PM +0200, Uladzislau Rezki wrote:
> > On Tue, Jul 29, 2025 at 06:25:39AM +0100, Lorenzo Stoakes wrote:
> > > Andrew - FYI there's nothing to worry about here, the type remains
> > > pre
On 8/4/25 12:07, Nam Cao wrote:
pnv_irq_domain_alloc() allocates interrupts at parent's interrupt
domain. If it fails in the progress, all allocated interrupts are
freed.
The number of successfully allocated interrupts so far is stored
"i". However, "i - 1" interrupts are freed. This is broken:
On 8/4/25 12:07, Nam Cao wrote:
pseries_irq_domain_alloc() allocates interrupts at parent's interrupt
domain. If it fails in the progress, all allocated interrupts are
freed.
The number of successfully allocated interrupts so far is stored
"i". However, "i - 1" interrupts are freed. This is brok
pnv_irq_domain_alloc() allocates interrupts at parent's interrupt
domain. If it fails in the progress, all allocated interrupts are
freed.
The number of successfully allocated interrupts so far is stored
"i". However, "i - 1" interrupts are freed. This is broken:
- One interrupt is not be fre
pseries_irq_domain_alloc() allocates interrupts at parent's interrupt
domain. If it fails in the progress, all allocated interrupts are
freed.
The number of successfully allocated interrupts so far is stored
"i". However, "i - 1" interrupts are freed. This is broken:
- One interrupt is not be f
Hi,
This series fixes integer overflow & leak problem. I noticed this problem
when Gautam reported a kernel bug with another patch series of mine:
https://lore.kernel.org/linuxppc-dev/ah9na8zqri0jp...@li-c6426e4c-27cf-11b2-a85c-95d65bc0de0e.ibm.com/
The root cause of that report is a bug in that
On Fri, Aug 01, 2025 at 11:59:08AM +0800, Xichao Zhao wrote:
> Simplify the code to enhance readability and maintain a consistent
> coding style.
>
>
> Signed-off-by: Xichao Zhao
> ---
> arch/powerpc/kernel/setup_64.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git
Similarly to pci_dev_aer_stats_incr(), pci_print_aer() may be called
when dev->aer_info is NULL. Add a NULL check before proceeding to avoid
calling aer_ratelimit() with a NULL aer_info pointer, returning 1, which
does not rate limit, given this is fatal.
This prevents a kernel crash triggered by
FYI: We are using PowerPC machines.
+ dri-devel
> On 03 August 2025 at 05:28 pm, Christian Zigotzky
> wrote:
>
> Hello,
>
> I have the same issue on another machine either. Blank screen during the
> boot. The Radeon graphics framebuffer device doesn't work anymore.
>
> Here is the modifed
> On 22 Jul 2025, at 2:26 PM, Aditya Bodkhe wrote:
>
> From: Hari Bathini
>
> Since commit 4346ba160409 ("fprobe: Rewrite fprobe on function-graph
> tracer"), FPROBE depends on HAVE_FUNCTION_GRAPH_FREGS. With previous
> patch adding HAVE_FUNCTION_GRAPH_FREGS for powerpc, FPROBE can be
> enab
> On 22 Jul 2025, at 2:26 PM, Aditya Bodkhe wrote:
>
> commit a1be9ccc57f0 ("function_graph: Support recording and printing the
> return value of function") introduced support for function graph return
> value tracing.
>
> Additionally, commit a3ed4157b7d8 ("fgraph: Replace fgraph_ret_regs wi
> On 16 Jul 2025, at 3:17 PM, Shrikanth Hegde wrote:
>
> Dynamic preemption can be static key or static call based.
> Static key is used to check kernel preemption depending on
> the current preemption model. i.e enable for lazy, full.
>
> Code is currently spread across entry/common.c, arm6
> On 16 Jul 2025, at 4:15 PM, Srikar Dronamraju wrote:
>
> Systems can now be partitioned into resource groups. By default all
> systems will be part of default resource group. Once a resource group is
> created, and resources allocated to the resource group, those resources
> will be removed
85 matches
Mail list logo
