Nicholas Miehlbradt writes:
> There is support for DEBUG_PAGEALLOC on hash but not on radix.
> Add support on radix.
>
> Signed-off-by: Nicholas Miehlbradt
> ---
> arch/powerpc/mm/book3s64/radix_pgtable.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/a
Le 19/09/2022 à 09:00, Michael Ellerman a écrit :
> Nicholas Miehlbradt writes:
>> There is support for DEBUG_PAGEALLOC on hash but not on radix.
>> Add support on radix.
>>
>> Signed-off-by: Nicholas Miehlbradt
>> ---
>> arch/powerpc/mm/book3s64/radix_pgtable.c | 16 +++-
>> 1 f
Le 19/09/2022 à 08:49, Benjamin Gray a écrit :
> On Mon, 2022-09-19 at 06:04 +, Christophe Leroy wrote:
>> With CONFIG_STRICT_KERNEL_RWX, this patches causes a 15% time
>> increase
>> for activation/deactivation of ftrace.
>
> It's possible that new alignment check is the cause. I'll see
>
On 19.09.22 04:13, Mike Kravetz wrote:
During discussions of this series [1], it was suggested that hugetlb
handling code in follow_page_mask could be simplified. At the beginning
of follow_page_mask, there currently is a call to follow_huge_addr which
'may' handle hugetlb pages. ia64 is the on
On 8/30/2022 23:14, Wolfram Sang wrote:
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.
On Tue, Aug 23, 2022 at 8:37 AM Greg Kroah-Hartman
wrote:
>
> On Thu, Jun 30, 2022 at 06:26:38PM -0700, Saravana Kannan wrote:
> > These patches are on top of driver-core-next.
> >
> > Even if stdout-path isn't set in DT, this patch should take console
> > probe times back to how they were before
On 9/7/22 09:49, Nicholas Piggin wrote:
On Mon Sep 5, 2022 at 4:38 PM AEST, Ganesh Goudar wrote:
Part of machine check error handling is done in realmode,
As of now instrumentation is not possible for any code that
runs in realmode.
When MCE is injected on KASAN enabled kernel, crash is
observe
https://bugzilla.kernel.org/show_bug.cgi?id=216504
Bug ID: 216504
Summary: no audio on iBook G4 (powerbook6,5)
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.19
Hardware: PPC-32
OS: Linux
T
Christophe Leroy writes:
> Le 16/09/2022 à 07:05, Samuel Holland a écrit :
>> With CONFIG_PREEMPT=y (involuntary preemption enabled), it is possible
>> to switch away from a task inside copy_{from,to}_user. This left the CPU
>> with userspace access enabled until after the next IRQ or privilege
>>
Le 19/09/2022 à 14:37, Michael Ellerman a écrit :
> Christophe Leroy writes:
>> Le 16/09/2022 à 07:05, Samuel Holland a écrit :
>>> With CONFIG_PREEMPT=y (involuntary preemption enabled), it is possible
>>> to switch away from a task inside copy_{from,to}_user. This left the CPU
>>> with userspa
Nathan Lynch writes:
> "Nicholas Piggin" writes:
>> On Wed Sep 14, 2022 at 3:39 AM AEST, Leonardo Brás wrote:
>>> On Mon, 2022-09-12 at 14:58 -0500, Nathan Lynch wrote:
>>> > Leonardo Brás writes:
>>> > > On Fri, 2022-09-09 at 09:04 -0500, Nathan Lynch wrote:
>>> > > > Leonardo Brás writes:
>>>
pcrel surprisingly didn't take much to get working, at least if
we ignore the hard bits (modules, ftrace, kprobes...). I'd like
to get it merged so we can incrementally fix the missing
bits. The series is functional but not quite polished, so this
is a good point to see if people agree with the app
Using a 16-bit constant for this marker allows it to be loaded with
a single 'li' instruction. On 64-bit this avoids a TOC entry and a
TOC load that depends on the r2 value that has just been loaded from
the PACA.
XXX: this probably should be 64-bit change and use 2 instruction
sequence that 32-bi
Use asm helpers to access global variables and to define them in asm.
Stop using got addressing and use the more common @toc offsets. 32-bit
already does this so that should be unchanged.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/boot/opal-calls.S | 6 +-
arch/powerpc/boot/pp
A later change stops the kernel using r2 and loads it with a poison
value. Provide a PACATOC loading abstraction which can hide this
detail.
XXX: 64e, KVM, ftrace not entirely done
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/ppc_asm.h | 3 +++
arch/powerpc/kernel/e
This macro is to be used in assembly where C functions are called.
pcrel addressing mode requires branches to functions with a
localentry value of 1 to have either a trailing nop or @notoc.
This macro permits the latter without changing callers.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/in
Update the 64s GENERIC_CPU option. POWER4 support has been dropped, so
make that clear in the option name.
-mtune= before power8 is dropped because the minimum gcc version
supports power8, and tuning is made consistent between big and little
endian.
Big endian drops -mcpu=power4 in favour of powe
This adds basic POWER10_CPU option, which builds with -mcpu=power10.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/Makefile | 7 ++-
arch/powerpc/platforms/Kconfig.cputype | 8 +++-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Makefile b
The main trick to this is that the kernel does not pick up the
PAGE_OFFSET (0xc load address) from the absolute address TOC load in
early boot so it doesn't load all addresses with the proper PAGE_OFFSET
as a matter of course, and needs to be moved there by hand.
- Extended inline asm memory a
CONFIG_PPC_FSL_BOOKE doesn't exist. Should be CONFIG_FSL_BOOKE.
Fixes: 49e3d8ea6248 ("powerpc/fsl_booke: Enable STRICT_KERNEL_RWX")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc
The only 64-bit Book3E CPUs we support require the selection
of CONFIG_PPC_E500MC.
However our Kconfig allows configurating a kernel that has 64-bit
Book3E support, but without CONFIG_PPC_E500MC enabled. Such a kernel
would never boot, it doesn't know about any CPUs.
To fix this, force CONFIG_PPC
CONFIG_PPC_BOOK3E_MMU is redundant with CONFIG_PPC_E500.
Remove it.
Also rename mmu-book3e.h to mmu-e500.h
Signed-off-by: Christophe Leroy
---
.../include/asm/nohash/{mmu-book3e.h => mmu-e500.h} | 0
arch/powerpc/include/asm/nohash/mmu.h | 4 ++--
arch/powerpc/kernel/
CONFIG_PPC_FSL_BOOK3E is redundant with CONFIG_PPC_E500.
Remove it.
And rename five files accordingly.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/include/asm/barrier.h | 2 +-
arch/powerpc/include/asm/hugetlb.h
CONFIG_PPC_BOOK3E_64 implies CONFIG_PPC_FSL_BOOK3E so no need of
additional #ifdefs in files built exclusively for CONFIG_PPC_BOOK3E_64.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/exceptions-64e.S | 8
arch/powerpc/mm/nohash/tlb_low_64e.S | 6 --
2 files changed, 14 del
e500v1/v2 and e500mc are said to be mutually exclusive in Kconfig.
Split e500 cpu_specs[] and then restrict the non e500mc to PPC32
which is then 85xx.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/cpu_specs.h | 6 +-
arch/powerpc/kernel/cpu_specs_85xx.h | 60 +
__machine_check_early_realmode_p{7/8/9} are already in mce.h
which is included. Remove them from cputable.c
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/cputable.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
ind
PPC_85xx implies PPC32 so no need to check PPC32 in addition.
PPC64 && !PPC_BOOK3E_64 means PPC_BOOK3S_64.
PPC_BOOK3E_64 implies PPC_E500.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +-
arch/powerpc/xmon/xmon.c
PPC_E500 is the same as PPC_85xx || PPC_BOOKE_64
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/platforms/85xx/Kconfig| 2 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/po
PPC_85xx is PPC32 only.
PPC_85xx always selects E500 and is the only PPC32 that
selects E500.
FSL_BOOKE is selected when E500 and PPC32 are selected.
So FSL_BOOKE is redundant with PPC_85xx.
Remove FSL_BOOKE.
And rename four files accordingly.
cpu_setup_fsl_booke.S is not renamed because it is
cpu_specs[] is full of #ifdefs depending on the different
types of CPU.
CPUs are mutually exclusive, it is therefore possible to split
cpu_specs[] into smaller more readable pieces.
Create cpu_specs_XXX.h that will each be dedicated on one
of the following mutually exclusive families:
- 40x
- 44x
PPC_85xx and PPC_BOOK3E_64 already select E500 so no need
to select it again by PPC_QEMU_E500 and CORENET_GENERIC
as they depend on PPC_85xx || PPC_BOOK3E_64.
PPC_BOOK3E_64 already selects E500MC so no need to
select it again by PPC_QEMU_E500 if PPC64, PPC_BOOK3E_64
is the only way into PPC_QEMU_E
CONFIG_PPC_FSL_BOOK3E is redundant with CONFIG_PPC_E500.
Rename it so that CONFIG_PPC_FSL_BOOK3E can be removed later.
Signed-off-by: Christophe Leroy
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
1 file changed, 1 insertion(+), 1
e500 idle setup is a bit messy.
e500_idle() is used for PPC32 while book3e_idle() is used for PPC64.
As they are mutually exclusive, call them all e500_idle().
Use CONFIG_MPC_85xx instead of PPC32 + E500 in Makefile and rename
idle_e500.c to idle_85xx.c .
Rename idle_book3e.c to idle_64e.c and r
It will be used outside arch/powerpc, make it clear its a
powerpc configuration item.
And we already have CONFIG_PPC_E500MC, so that will make
it more consistant.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Makefile | 2 +-
arch/powerpc/include/asm/cputable.h |
CONFIG_PPC_BOOK3E is redundant with CONFIG_PPC_BOOK3E_64.
The later is more explicit about the fact that it's a 64 bits target.
Remove CONFIG_PPC_BOOK3E.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/include/asm/cputable.h | 4 +--
a
Move all prototypes out of cputable.h
For that rename cpu_setup_power.h to cpu_setup.h and move all
prototypes in it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/cpu_setup.h | 49 ++
arch/powerpc/include/asm/cpu_setup_power.h | 12 --
arch/powerpc/
CONFIG_PPC_FSL_BOOK3E is redundant with CONFIG_PPC_E500.
Replace it so that CONFIG_PPC_FSL_BOOK3E can be removed later.
Signed-off-by: Christophe Leroy
Cc: Wim Van Sebroeck
Acked-by: Guenter Roeck
Cc: linux-watch...@vger.kernel.org
---
drivers/watchdog/Kconfig | 8
drivers/watchd
Today there is:
if e500 or 8xx
if e500
mmu_psize_defs[] =
else if 8xx
mmu_psize_defs[] =
else
mmu_psize_defs[] =
endif
endif
The else leg is dead definition.
Drop that else leg and rewrite as:
if e500
mmu_psize_defs[] =
endif
if 8xx
mmu_psize_
On Sat, Sep 17, 2022 at 06:31:20AM +, Christophe Leroy wrote:
>
>
> Le 16/09/2022 à 21:40, Omar Sandoval a écrit :
> > [Vous ne recevez pas souvent de courriers de osan...@osandov.com. D?couvrez
> > pourquoi ceci est important ? https://aka.ms/LearnAboutSenderIdentification
> > ]
> >
> > O
On Mon, Sep 19, 2022 at 10:26:17AM -0700, Omar Sandoval wrote:
In general if you're going to CC someone into a thread please put
a note at the start of your mail explaining why, many of us get
copied on a lot of irrelevant things for no apparently reason so
if it's not immediately obvious why we w
On Mon, Sep 19, 2022 at 06:33:40PM +0100, Mark Brown wrote:
> On Mon, Sep 19, 2022 at 10:26:17AM -0700, Omar Sandoval wrote:
>
> In general if you're going to CC someone into a thread please put
> a note at the start of your mail explaining why, many of us get
> copied on a lot of irrelevant thing
On Mon, Sep 19, 2022 at 10:40:36AM -0700, Omar Sandoval wrote:
> On Mon, Sep 19, 2022 at 06:33:40PM +0100, Mark Brown wrote:
> > I don't understand the question, what file are you talking about
> > here? arch/arm64/include/asm/assembler.h is itself a file and I
> > couldn't find anything nearby i
Hello:
This patch was applied to netdev/net-next.git (master)
by Jakub Kicinski :
On Fri, 9 Sep 2022 14:29:59 +0800 you wrote:
> fs_mii_disconnect and fs_mii_connect have been removed since
> commit 5b4b8454344a ("[PATCH] FS_ENET: use PAL for mii management"),
> so remove them.
>
> Signed-off-by
On Sun, Sep 18, 2022 at 08:44:27PM -0700, Olof Johansson wrote:
> On Tue, Aug 23, 2022 at 8:37 AM Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Jun 30, 2022 at 06:26:38PM -0700, Saravana Kannan wrote:
> > > These patches are on top of driver-core-next.
> > >
> > > Even if stdout-path isn't set in DT
Doing RCU-idle outside the driver, only to then temporarily enable it
again, at least twice, before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle-riscv-sbi.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/cpuidle/cpuidle-r
Doing RCU-idle outside the driver, only to then temporarily enable it
again, at least twice, before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle-psci.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/cpuidle/cpuidle-psci.c
Doing RCU-idle outside the driver, only to then temporarily enable it
again, at least twice, before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle-tegra.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
--- a/drivers/cpuidle/
cpuidle_state::enter() methods should be IRQ invariant
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Rafael J. Wysocki
---
drivers/cpuidle/poll_state.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/cpuidle/poll_state.c
+++ b/drivers/cpuidle/poll_state.c
@@ -17,
Doing RCU-idle outside the driver, only to then temporarily enable it
again before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle-mvebu-v7.c |7 +++
1 file changed, 7 insertions(+)
--- a/drivers/cpuidle/cpuidle-mvebu-v7.c
+++ b/drivers/cpuidle/cpui
Typical boot time setup; no need to suffer an indirect call for that.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Frederic Weisbecker
Reviewed-by: Rafael J. Wysocki
---
arch/x86/kernel/process.c | 50 +-
1 file changed, 28 insertions(+), 22
Doing RCU-idle outside the driver, only to then teporarily enable it
again before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Tony Lindgren
Tested-by: Tony Lindgren
---
arch/arm/mach-omap2/cpuidle34xx.c | 16
1 file changed, 16 insertions(+)
--- a
Doing RCU-idle outside the driver, only to then temporarily enable it
again, some *four* times, before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Tony Lindgren
Tested-by: Tony Lindgren
---
arch/arm/mach-omap2/cpuidle44xx.c | 29 ++---
1 fil
The __cpuidle functions will become a noinstr class, as such they need
explicit annotations.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Rafael J. Wysocki
---
drivers/cpuidle/poll_state.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/cpuidle/poll_state.c
++
All the idle routines are called with RCU disabled, as such there must
not be any tracing inside.
While there; clean-up the io-port idle thing.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/acpi/processor_idle.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions
The problem, per commit fc98c3c8c9dc ("printk: use rcuidle console
tracepoint"), was printk usage from the cpuidle path where RCU was
already disabled.
Per the patches earlier in this series, this is no longer the case.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Sergey Senozhatsky
Acked
Now that arch_cpu_idle() is expected to return with IRQs disabled,
avoid the useless STI/CLI dance.
Per the specs this is supposed to work, but nobody has yet relied up
this behaviour so broken implementations are possible.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/coco/tdx/tdcall.S
arch_cpu_idle() is a very simple idle interface and exposes only a
single idle state and is expected to not require RCU and not do any
tracing/instrumentation.
As such, omap2_pm_idle() is not a valid implementation. Replace it
with a simple (shallow) omap2_do_wfi() call.
Omap2 doesn't have a cpui
vmlinux.o: warning: objtool: __halt+0x2c: call to hcall_func.constprop.0()
leaves .noinstr.text section
vmlinux.o: warning: objtool: __halt+0x3f: call to __tdx_hypercall() leaves
.noinstr.text section
vmlinux.o: warning: objtool: __tdx_hypercall+0x66: call to
__tdx_hypercall_failed() leaves .noi
CONFIG_GENERIC_ENTRY disallows any and all tracing when RCU isn't
enabled.
XXX if s390 (the only other GENERIC_ENTRY user as of this writing)
isn't comfortable with this, we could switch to
HAVE_NOINSTR_VALIDATION which is x86_64 only atm.
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux
From: Tony Lindgren
OMAP4 uses full SoC suspend modes as idle states, as such it needs the
whole power-domain and clock-domain code from the idle path.
All that code is not suitable to run with RCU disabled, as such push
RCU-idle deeper still.
Signed-off-by: Tony Lindgren
Signed-off-by: Peter
OMAP was the one and only user.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/clk/clk.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -978,12 +978,12 @@ static void clk_core_disable(struct clk_
if (--core->enable_
vmlinux.o: warning: objtool: mwait_idle+0x5: call to
current_set_polling_and_test() leaves .noinstr.text section
vmlinux.o: warning: objtool: acpi_processor_ffh_cstate_enter+0xc5: call to
current_set_polling_and_test() leaves .noinstr.text section
vmlinux.o: warning: objtool: cpu_idle_poll.isra.0
vmlinux.o: warning: objtool: io_idle+0xc: call to __inb.isra.0() leaves
.noinstr.text section
vmlinux.o: warning: objtool: acpi_idle_enter+0xfe: call to num_online_cpus()
leaves .noinstr.text section
vmlinux.o: warning: objtool: acpi_idle_enter+0x115: call to
acpi_idle_fallback_to_c1.isra.0() le
OMAP was the one and only user.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm/mach-omap2/powerdomain.c | 10 +-
drivers/base/power/runtime.c | 24
2 files changed, 17 insertions(+), 17 deletions(-)
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch
The whole disable-RCU, enable-IRQS dance is very intricate since
changing IRQ state is traced, which depends on RCU.
Add two helpers for the cpuidle case that mirror the entry code.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm/mach-imx/cpuidle-imx6q.c|4 +--
arch/arm/mach-imx/cpui
Idle code is very like entry code in that RCU isn't available. As
such, add a little validation.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Geert Uytterhoeven
---
arch/alpha/kernel/vmlinux.lds.S |1 -
arch/arc/kernel/vmlinux.lds.S|1 -
arch/arm/include/asm/vmlinux.lds.
vmlinux.o: warning: objtool: in_entry_stack+0x9: call to
__this_cpu_preempt_check() leaves .noinstr.text section
vmlinux.o: warning: objtool: default_do_nmi+0x10: call to
__this_cpu_preempt_check() leaves .noinstr.text section
vmlinux.o: warning: objtool: fpu_idle_fpregs+0x41: call to
__this_cpu
vmlinux.o: warning: objtool: intel_idle_ibrs+0x17: call to spec_ctrl_current()
leaves .noinstr.text section
vmlinux.o: warning: objtool: intel_idle_ibrs+0x27: call to wrmsrl.constprop.0()
leaves .noinstr.text section
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/kernel/cpu/bugs.c |2 +
vmlinux.o: warning: objtool: intel_idle_s2idle+0x6e: call to
__monitor.constprop.0() leaves .noinstr.text section
vmlinux.o: warning: objtool: intel_idle_irq+0x8c: call to
__monitor.constprop.0() leaves .noinstr.text section
vmlinux.o: warning: objtool: intel_idle+0x73: call to __monitor.constpro
arch_cpu_idle() is a very simple idle interface and exposes only a
single idle state and is expected to not require RCU and not do any
tracing/instrumentation.
As such, omap_sram_idle() is not a valid implementation. Replace it
with the simple (shallow) omap3_do_wfi() call. Leaving the more
compli
Doing RCU-idle outside the driver, only to then temporarily enable it
again before going idle is daft.
Notably: this converts all dt_init_idle_driver() and
__CPU_PM_CPU_IDLE_ENTER() users for they are inextrably intertwined.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm/mach-omap2/cpuidle3
OMAP3 uses full SoC suspend modes as idle states, as such it needs the
whole power-domain and clock-domain code from the idle path.
All that code is not suitable to run with RCU disabled, as such push
RCU-idle deeper still.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Tony Lindgren
Tested
The PM notifiers should no longer be ran with RCU disabled (per the
previous patches), as such this hack is no longer required either.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/perf/arm_pmu.c | 11 +--
drivers/perf/riscv_pmu_sbi.c |8 +---
2 files changed, 2 inser
The perf_lopwr_cb() is called from the idle routines; there is no RCU
there, we must not enter tracing.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/events/amd/brs.c | 13 +
arch/x86/include/asm/perf_event.h |2 +-
2 files changed, 6 insertions(+), 9 deletions(-)
None of these functions should ever be ran with RCU disabled anymore.
Specifically, do_handle_IPI() is only called from handle_IPI() which
explicitly does irq_enter()/irq_exit() which ensures RCU is watching.
The problem with smp_cross_call() was, per commit 7c64cc0531fa ("arm: Use
_rcuidle for s
Doing RCU-idle outside the driver, only to then temporarily enable it
again, at least twice, before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm/mach-imx/cpuidle-imx6sx.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/arch/arm/mach-imx/cpuidle-imx6s
KASAN cannot just hijack the mem*() functions, it needs to emit
__asan_mem*() variants if it wants instrumentation (other sanitizers
already do this).
vmlinux.o: warning: objtool: sync_regs+0x24: call to memcpy() leaves
.noinstr.text section
vmlinux.o: warning: objtool: vc_switch_off_ist+0xbe: ca
Ever since commit d3afc7f12987 ("arm64: Allow IPIs to be handled as
normal interrupts") this function is called in regular IRQ context.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Mark Rutland
Acked-by: Marc Zyngier
---
arch/arm64/kernel/smp.c |4 ++--
1 file changed, 2 insertions(+),
vmlinux.o: warning: objtool: intel_idle_irq+0x10c: call to
trace_hardirqs_off() leaves .noinstr.text section
As per commit 32d4fd5751ea ("cpuidle,intel_idle: Fix
CPUIDLE_FLAG_IRQ_ENABLE"):
"must not have tracing in idle functions"
Clearly people can't read and tinker along until splat dissa
No callers left that have already disabled RCU.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Mark Rutland
---
kernel/time/tick-broadcast-hrtimer.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
--- a/kernel/time/tick-broadcast-hrtimer.c
+++ b/kernel/
Hi All!
At long last, a respin of the cpuidle vs rcu cleanup patches.
v1: https://lkml.kernel.org/r/20220608142723.103523...@infradead.org
These here patches clean up the mess that is cpuidle vs rcuidle.
At the end of the ride there's only on RCU_NONIDLE user left:
arch/arm64/kernel/suspend.
clang-14 allyesconfig gives:
vmlinux.o: warning: objtool: emulator_cmpxchg_emulated+0x705: call to
__ubsan_handle_load_invalid_value() with UACCESS enabled
vmlinux.o: warning: objtool: paging64_update_accessed_dirty_bits+0x39e: call to
__ubsan_handle_load_invalid_value() with UACCESS enabled
vml
vmlinux.o: warning: objtool: intel_idle_s2idle+0xd5: call to fpu_idle_fpregs()
leaves .noinstr.text section
vmlinux.o: warning: objtool: intel_idle_xstate+0x11: call to fpu_idle_fpregs()
leaves .noinstr.text section
vmlinux.o: warning: objtool: fpu_idle_fpregs+0x9: call to xfeatures_in_use()
lea
For testing purposes.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/idle/intel_idle.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -1787,6 +1787,9 @@ static bool __init intel_idle_verify_cst
return
Make cpuidle_enter_state() consistent with the s2idle variant and
verify ->enter() always returns with interrupts disabled.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/cpuidle/cpuidle.c
+++
Current arch_cpu_idle() is called with IRQs disabled, but will return
with IRQs enabled.
However, the very first thing the generic code does after calling
arch_cpu_idle() is raw_local_irq_disable(). This means that
architectures that can idle with IRQs disabled end up doing a
pointless 'enable-dis
On 19.09.22 12:00, Peter Zijlstra wrote:
vmlinux.o: warning: objtool: acpi_idle_enter_s2idle+0xde: call to wbinvd()
leaves .noinstr.text section
vmlinux.o: warning: objtool: default_idle+0x4: call to arch_safe_halt() leaves
.noinstr.text section
vmlinux.o: warning: objtool: xen_safe_halt+0xa: c
On Mon, Sep 19, 2022 at 3:47 PM Peter Zijlstra wrote:
>
> Doing RCU-idle outside the driver, only to then temporarily enable it
> again, at least twice, before going idle is daft.
>
> Signed-off-by: Peter Zijlstra (Intel)
Looks good to me.
For RISC-V cpuidle:
Reviewed-by: Anup Patel
Regards,
On Mon, Sep 19, 2022 at 11:59:42AM +0200, Peter Zijlstra wrote:
> cpuidle_state::enter() methods should be IRQ invariant
Got a bit confused with the invariant thing since the first chunck I
see in this patch is a conversion to an non-traceable local_irq_enable().
Maybe just add a short mention ab
On Mon, Sep 19, 2022 at 11:59:44AM +0200, Peter Zijlstra wrote:
> Doing RCU-idle outside the driver, only to then temporarily enable it
> again, at least twice, before going idle is daft.
>
> Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Frederic Weisbecker
On Mon, Sep 19, 2022 at 11:59:45AM +0200, Peter Zijlstra wrote:
> Doing RCU-idle outside the driver, only to then temporarily enable it
> again, at least twice, before going idle is daft.
>
> Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Frederic Weisbecker
On Mon, Sep 19, 2022 at 11:59:46AM +0200, Peter Zijlstra wrote:
> Doing RCU-idle outside the driver, only to then temporarily enable it
> again, at least twice, before going idle is daft.
>
> Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Frederic Weisbecker
On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote:
> Doing RCU-idle outside the driver, only to then temporarily enable it
> again, at least twice, before going idle is daft.
Hmm, what ends up calling RCU_IDLE() here? Also what about
cpu_do_idle()?
Thanks.
>
> Signed-off-by: Peter
> > Le 16/12/2019 à 10:50, Holger Brunck a écrit :
> >> From: Matteo Ghidoni
> >>
> >> The defconfig is synchronized and the missing MTD_PHYSMAP,
> DEVTMPFS
> >> and I2C MUX support are switched on.
> >>
> >> Additionally the I2C mux device is added to the DTS with its attached
> >> temperature se
On Mon, Sep 19, 2022 at 11:59:48AM +0200, Peter Zijlstra wrote:
> Doing RCU-idle outside the driver, only to then teporarily enable it
> again before going idle is daft.
That doesn't tell where those calls are.
Thanks.
On Mon, Sep 19, 2022 at 11:59:49AM +0200, Peter Zijlstra wrote:
> Doing RCU-idle outside the driver, only to then temporarily enable it
> again before going idle is daft.
Ah wait, now I see, that's cpu_pm_enter()/cpu_pm_exit() -> cpu_pm_notify*() the
culprits.
Might be worth adding a short note a
On Mon, Sep 19, 2022 at 11:59:48AM +0200, Peter Zijlstra wrote:
> Doing RCU-idle outside the driver, only to then teporarily enable it
> again before going idle is daft.
>
> Signed-off-by: Peter Zijlstra (Intel)
> Reviewed-by: Tony Lindgren
> Tested-by: Tony Lindgren
Ok now with the cpu_pm_*()
On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote:
> Doing RCU-idle outside the driver, only to then temporarily enable it
> again, at least twice, before going idle is daft.
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/arm/mach-imx/cpuidle-imx6sx.c |5 -
> 1 file
On Mon, Sep 19, 2022 at 04:21:23PM +0200, Frederic Weisbecker wrote:
> On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote:
> > Doing RCU-idle outside the driver, only to then temporarily enable it
> > again, at least twice, before going idle is daft.
>
> Hmm, what ends up calling RCU_I
On Mon, Sep 19, 2022 at 04:49:41PM +0200, Frederic Weisbecker wrote:
> On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote:
> > Doing RCU-idle outside the driver, only to then temporarily enable it
> > again, at least twice, before going idle is daft.
> >
> > Signed-off-by: Peter Zijlst
1 - 100 of 132 matches
Mail list logo
