Message ID | CACRpkdZCiiMTwf7eGJJ9aCKFOC3_xTGv1JKQUijjyp+_++cZ_A@mail.gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [GIT,PULL] Generic entry for ARM | expand |
On Fri, Feb 28 2025 at 13:49, Linus Walleij wrote: > please consider pulling the following git branch for generic entry, > see below. > > This branch was just harvested from my own v5 patch series on > lore with b4 am -t 20250225-arm-generic-entry-v5-0-2f02313653e5@linaro.org > then git am on top of v6.14-rc1, so you can do the same if you > prefer. > > It's possible to squash patches, even all of them into one > big all-or-nothing patch, given the not very gradual nature generic > entry conversion seems to have. > > Main upsides and downsides are in the signed tag. > > I don't know who the most important stakeholders are, but I guess > the context tracker maintainer (Paul McKenney) and the people working > on generic entry (tglx) could have a say on how important this is, or isn't. > > I think it's pretty neat. It's valuable to consolidate these common functionalities across architectures as it reduces maintainence costs. I read through the patches and did not find anything offending there. Thanks for doing that! Acked-by: Thomas Gleixner <tglx@linutronix.de>
On Fri, Feb 28, 2025 at 01:49:36PM +0100, Linus Walleij wrote: > Hi Russell, > > please consider pulling the following git branch for generic entry, > see below. > > This branch was just harvested from my own v5 patch series on > lore with b4 am -t 20250225-arm-generic-entry-v5-0-2f02313653e5@linaro.org > then git am on top of v6.14-rc1, so you can do the same if you > prefer. > > It's possible to squash patches, even all of them into one > big all-or-nothing patch, given the not very gradual nature generic > entry conversion seems to have. > > Main upsides and downsides are in the signed tag. > > I don't know who the most important stakeholders are, but I guess > the context tracker maintainer (Paul McKenney) and the people working > on generic entry (tglx) could have a say on how important this is, or isn't. > > I think it's pretty neat. No argument here! Once you are confident that you have all the needed "noinstr" and "__always_inline" instances in place, could you please add ARCH_WANTS_NO_INSTR to the list of "select" clauses for "config ARM" in arch/arm/Kconfig? Once all architectures that support trampoline-based tracing also select ARCH_WANTS_NO_INSTR we can drop RCU Tasks Rude. ;-) In the meantime, for the series: Acked-by: Paul E. McKenney <paulmck@kernel.org> Thanx, Paul > Yours, > Linus Walleij > > The following changes since commit 2014c95afecee3e76ca4a56956a936e23283f05b: > > Linux 6.14-rc1 (2025-02-02 15:39:26 -0800) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git > tags/arm-generic-entry-for-v6.15 > > for you to fetch changes up to 98b8e133458a3feefdf882ea16fb7f1f576a49e5: > > ARM: entry: Reimplement local restart in C (2025-02-28 13:40:44 +0100) > > ---------------------------------------------------------------- > Main upsides: > > - Using the same common entry as used by x86_64, RISCV, S390 > and Loongarch, probably soon also ARM64. > > - Moves ARM away from the obsoleted context tracker entry points > user_enter_callable() and user_exit_callable() are now only used > by ARM, CSKY and Xtensa. > > - Solves a few lockdep warnings in the process. > > - Converts a bit of assembly into C. > > Main downside: > > - Slightly increased system call overhead, around 6% in > measurements. > > ---------------------------------------------------------------- > Linus Walleij (31): > ARM: Prepare includes for generic entry > ARM: ptrace: Split report_syscall() > ARM: entry: Skip ret_slow_syscall label > ARM: process: Rewrite ret_from_fork i C > ARM: process: Remove local restart > ARM: entry: Invoke syscalls using C > ARM: entry: Rewrite two asm calls in C > ARM: entry: Move trace entry to C function > ARM: entry: save the syscall sp in thread_info > ARM: entry: move all tracing invocation to C > ARM: entry: Merge the common and trace entry code > ARM: entry: Rename syscall invocation > ARM: entry: Create user_mode_enter/exit > ARM: entry: Drop trace argument from usr_entry macro > ARM: entry: Separate call path for syscall SWI entry > ARM: entry: Drop argument to asm_irqentry macros > ARM: entry: Implement syscall_exit_to_user_mode() > ARM: entry: Drop the superfast ret_fast_syscall > ARM: entry: Remove fast and offset register restore > ARM: entry: Untangle ret_fast_syscall/to_user > ARM: entry: Do not double-call exit functions > ARM: entry: Move work processing to C > ARM: entry: Stop exiting syscalls like IRQs > ARM: entry: Complete syscall and IRQ transition to C > ARM: entry: Create irqentry calls from kernel mode > ARM: entry: Move in-kernel hardirq tracing to C > ARM: irq: Add irqstack helper > ARM: entry: Convert to generic entry > ARM: entry: Handle dabt, pabt, and und as interrupts > ARM: entry: Block IRQs in early IRQ context > ARM: entry: Reimplement local restart in C > > arch/arm/Kconfig | 1 + > arch/arm/include/asm/entry-common.h | 66 ++++++++++++ > arch/arm/include/asm/entry.h | 14 +++ > arch/arm/include/asm/ptrace.h | 8 +- > arch/arm/include/asm/signal.h | 4 - > arch/arm/include/asm/stacktrace.h | 2 +- > arch/arm/include/asm/switch_to.h | 4 + > arch/arm/include/asm/syscall.h | 7 ++ > arch/arm/include/asm/thread_info.h | 22 ++-- > arch/arm/include/asm/traps.h | 5 +- > arch/arm/include/uapi/asm/ptrace.h | 2 + > arch/arm/kernel/Makefile | 5 +- > arch/arm/kernel/asm-offsets.c | 1 + > arch/arm/kernel/entry-armv.S | 82 ++++----------- > arch/arm/kernel/entry-common.S | 198 +++++++++++++----------------------- > arch/arm/kernel/entry-header.S | 100 ++---------------- > arch/arm/kernel/entry.c | 120 ++++++++++++++++++++++ > arch/arm/kernel/irq.c | 6 ++ > arch/arm/kernel/irq.h | 2 + > arch/arm/kernel/process.c | 25 ++++- > arch/arm/kernel/ptrace.c | 81 +-------------- > arch/arm/kernel/signal.c | 68 +++---------- > arch/arm/kernel/syscall.c | 59 +++++++++++ > arch/arm/kernel/traps.c | 30 +----- > arch/arm/mm/abort-ev4.S | 2 +- > arch/arm/mm/abort-ev4t.S | 2 +- > arch/arm/mm/abort-ev5t.S | 4 +- > arch/arm/mm/abort-ev5tj.S | 6 +- > arch/arm/mm/abort-ev6.S | 2 +- > arch/arm/mm/abort-ev7.S | 2 +- > arch/arm/mm/abort-lv4t.S | 36 +++---- > arch/arm/mm/abort-macro.S | 2 +- > arch/arm/mm/abort-nommu.S | 2 +- > arch/arm/mm/fault.c | 4 +- > arch/arm/mm/fault.h | 8 +- > arch/arm/mm/pabort-legacy.S | 2 +- > arch/arm/mm/pabort-v6.S | 2 +- > arch/arm/mm/pabort-v7.S | 2 +- > 38 files changed, 484 insertions(+), 504 deletions(-) > create mode 100644 arch/arm/include/asm/entry-common.h > create mode 100644 arch/arm/include/asm/entry.h > create mode 100644 arch/arm/kernel/entry.c > create mode 100644 arch/arm/kernel/irq.h > create mode 100644 arch/arm/kernel/syscall.c
On Wed, Mar 12, 2025 at 7:00 PM Paul E. McKenney <paulmck@kernel.org> wrote: > Once you are confident that you have all the needed "noinstr" > and "__always_inline" instances in place, could you please add > ARCH_WANTS_NO_INSTR to the list of "select" clauses for "config ARM" > in arch/arm/Kconfig? I would love to do that, I'm just not sure what this really entails. Surely this patchset tags a noinstr on every entry point from exceptions and syscall software interrupts. Documentation/core-api/entry.rst is pretty good at explaining this. But what makes me uncertain are things that are tagged "notrace", such as void notrace cpu_init(void) - surely we don't trace, but should that be "noinstr"? It's even marked "notrace" but not "noinstr" in arm64. cpu_init() is called from e.g.: asmlinkage void secondary_start_kernel(struct task_struct *task) OK should this also be noinstr? Or is that just implied because of asmlinkage? <linux/compiler_types.h> will resolve to: #if defined(CC_USING_HOTPATCH) #define notrace __attribute__((hotpatch(0, 0))) #elif defined(CC_USING_PATCHABLE_FUNCTION_ENTRY) #define notrace __attribute__((patchable_function_entry(0, 0))) #else #define notrace __attribute__((__no_instrument_function__)) #endif which I read as three different ways of saying "don't patch here". Which is confusingly similar or identical to what noinstr does, I do see that noinstr pushes the code to separate section but that in turn might be what __attribute__((__no_instrument_function__)) and friends does? Are they equivalent? sched_clock_noinstr() is tagged noinstr and sched_clock() is tagged notrace, so there must be a difference here. secondary_start_kernel() is tagged "notrace" on arm64 but not on arm, should it be tagged "noinstr" or "notrace"? This kind of stuff makes me uncertain about how this is to be done. A "noinstr vs notrace" section in Documentation/core-api/entry.rst would help a lot I think! Yours, Linus Walleij