On Wed, Mar 19 2025 at 10:28, Jiri Slaby wrote:
> Hi,
>
> tl;dr if patches are agreed upon, I ask subsys maintainers to take the
> respective ones via their trees (as they are split per subsys), so that
> the IRQ tree can take only the rest. That would minimize churn/conflicts
> during merges.
So
On Sat, Aug 24 2024 at 18:06, Wentao Zhang wrote:
The subject line is really not useful. What's 'odd' code?
> Disable instrumentation in the same areas that were disabled for
> kernel/gcov/
> Signed-off-by: Wentao Zhang
> Signed-off-by: Chuck Wolber
This Signed-off-by chain is broken. See Doc
On Sat, Aug 24 2024 at 18:06, Wentao Zhang wrote:
> Makefile | 3 +
> arch/Kconfig | 1 +
> arch/x86/Kconfig | 1 +
> arch/x86/kernel/vmlinux.lds.S | 2 +
> include/asm-generic/vmlinux.lds.h | 38 +
> kernel/Makefile
Herve!
On Fri, Jun 14 2024 at 19:32, Herve Codina wrote:
> During the review, it was asked to rework the irq domain modification in
> order to avoid more wrappers and a new irq_domain_instanciate() function
> was proposed [2].
>
> Also a patch [3] sent by Maitti Vaittinen can benefit of this new
>
On Wed, Mar 06 2024 at 15:14, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Naresh noticed that the newly added usage of the PAGE_SIZE macro in
> include/vdso/datapage.h introduced a build regression. I had an older
> patch that I revived to have this defined through Kconfig rather than
> through
n one and allow
> only the hardware page size to be selected.
>
> Acked-by: Guo Ren
> Acked-by: Heiko Carstens
> Acked-by: Stafford Horne
> Acked-by: Johannes Berg
> Signed-off-by: Arnd Bergmann
Reviewed-by: Thomas Gleixner
e
> leaving the arhcitecture specific ones as the user visible
> place for configuring it, to avoid breaking user configs.
>
> Reviewed-by: Christophe Leroy (powerpc32)
> Acked-by: Catalin Marinas
> Acked-by: Helge Deller # parisc
> Signed-off-by: Arnd Bergmann
Reviewed-by: Thomas Gleixner
off-by: Arnd Bergmann
Reviewed-by: Thomas Gleixner
On Tue, Sep 19 2023 at 10:25, Linus Torvalds wrote:
> PeterZ mentioned the generic entry code, which does this for the entry
> path. But it actually goes much deeper: just do a
>
> git grep preempt_disable arch/x86/kernel
>
> and then do the same for some other architectures.
>
> Looking at alp
On Tue, Sep 19 2023 at 11:52, Linus Torvalds wrote:
> On Tue, 19 Sept 2023 at 11:37, Steven Rostedt wrote:
>>
>> We could simply leave the cond_resched() around but defined as nops for
>> everything but the "nostalgia club" to keep them from having any regressions.
>
> I doubt the nostalgia club c
On Tue, Sep 19 2023 at 10:25, Linus Torvalds wrote:
> On Tue, 19 Sept 2023 at 06:48, John Paul Adrian Glaubitz
> wrote:
>>
>> As Geert poined out, I'm not seeing anything particular problematic with the
>> architectures lacking CONFIG_PREEMPT at the moment. This seems to be more
>> something about
On Tue, Sep 19 2023 at 17:41, Anton Ivanov wrote:
> On 19/09/2023 17:22, Richard Weinberger wrote:
>> - Ursprüngliche Mail -
>>> Von: "anton ivanov"
>>> It's been a while. I remember that I dropped it at the time, but do not
>>> remember
>>> the full details.
>>>
>>> There was some stuff
On Tue, Sep 19 2023 at 15:21, Anton Ivanov wrote:
> On 19/09/2023 14:42, Peter Zijlstra wrote:
>> If you're working on one of them, then surely it's a simple matter of
>> working on adding CONFIG_PREEMPT support :-)
>
> In the case of UML adding preempt will be quite difficult. I looked at
> this a
On Tue, Sep 19 2023 at 15:48, John Paul Adrian Glaubitz wrote:
> On Tue, 2023-09-19 at 15:42 +0200, Peter Zijlstra wrote:
>> > The agreement to kill off ia64 wasn't an invitation to kill off other stuff
>> > that people are still working on! Can we please not do this?
>>
>> If you're working on on
On Thu, Jun 15 2023 at 21:44, Rick P. Edgecombe wrote:
> On Wed, 2023-06-14 at 01:39 +0200, Thomas Gleixner wrote:
>> Fortunately none of the init calls between calibrate_delay() and
>> arch_cpu_finalize_init() is relevant for the functionality of
>> arch_cpu_finalize_init()
On Wed, Jun 14 2023 at 01:39, Thomas Gleixner wrote:
> + /*
> + * identify_boot_cpu() initialized SMT support information, let the
> + * core code know.
> + */
> + cpu_smt_check_topology();
> +
> + if (!IS_ENABLED(CONFIG_SMP)) {
> +
On Tue, Jun 13 2023 at 22:03, Chang S. Bae wrote:
> On 6/13/2023 4:39 PM, Thomas Gleixner wrote:
>>
>> @@ -2396,6 +2393,13 @@ void __init arch_cpu_finalize_init(void)
>> '0' + (boot_cpu_data.x86 > 6 ? 6 : boot_cpu_data.x86);
>>
initialization to arch_cpu_finalize_init() which is the perfect
place to do so.
No functional change.
This allows to remove quite some of the custom early command line parsing,
but that's subject to the next installment.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/common.c |
Invoke the X86ism mem_encrypt_init() from X86 arch_cpu_finalize_init() and
remove the weak fallback from the core code.
No functional change.
Signed-off-by: Thomas Gleixner
Cc: Tom Lendacky
---
arch/x86/include/asm/mem_encrypt.h |7 ---
arch/x86/kernel/cpu/common.c | 11
No point in keeping them around.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/fpu/init.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -53,7 +53,7 @@ void fpu__init_cpu(void)
fpu__init_cpu_xstate
arch_cpu_finalize_init() is relevant for the functionality of
arch_cpu_finalize_init().
Invoke it right after calibrate_delay() where everything which is relevant
for arch_cpu_finalize_init() has been set up already.
No functional change intended.
Signed-off-by: Thomas Gleixner
---
init/main.c |4
check_bugs() is about to be phased out. Switch over to the new
arch_cpu_finalize_init() implementation.
No functional change.
Signed-off-by: Thomas Gleixner
Cc: Richard Weinberger
Cc: Anton Ivanov
Cc: Johannes Berg
Cc: linux-um@lists.infradead.org
---
arch/um/Kconfig|1
Nothing in the call chain requires it
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/fpu/api.h |2 +-
arch/x86/kernel/cpu/common.c |2 +-
arch/x86/kernel/fpu/init.c |6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
--- a/arch/x86/include/asm/fpu/api.h
+++ b
No point in doing this during really early boot. Move it to an early
initcall so that it is set up before possible user mode helpers are started
during device initialization.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/sigframe.h |2 --
arch/x86/kernel/cpu/common.c|3
Everything is converted over to arch_cpu_finalize_init(). Remove the
check_bugs() leftovers including the empty stubs in asm-generic, alpha,
parisc, powerpc and xtensa.
Signed-off-by: Thomas Gleixner
Cc: Richard Henderson
Cc: "James E.J. Bottomley"
Cc: Michael Ellerman
Cc: Ch
check_bugs() is about to be phased out. Switch over to the new
arch_cpu_finalize_init() implementation.
No functional change.
Signed-off-by: Thomas Gleixner
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: John Paul Adrian Glaubitz
Cc: linux...@vger.kernel.org
---
arch/sh/Kconfig
check_bugs() is about to be phased out. Switch over to the new
arch_cpu_finalize_init() implementation.
No functional change.
Signed-off-by: Thomas Gleixner
Cc: Thomas Bogendoerfer
Cc: linux-m...@vger.kernel.org
---
arch/mips/Kconfig|1 +
arch/mips/include/asm/bugs.h | 17
check_bugs() is about to be phased out. Switch over to the new
arch_cpu_finalize_init() implementation.
No functional change.
Signed-off-by: Thomas Gleixner
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
---
arch/sparc/Kconfig|1 +
arch/sparc/include/asm/bug
check_bugs() is about to be phased out. Switch over to the new
arch_cpu_finalize_init() implementation.
No functional change.
Signed-off-by: Thomas Gleixner
Cc: Geert Uytterhoeven
Cc: linux-m...@lists.linux-m68k.org
---
arch/m68k/Kconfig|1 +
arch/m68k/include/asm/bugs.h
check_bugs() is about to be phased out. Switch over to the new
arch_cpu_finalize_init() implementation.
No functional change.
Signed-off-by: Thomas Gleixner
Cc: Huacai Chen
Cc: WANG Xuerui
Cc: loonga...@lists.linux.dev
---
arch/loongarch/Kconfig|1 +
arch/loongarch/include
check_bugs() is about to be phased out. Switch over to the new
arch_cpu_finalize_init() implementation.
No functional change.
Signed-off-by: Thomas Gleixner
Cc: linux-i...@vger.kernel.org
---
arch/ia64/Kconfig|1 +
arch/ia64/include/asm/bugs.h | 20
arch
check_bugs() is a dump ground for finalizing the CPU bringup. Only parts of
it has to do with actual CPU bugs.
Split it apart into arch_cpu_finalize_init() and cpu_select_mitigations().
Fixup the bogus 32bit comments while at it.
No functional change.
Signed-off-by: Thomas Gleixner
---
arch
Hi!
My team and myself are working on sanitizing the x86 boot process,
especially the complete horror show of CPUID evaluation, which is
constructed with hay-wire circuits, duct tape and superglue.
A related goal is to move the initialization of infrastructure which is not
required during early b
start_kernel() which will be removed
along with check_bugs() once the architectures are converted over.
Signed-off-by: Thomas Gleixner
---
arch/Kconfig|3 +++
include/linux/cpu.h |6 ++
init/main.c |4
3 files changed, 13 insertions(+)
--- a/arch/Kconfig
+++ b/arch
check_bugs() is about to be phased out. Switch over to the new
arch_cpu_finalize_init() implementation.
No functional change.
Signed-off-by: Thomas Gleixner
Cc: Russell King
Cc: Arnd Bergmann
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/Kconfig|1 +
arch/arm/include
On Tue, Apr 12 2022 at 19:27, Jason A. Donenfeld wrote:
> +/**
> + * random_get_entropy_fallback - Returns the raw clock source value,
> + * used by random.c for platforms with no valid random_get_entropy().
> + */
> +unsigned long random_get_entropy_fallback(void)
> +{
> + return tk_clock_read
cause that always needs to return _something_, even falling back to
> jiffies eventually. It's not as though ktime_read_raw_clock() is super
> high precision or guaranteed to be entropic, but basically anything
> that's not zero all the time is better than returning zero all the
Jason,
On Sun, Apr 10 2022 at 16:25, Jason A. Donenfeld wrote:
> On Sun, Apr 10, 2022 at 01:29:32AM +0200, Thomas Gleixner wrote:
>> But the below uncompiled hack gives you access to the 'best' clocksource
>> of a machine, i.e. the one which the platform decided to be t
Jason,
On Fri, Apr 08 2022 at 20:21, Jason A. Donenfeld wrote:
> Sometimes the next best thing is architecture-defined. For example,
> really old MIPS has the CP0 random register, which isn't a cycle
> counter, but is at least something. However, some platforms don't even
> have an architecture-de
On Mon, Apr 04 2022 at 10:37, Johannes Berg wrote:
> On Mon, 2022-04-04 at 10:32 +0200, Thomas Gleixner wrote:
>> --- a/kernel/time/timer.c
>> +++ b/kernel/time/timer.c
>> @@ -1724,9 +1724,8 @@ static inline void __run_timers(struct t
>> /*
>>
On Mon, Apr 04 2022 at 09:02, Johannes Berg wrote:
> On Sun, 2022-04-03 at 21:51 +0200, Thomas Gleixner wrote:
>> but that's fine and it is overwritten by every timer which is inserted
>> to expire before that. So that's not an issue as the prandom timer is
>> firing
Johannes,
On Sun, Apr 03 2022 at 19:19, Johannes Berg wrote:
> Actually, in a sense, this *is* the case of (just) recalculating
> next_expiry, no? We just never set next_expiry_recalc since there was
> never any timer on this?
why are you insisting on fishing in the dark?
> So actually this als
On Sun, Apr 03 2022 at 19:13, Johannes Berg wrote:
> On Sun, 2022-04-03 at 18:18 +0200, Thomas Gleixner wrote:
>> On Sat, Apr 02 2022 at 16:09, Johannes Berg wrote:
> There was no timer. If there's ever a timer on this base (BASE_DEF) then
> this doesn't happen.
You sai
On Sat, Apr 02 2022 at 16:09, Johannes Berg wrote:
> At init, we get
>
> init_timer_cpu(0) base 0 clk=0x8ad0, next_expiry=0x13fff8acf
> init_timer_cpu(0) base 1 clk=0x8ad0, next_expiry=0x13fff8acf
>
> which makes sense, jiffies is set up to wrap very quickly after boot.
>
> The warning trig
44 matches
Mail list logo
