With CONFIG_DEBUG_PREEMPT we observed reports like:
BUG: using smp_processor_id() in preemptible
caller is perf_ftrace_function_call+0x6f/0x2e0
CPU: 1 PID: 680 Comm: a.out Not tainted
Call Trace:
dump_stack_lvl+0x8d/0xcf
check_preemption_disabled+0x104/0x110
?
As the documentation explained, ftrace_test_recursion_trylock()
and ftrace_test_recursion_unlock() were supposed to disable and
enable preemption properly, however currently this work is done
outside of the function, which could be missing by mistake.
This path will make sure the preemption was
The testing show that perf_ftrace_function_call() are using smp_processor_id()
with preemption enabled, all the checking on CPU could be wrong after
preemption.
As Peter point out, the section between ftrace_test_recursion_trylock/unlock()
pair require the preemption to be disabled as
On 2021/10/13 上午11:26, Steven Rostedt wrote:
> Please start a new thread when sending new versions. v2 should not be a
> reply to v1. If you want to reference v1, just add it to the cover
> letter with a link tag:
>
> Link:
>
Please start a new thread when sending new versions. v2 should not be a
reply to v1. If you want to reference v1, just add it to the cover
letter with a link tag:
Link:
https://lore.kernel.org/all/8c7de46d-9869-aa5e-2bb9-5dbc2eda3...@linux.alibaba.com/
-- Steve
On Wed, 13 Oct 2021 11:16:56
With CONFIG_DEBUG_PREEMPT we observed reports like:
BUG: using smp_processor_id() in preemptible
caller is perf_ftrace_function_call+0x6f/0x2e0
CPU: 1 PID: 680 Comm: a.out Not tainted
Call Trace:
dump_stack_lvl+0x8d/0xcf
check_preemption_disabled+0x104/0x110
?
As the documentation explained, ftrace_test_recursion_trylock()
and ftrace_test_recursion_unlock() were supposed to disable and
enable preemption properly, however currently this work is done
outside of the function, which could be missing by mistake.
This path will make sure the preemption was
The testing show that perf_ftrace_function_call() are using smp_processor_id()
with preemption enabled, all the checking on CPU could be wrong after
preemption.
As Peter point out, the section between ftrace_test_recursion_trylock/unlock()
pair require the preemption to be disabled as
On 2021/10/13 上午10:30, Steven Rostedt wrote:
> On Wed, 13 Oct 2021 10:04:52 +0800
> 王贇 wrote:
>
>> I see, while the user can still check smp_processor_id() after trylock
>> return bit 0...
>
> But preemption would have already been disabled. That's because a bit 0
> means that a recursion
On 2021/10/13 上午10:27, Steven Rostedt wrote:
> On Wed, 13 Oct 2021 09:50:17 +0800
> 王贇 wrote:
>
- preempt_enable_notrace();
ftrace_test_recursion_unlock(bit);
}
>>>
>>> I don't like this change much. We have preempt_disable there not because
>>> of
On Wed, 13 Oct 2021 10:04:52 +0800
王贇 wrote:
> I see, while the user can still check smp_processor_id() after trylock
> return bit 0...
But preemption would have already been disabled. That's because a bit 0
means that a recursion check has already been made by a previous
caller and this one is
On Wed, 13 Oct 2021 09:50:17 +0800
王贇 wrote:
> >> - preempt_enable_notrace();
> >>ftrace_test_recursion_unlock(bit);
> >> }
> >
> > I don't like this change much. We have preempt_disable there not because
> > of ftrace_test_recursion, but because of RCU. ftrace_test_recursion was
> >
On 2021/10/12 下午8:43, Steven Rostedt wrote:
> On Tue, 12 Oct 2021 13:40:08 +0800
> 王贇 wrote:
>
>> --- a/include/linux/trace_recursion.h
>> +++ b/include/linux/trace_recursion.h
>> @@ -214,7 +214,14 @@ static __always_inline void trace_clear_recursion(int
>> bit)
>> static __always_inline
On 2021/10/12 下午8:29, Steven Rostedt wrote:
> On Tue, 12 Oct 2021 14:24:43 +0200 (CEST)
> Miroslav Benes wrote:
>
>>> +++ b/kernel/livepatch/patch.c
>>> @@ -52,11 +52,6 @@ static void notrace klp_ftrace_handler(unsigned long ip,
>>> bit = ftrace_test_recursion_trylock(ip, parent_ip);
>>>
On 2021/10/12 下午8:24, Miroslav Benes wrote:
[snip]
>>
>> func = list_first_or_null_rcu(>func_stack, struct klp_func,
>>stack_node);
>> @@ -120,7 +115,6 @@ static void notrace klp_ftrace_handler(unsigned long ip,
>> klp_arch_set_pc(fregs, (unsigned
On 2021/10/12 下午8:17, Steven Rostedt wrote:
> On Tue, 12 Oct 2021 13:40:08 +0800
> 王贇 wrote:
>
>> @@ -52,11 +52,6 @@ static void notrace klp_ftrace_handler(unsigned long ip,
>> bit = ftrace_test_recursion_trylock(ip, parent_ip);
>> if (WARN_ON_ONCE(bit < 0))
>> return;
On 2021/10/12 下午7:20, Peter Zijlstra wrote:
> On Tue, Oct 12, 2021 at 01:40:31PM +0800, 王贇 wrote:
>
>> diff --git a/kernel/trace/trace_event_perf.c
>> b/kernel/trace/trace_event_perf.c
>> index 6aed10e..33c2f76 100644
>> --- a/kernel/trace/trace_event_perf.c
>> +++
From: "Naveen N. Rao"
[ Upstream commit 030905920f32e91a52794937f67434ac0b3ea41a ]
Add a helper to return the stf_barrier type for the current processor.
Signed-off-by: Naveen N. Rao
Signed-off-by: Michael Ellerman
Link:
From: "Naveen N. Rao"
[ Upstream commit 030905920f32e91a52794937f67434ac0b3ea41a ]
Add a helper to return the stf_barrier type for the current processor.
Signed-off-by: Naveen N. Rao
Signed-off-by: Michael Ellerman
Link:
From: "Naveen N. Rao"
[ Upstream commit 030905920f32e91a52794937f67434ac0b3ea41a ]
Add a helper to return the stf_barrier type for the current processor.
Signed-off-by: Naveen N. Rao
Signed-off-by: Michael Ellerman
Link:
From: "Naveen N. Rao"
[ Upstream commit 030905920f32e91a52794937f67434ac0b3ea41a ]
Add a helper to return the stf_barrier type for the current processor.
Signed-off-by: Naveen N. Rao
Signed-off-by: Michael Ellerman
Link:
From: "Naveen N. Rao"
[ Upstream commit 030905920f32e91a52794937f67434ac0b3ea41a ]
Add a helper to return the stf_barrier type for the current processor.
Signed-off-by: Naveen N. Rao
Signed-off-by: Michael Ellerman
Link:
From: "Naveen N. Rao"
[ Upstream commit 030905920f32e91a52794937f67434ac0b3ea41a ]
Add a helper to return the stf_barrier type for the current processor.
Signed-off-by: Naveen N. Rao
Signed-off-by: Michael Ellerman
Link:
From: "Naveen N. Rao"
[ Upstream commit b7540d62509453263604a155bf2d5f0ed450cba2 ]
Emit similar instruction sequences to commit a048a07d7f4535
("powerpc/64s: Add support for a store forwarding barrier at kernel
entry/exit") when encountering BPF_NOSPEC.
Mitigations are enabled depending on
From: "Naveen N. Rao"
[ Upstream commit 030905920f32e91a52794937f67434ac0b3ea41a ]
Add a helper to return the stf_barrier type for the current processor.
Signed-off-by: Naveen N. Rao
Signed-off-by: Michael Ellerman
Link:
From: "Naveen N. Rao"
[ Upstream commit 3832ba4e283d7052b783dab8311df7e3590fed93 ]
Add checks to ensure that we never emit branch instructions with
truncated branch offsets.
Suggested-by: Michael Ellerman
Signed-off-by: Naveen N. Rao
Tested-by: Johan Almbladh
Reviewed-by: Christophe Leroy
From: "Naveen N. Rao"
[ Upstream commit 4549c3ea3160fa8b3f37dfe2f957657bb265eda9 ]
Add a helper to check if a given offset is within the branch range for a
powerpc conditional branch instruction, and update some sites to use the
new helper.
Signed-off-by: Naveen N. Rao
Reviewed-by: Christophe
Christophe Leroy writes:
> Le 12/10/2021 à 08:24, Michael Ellerman a écrit :
>> Liu Shixin writes:
>>> kindly ping.
>>
>> I was under the impression you were trying to debug why it wasn't
>> working with Christophe.
>
> The investigation was a bit dormant to be honest since Liu confirmed
>
On Mon, Oct 04, 2021 at 02:59:24PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> this is v6 of the quest to drop the "driver" member from struct pci_dev
> which tracks the same data (apart from a constant offset) as dev.driver.
I like this a lot and applied it to pci/driver for v5.16, thanks!
I
Laurent Vivier writes:
> Commit 112665286d08 moved guest_exit() in the interrupt protected
> area to avoid wrong context warning (or worse), but the tick counter
> cannot be updated and the guest time is accounted to the system time.
>
> To fix the problem port to POWER the x86 fix
> 160457140187
From: Jarkko Sakkinen
> Sent: 12 October 2021 18:41
>
> On Tue, 2021-10-12 at 12:43 -0300, Jason Gunthorpe wrote:
> > On Tue, Oct 12, 2021 at 06:29:58PM +0300, Jarkko Sakkinen wrote:
> > > On Mon, 2021-10-11 at 00:01 +0800, Cai Huoqing wrote:
> > > > Replacing
On Tue, 2021-10-12 at 12:43 -0300, Jason Gunthorpe wrote:
> On Tue, Oct 12, 2021 at 06:29:58PM +0300, Jarkko Sakkinen wrote:
> > On Mon, 2021-10-11 at 00:01 +0800, Cai Huoqing wrote:
> > > Replacing kmalloc/kfree/get_zeroed_page/free_page/dma_map_single/
> > ~
> > Replace
> >
> > >
Le 12/10/2021 à 08:24, Michael Ellerman a écrit :
Liu Shixin writes:
kindly ping.
I was under the impression you were trying to debug why it wasn't
working with Christophe.
The investigation was a bit dormant to be honest since Liu confirmed
that neither KFENCE not DEBUG_PAGEALLOC
On Tue, Oct 12, 2021 at 06:29:58PM +0300, Jarkko Sakkinen wrote:
> On Mon, 2021-10-11 at 00:01 +0800, Cai Huoqing wrote:
> > Replacing kmalloc/kfree/get_zeroed_page/free_page/dma_map_single/
> ~
> Replace
>
> > dma_unmap_single() with dma_alloc_coherent/dma_free_coherent()
> > helps
The mpc5xxx platforms have had dts warnings for some time which no one
seems to care to fix, so let's just remove the dts files.
According to Arnd:
"Specifically, MPC5200B has a 15 year lifetime, which ends in
11 months from now. The original bplan/Genesi Efika 5K2 was
quite popular at the time
On Mon, 2021-10-11 at 00:01 +0800, Cai Huoqing wrote:
> Replacing kmalloc/kfree/get_zeroed_page/free_page/dma_map_single/
~
Replace
> dma_unmap_single() with dma_alloc_coherent/dma_free_coherent()
> helps to reduce code size, and simplify the code, and coherent
> DMA will not clear
On Mon, Oct 11, 2021 at 10:42 PM Rob Herring wrote:
> On Sun, Oct 10, 2021 at 4:27 PM Stephen Rothwell
> wrote:
> FYI, u-boot removed mpc5xxx support in 2017, so maybe there's
> similarly not a need to keep them in the kernel? It does appear NXP
> will still sell you the parts though the last
From: Ravi Bangoria
SEEN_STACK is unused on PowerPC. Remove it. Also, have
SEEN_TAILCALL use 0x4000.
Signed-off-by: Ravi Bangoria
Reviewed-by: Christophe Leroy
---
* No changes in v4.
arch/powerpc/net/bpf_jit.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
On Tue, 12 Oct 2021 13:40:08 +0800
王贇 wrote:
> --- a/include/linux/trace_recursion.h
> +++ b/include/linux/trace_recursion.h
> @@ -214,7 +214,14 @@ static __always_inline void trace_clear_recursion(int
> bit)
> static __always_inline int ftrace_test_recursion_trylock(unsigned long ip,
>
Patch #1 & #2 are simple cleanup patches. Patch #3 refactors JIT
compiler code with the aim to simplify adding BPF_PROBE_MEM support.
Patch #4 introduces PPC_RAW_BRANCH() macro instead of open coding
branch instruction. Patch #5 & #7 add BPF_PROBE_MEM support for PPC64
& PPC32 JIT compilers
> diff --git a/include/linux/trace_recursion.h b/include/linux/trace_recursion.h
> index a9f9c57..805f9c4 100644
> --- a/include/linux/trace_recursion.h
> +++ b/include/linux/trace_recursion.h
> @@ -214,7 +214,14 @@ static __always_inline void trace_clear_recursion(int
> bit)
> static
With KUAP enabled, any kernel code which wants to access userspace
needs to be surrounded by disable-enable KUAP. But that is not
happening for BPF_PROBE_MEM load instruction. Though PPC32 does not
support read protection, considering the fact that PTR_TO_BTF_ID
(which uses BPF_PROBE_MEM mode)
BPF load instruction with BPF_PROBE_MEM mode can cause a fault
inside kernel. Append exception table for such instructions
within BPF program.
Unlike other archs which uses extable 'fixup' field to pass dest_reg
and nip, BPF exception table on PowerPC follows the generic PowerPC
exception table
Define and use PPC_RAW_BRANCH() macro instead of open coding it. This
macro is used while adding BPF_PROBE_MEM support.
Signed-off-by: Hari Bathini
Reviewed-by: Christophe Leroy
---
* No changes in v4.
arch/powerpc/include/asm/ppc-opcode.h | 2 ++
arch/powerpc/net/bpf_jit.h| 2
From: Ravi Bangoria
On PPC64 with KUAP enabled, any kernel code which wants to
access userspace needs to be surrounded by disable-enable KUAP.
But that is not happening for BPF_PROBE_MEM load instruction.
So, when BPF program tries to access invalid userspace address,
page-fault handler
From: Ravi Bangoria
BPF load instruction with BPF_PROBE_MEM mode can cause a fault
inside kernel. Append exception table for such instructions
within BPF program.
Unlike other archs which uses extable 'fixup' field to pass dest_reg
and nip, BPF exception table on PowerPC follows the generic
Refactor powerpc LDX JITing code to simplify adding BPF_PROBE_MEM
support.
Signed-off-by: Hari Bathini
Reviewed-by: Christophe Leroy
---
Changes in v4:
* Dropped the default case in the switch statement for bpf size.
* Dropped explicit fallthrough statement for empty switch cases.
From: Ravi Bangoria
In case of extra_pass, usual JIT passes are always skipped. So,
extra_pass is always false while calling bpf_jit_build_body() and
can be removed.
Signed-off-by: Ravi Bangoria
---
* No changes in v4.
arch/powerpc/net/bpf_jit.h| 2 +-
On Tue, 12 Oct 2021 14:24:43 +0200 (CEST)
Miroslav Benes wrote:
> > +++ b/kernel/livepatch/patch.c
> > @@ -52,11 +52,6 @@ static void notrace klp_ftrace_handler(unsigned long ip,
> > bit = ftrace_test_recursion_trylock(ip, parent_ip);
> > if (WARN_ON_ONCE(bit < 0))
> >
On Tue, 12 Oct 2021 13:40:08 +0800
王贇 wrote:
> @@ -52,11 +52,6 @@ static void notrace klp_ftrace_handler(unsigned long ip,
> bit = ftrace_test_recursion_trylock(ip, parent_ip);
> if (WARN_ON_ONCE(bit < 0))
> return;
> - /*
> - * A variant of synchronize_rcu()
On Tue, Oct 12, 2021 at 01:40:31PM +0800, 王贇 wrote:
> diff --git a/kernel/trace/trace_event_perf.c b/kernel/trace/trace_event_perf.c
> index 6aed10e..33c2f76 100644
> --- a/kernel/trace/trace_event_perf.c
> +++ b/kernel/trace/trace_event_perf.c
> @@ -441,12 +441,19 @@ void
max_mapnr is used by virt_addr_valid() to check if a linear
address is valid.
It must only include lowmem PFNs, like other architectures.
Problem detected on a system with 1G mem (Only 768M are mapped), with
CONFIG_DEBUG_VIRTUAL and CONFIG_TEST_DEBUG_VIRTUAL, it didn't report
On Tue, Oct 12, 2021 at 01:04:54PM +0530, Naresh Kamboju wrote:
> On Tue, 12 Oct 2021 at 12:16, Greg Kroah-Hartman
> wrote:
> >
> > This is the start of the stable review cycle for the 5.4.153 release.
> > There are 52 patches in this series, all will be posted as a response
> > to this one. If
On Tue, Oct 12, 2021 at 9:10 AM Michael Ellerman wrote:
> Christophe Leroy writes:
> > 'struct ppc64_opd_entry' doesn't belong to uapi/asm/elf.h
> > But it was by mistake added outside of __KERNEL__ section,
> > therefore commit c3617f72036c ("UAPI: (Scripted) Disintegrate
> >
On Tue, 12 Oct 2021 at 12:16, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 5.4.153 release.
> There are 52 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
Christophe Leroy writes:
> 'struct ppc64_opd_entry' doesn't belong to uapi/asm/elf.h
Agree, but ...
> It was initially in module_64.c and commit 2d291e902791 ("Fix compile
> failure with non modular builds") moved it into asm/elf.h
>
> But it was by mistake added outside of __KERNEL__ section,
* Christophe Leroy :
>
>
> Le 12/10/2021 à 08:02, Helge Deller a écrit :
> > On 10/11/21 17:25, Christophe Leroy wrote:
> > > Use HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR instead of
> > > 'dereference_function_descriptor'
> > > to know whether arch has function descriptors.
> > >
> > > Signed-off-by:
Liu Shixin writes:
> kindly ping.
I was under the impression you were trying to debug why it wasn't
working with Christophe.
cheers
> On 2021/9/24 14:39, Liu Shixin wrote:
>> On platform PPC_FSL_BOOK3E, all lowmem is managed by tlbcam. That means
>> we didn't really map the kfence pool with
Hi Cai,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.15-rc5 next-20211011]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
Le 12/10/2021 à 08:02, Helge Deller a écrit :
On 10/11/21 17:25, Christophe Leroy wrote:
Use HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR instead of
'dereference_function_descriptor'
to know whether arch has function descriptors.
Signed-off-by: Christophe Leroy
---
On 10/11/21 17:25, Christophe Leroy wrote:
> Use HAVE_DEREFERENCE_FUNCTION_DESCRIPTOR instead of
> 'dereference_function_descriptor'
> to know whether arch has function descriptors.
>
> Signed-off-by: Christophe Leroy
> ---
> arch/ia64/include/asm/sections.h| 4 ++--
>
The testing show that perf_ftrace_function_call() are using
smp_processor_id() with preemption enabled, all the checking
on CPU could be wrong after preemption, PATCH 1/2 will fix
that.
Besides, as Peter point out, the testing of recursion within
the section between
On 2021/10/12 下午1:39, 王贇 wrote:
> The testing show that perf_ftrace_function_call() are using
> smp_processor_id() with preemption enabled, all the checking
> on CPU could be wrong after preemption, PATCH 1/2 will fix
> that.
2/2 actually.
>
> Besides, as Peter point out, the testing of
With CONFIG_DEBUG_PREEMPT we observed reports like:
BUG: using smp_processor_id() in preemptible
caller is perf_ftrace_function_call+0x6f/0x2e0
CPU: 1 PID: 680 Comm: a.out Not tainted
Call Trace:
dump_stack_lvl+0x8d/0xcf
check_preemption_disabled+0x104/0x110
?
As the documentation explained, ftrace_test_recursion_trylock()
and ftrace_test_recursion_unlock() were supposed to disable and
enable preemption properly, however currently this work is done
outside of the function, which could be missing by mistake.
This path will make sure the preemption will
Le 12/10/2021 à 03:13, Joel Stanley a écrit :
The page_alloc.c code will call into __kernel_map_pages when
DEBUG_PAGEALLOC is configured and enabled.
As the implementation assumes hash, this should crash spectacularly if
not for a bit of luck in __kernel_map_pages. In this function
66 matches
Mail list logo
