* [ANNOUNCE] 5.10.162-rt78 @ 2023-01-16 13:35 Luis Claudio R. Goncalves 2023-01-19 8:32 ` Vignesh Raghavendra 0 siblings, 1 reply; 20+ messages in thread From: Luis Claudio R. Goncalves @ 2023-01-16 13:35 UTC (permalink / raw) To: LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Pavel Machek, Jeff Brady, Salvatore Bonaccorso, Luis Goncalves Hello RT-list! I'm pleased to announce the 5.10.162-rt78 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v5.10-rt Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 Or to build 5.10.162-rt78 directly, the following patches should be applied: https://www.kernel.org/pub/linux/kernel/v5.x/linux-5.10.tar.xz https://www.kernel.org/pub/linux/kernel/v5.x/patch-5.10.162.xz https://www.kernel.org/pub/linux/kernel/projects/rt/5.10/older/patch-5.10.162-rt78.patch.xz Signing key fingerprint: 9354 0649 9972 8D31 D464 D140 F394 A423 F8E6 7C26 All keys used for the above files and repositories can be found on the following git repository: git://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git Enjoy! Luis ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-16 13:35 [ANNOUNCE] 5.10.162-rt78 Luis Claudio R. Goncalves @ 2023-01-19 8:32 ` Vignesh Raghavendra 2023-01-19 11:38 ` Pavel Machek 0 siblings, 1 reply; 20+ messages in thread From: Vignesh Raghavendra @ 2023-01-19 8:32 UTC (permalink / raw) To: Luis Claudio R. Goncalves, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Pavel Machek, Jeff Brady, Salvatore Bonaccorso Hi Luis, On 16/01/23 19:05, Luis Claudio R. Goncalves wrote: > Hello RT-list! > > I'm pleased to announce the 5.10.162-rt78 stable release. > > You can get this release via the git tree at: > > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > > branch: v5.10-rt > Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 > > Or to build 5.10.162-rt78 directly, the following patches should be applied: > > https://www.kernel.org/pub/linux/kernel/v5.x/linux-5.10.tar.xz > > https://www.kernel.org/pub/linux/kernel/v5.x/patch-5.10.162.xz > > https://www.kernel.org/pub/linux/kernel/projects/rt/5.10/older/patch-5.10.162-rt78.patch.xz > > Signing key fingerprint: > > 9354 0649 9972 8D31 D464 D140 F394 A423 F8E6 7C26 > > All keys used for the above files and repositories can be found on the > following git repository: > > git://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git > > Enjoy! > Luis > > I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] Any pointers on what maybe wrong? [0] arch/arm64/kernel/entry.S: Assembler messages: arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 make: *** [Makefile:1837: arch/arm64] Error 2 [1] 143ef105f40a ~/work/lcpd_kernel:v5.10.162-rt78 ✓ aarch64-none-linux-gnu-gcc --version aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 10.3-2021.07 (arm-10.29)) 10.3.1 20210621 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. {13:21:32}143ef105f40a ~/work/linux_kernel:v5.10.162-rt78 ✓ make defconfig ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/confdata.o HOSTCC scripts/kconfig/expr.o LEX scripts/kconfig/lexer.lex.c YACC scripts/kconfig/parser.tab.[ch] HOSTCC scripts/kconfig/lexer.lex.o HOSTCC scripts/kconfig/parser.tab.o HOSTCC scripts/kconfig/preprocess.o HOSTCC scripts/kconfig/symbol.o HOSTCC scripts/kconfig/util.o HOSTLD scripts/kconfig/conf *** Default configuration is based on 'defconfig' # # configuration written to .config # {13:21:39}143ef105f40a ~/work/linux_kernel/:v5.10.162-rt78 ✓ make ARCH=arm64 CROSS_COMPILE=aarch64-none-linux-gnu- HOSTCC scripts/dtc/dtc.o HOSTCC scripts/dtc/flattree.o HOSTCC scripts/dtc/fstree.o HOSTCC scripts/dtc/data.o HOSTCC scripts/dtc/livetree.o HOSTCC scripts/dtc/treesource.o HOSTCC scripts/dtc/srcpos.o HOSTCC scripts/dtc/checks.o HOSTCC scripts/dtc/util.o LEX scripts/dtc/dtc-lexer.lex.c YACC scripts/dtc/dtc-parser.tab.[ch] HOSTCC scripts/dtc/dtc-lexer.lex.o HOSTCC scripts/dtc/dtc-parser.tab.o HOSTCC scripts/dtc/yamltree.o HOSTLD scripts/dtc/dtc HOSTCC scripts/kallsyms HOSTCC scripts/sorttable HOSTCC scripts/asn1_compiler HOSTCC scripts/extract-cert WRAP arch/arm64/include/generated/uapi/asm/kvm_para.h WRAP arch/arm64/include/generated/uapi/asm/errno.h WRAP arch/arm64/include/generated/uapi/asm/ioctl.h WRAP arch/arm64/include/generated/uapi/asm/ioctls.h WRAP arch/arm64/include/generated/uapi/asm/ipcbuf.h WRAP arch/arm64/include/generated/uapi/asm/msgbuf.h WRAP arch/arm64/include/generated/uapi/asm/poll.h WRAP arch/arm64/include/generated/uapi/asm/resource.h WRAP arch/arm64/include/generated/uapi/asm/sembuf.h WRAP arch/arm64/include/generated/uapi/asm/shmbuf.h WRAP arch/arm64/include/generated/uapi/asm/siginfo.h WRAP arch/arm64/include/generated/uapi/asm/socket.h WRAP arch/arm64/include/generated/uapi/asm/sockios.h WRAP arch/arm64/include/generated/uapi/asm/stat.h WRAP arch/arm64/include/generated/uapi/asm/swab.h WRAP arch/arm64/include/generated/uapi/asm/termbits.h WRAP arch/arm64/include/generated/uapi/asm/termios.h WRAP arch/arm64/include/generated/uapi/asm/types.h WRAP arch/arm64/include/generated/asm/early_ioremap.h WRAP arch/arm64/include/generated/asm/mcs_spinlock.h WRAP arch/arm64/include/generated/asm/qrwlock.h WRAP arch/arm64/include/generated/asm/qspinlock.h WRAP arch/arm64/include/generated/asm/set_memory.h WRAP arch/arm64/include/generated/asm/user.h WRAP arch/arm64/include/generated/asm/bugs.h WRAP arch/arm64/include/generated/asm/delay.h WRAP arch/arm64/include/generated/asm/div64.h WRAP arch/arm64/include/generated/asm/dma-mapping.h WRAP arch/arm64/include/generated/asm/dma.h WRAP arch/arm64/include/generated/asm/emergency-restart.h WRAP arch/arm64/include/generated/asm/hw_irq.h WRAP arch/arm64/include/generated/asm/irq_regs.h WRAP arch/arm64/include/generated/asm/kdebug.h WRAP arch/arm64/include/generated/asm/kmap_size.h WRAP arch/arm64/include/generated/asm/local.h WRAP arch/arm64/include/generated/asm/local64.h WRAP arch/arm64/include/generated/asm/mm-arch-hooks.h WRAP arch/arm64/include/generated/asm/mmiowb.h WRAP arch/arm64/include/generated/asm/msi.h WRAP arch/arm64/include/generated/asm/rwonce.h WRAP arch/arm64/include/generated/asm/serial.h WRAP arch/arm64/include/generated/asm/switch_to.h WRAP arch/arm64/include/generated/asm/trace_clock.h WRAP arch/arm64/include/generated/asm/unaligned.h WRAP arch/arm64/include/generated/asm/vga.h UPD include/config/kernel.release UPD include/generated/uapi/linux/version.h UPD include/generated/utsrelease.h CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/modpost.o CC scripts/mod/devicetable-offsets.s UPD scripts/mod/devicetable-offsets.h HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/sumversion.o HOSTLD scripts/mod/modpost CC kernel/bounds.s UPD include/generated/bounds.h UPD include/generated/timeconst.h CC arch/arm64/kernel/asm-offsets.s UPD include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CALL scripts/atomic/check-atomics.sh LDS arch/arm64/kernel/vdso/vdso.lds CC arch/arm64/kernel/vdso/vgettimeofday.o AS arch/arm64/kernel/vdso/note.o AS arch/arm64/kernel/vdso/sigreturn.o LD arch/arm64/kernel/vdso/vdso.so.dbg VDSOSYM include/generated/vdso-offsets.h CC init/main.o CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o CC init/do_mounts.o CC init/do_mounts_initrd.o CC init/initramfs.o CC init/calibrate.o CC init/init_task.o AR init/built-in.a HOSTCC usr/gen_init_cpio GEN usr/initramfs_data.cpio SHIPPED usr/initramfs_inc_data AS usr/initramfs_data.o AR usr/built-in.a OBJCOPY arch/arm64/kernel/vdso/vdso.so AS arch/arm64/kernel/vdso/vdso.o AR arch/arm64/kernel/vdso/built-in.a AR arch/arm64/kernel/probes/built-in.a AS arch/arm64/kernel/head.o LDS arch/arm64/kernel/vmlinux.lds CC arch/arm64/kernel/debug-monitors.o AS arch/arm64/kernel/entry.o arch/arm64/kernel/entry.S: Assembler messages: arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 make: *** [Makefile:1837: arch/arm64] Error 2 -- Regards Vignesh ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-19 8:32 ` Vignesh Raghavendra @ 2023-01-19 11:38 ` Pavel Machek 2023-01-19 12:37 ` Pavel Machek 2023-01-19 13:16 ` Luis Claudio R. Goncalves 0 siblings, 2 replies; 20+ messages in thread From: Pavel Machek @ 2023-01-19 11:38 UTC (permalink / raw) To: Vignesh Raghavendra Cc: Luis Claudio R. Goncalves, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Pavel Machek, Jeff Brady, Salvatore Bonaccorso [-- Attachment #1: Type: text/plain, Size: 1327 bytes --] Hi! > > I'm pleased to announce the 5.10.162-rt78 stable release. > > > > You can get this release via the git tree at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > > > > branch: v5.10-rt > > Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 > > > > Or to build 5.10.162-rt78 directly, the following patches should be applied: > I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] > Any pointers on what maybe wrong? We see the same failure. > AS arch/arm64/kernel/entry.o > arch/arm64/kernel/entry.S: Assembler messages: > arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' > make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 > make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 > make: *** [Makefile:1837: arch/arm64] Error 2 The line is: > and x2, x19, #_TIF_WORK_MASK And I believe there were some cleanups in stable in that area. Let me search for them. Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-19 11:38 ` Pavel Machek @ 2023-01-19 12:37 ` Pavel Machek 2023-01-19 13:16 ` Luis Claudio R. Goncalves 1 sibling, 0 replies; 20+ messages in thread From: Pavel Machek @ 2023-01-19 12:37 UTC (permalink / raw) To: Pavel Machek Cc: Vignesh Raghavendra, Luis Claudio R. Goncalves, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady, Salvatore Bonaccorso [-- Attachment #1: Type: text/plain, Size: 1478 bytes --] Hi! > > > I'm pleased to announce the 5.10.162-rt78 stable release. > > > > > > You can get this release via the git tree at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > > > > > > branch: v5.10-rt > > > Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 > > > > > > Or to build 5.10.162-rt78 directly, the following patches should be applied: > > > I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] > > Any pointers on what maybe wrong? > > We see the same failure. > > > AS arch/arm64/kernel/entry.o > > arch/arm64/kernel/entry.S: Assembler messages: > > arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' > > make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 > > make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 > > make: *** [Makefile:1837: arch/arm64] Error 2 > > The line is: > > > and x2, x19, #_TIF_WORK_MASK > > And I believe there were some cleanups in stable in that area. Let me > search for them. Commit 1bee9dbbcabbb77617fb257f964628b50ba2529c is related, but does not revert cleanly. Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-19 11:38 ` Pavel Machek 2023-01-19 12:37 ` Pavel Machek @ 2023-01-19 13:16 ` Luis Claudio R. Goncalves 2023-01-19 21:03 ` Salvatore Bonaccorso 1 sibling, 1 reply; 20+ messages in thread From: Luis Claudio R. Goncalves @ 2023-01-19 13:16 UTC (permalink / raw) To: Pavel Machek Cc: Vignesh Raghavendra, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady, Salvatore Bonaccorso [-- Attachment #1: Type: text/plain, Size: 2636 bytes --] On Thu, Jan 19, 2023 at 12:38:25PM +0100, Pavel Machek wrote: > Hi! > > > > I'm pleased to announce the 5.10.162-rt78 stable release. > > > > > > You can get this release via the git tree at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > > > > > > branch: v5.10-rt > > > Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 > > > > > > Or to build 5.10.162-rt78 directly, the following patches should be applied: > > > I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] > > Any pointers on what maybe wrong? > > We see the same failure. > > > AS arch/arm64/kernel/entry.o > > arch/arm64/kernel/entry.S: Assembler messages: > > arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' > > make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 > > make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 > > make: *** [Makefile:1837: arch/arm64] Error 2 > > The line is: > > > and x2, x19, #_TIF_WORK_MASK I believe this is related to the arch/arm64/include/asm/thread_info.h changes in 5.10.162-rt78, specifically: 79a9991e87fe arm64: add support for TIF_NOTIFY_SIGNAL 1ba44dcf789d Merge tag 'v5.10.162' into v5.10-rt The first one is the original change, coming from stable v5.10.162 and the second one has the merge conflict I fixed in that file due to the existence of TIF_NEED_RESCHED_LAZY in PREEMPT_RT. It escaped me that having TIF_NEED_RESCHED_LAZY set to 13 breaks the AND statement reported above. Looking at b5a5a01d8e9a arm64: uaccess: remove addr_limit_user_check() specially this note To ensure that _TIF_WORK_MASK can be used as an immediate value in an AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. I understand that I need to either have to renumber TIF_NEED_RESCHED_LAZY to 8, with the risk of breaking something else, or backport commit b5a5a01d8e9a in order to remove TIF_FSCHECK and then safely renumber TIF_NEED_RESCHED_LAZY. Guidance is welcome here :) Best regards, Luis > And I believe there were some cleanups in stable in that area. Let me > search for them. > > Best regards, > Pavel > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ---end quoted text--- [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-19 13:16 ` Luis Claudio R. Goncalves @ 2023-01-19 21:03 ` Salvatore Bonaccorso 2023-01-19 23:09 ` Jens Axboe 0 siblings, 1 reply; 20+ messages in thread From: Salvatore Bonaccorso @ 2023-01-19 21:03 UTC (permalink / raw) To: Luis Claudio R. Goncalves Cc: Pavel Machek, Vignesh Raghavendra, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady, Jens Axboe Hi Luis, all, On Thu, Jan 19, 2023 at 10:16:34AM -0300, Luis Claudio R. Goncalves wrote: > On Thu, Jan 19, 2023 at 12:38:25PM +0100, Pavel Machek wrote: > > Hi! > > > > > > I'm pleased to announce the 5.10.162-rt78 stable release. > > > > > > > > You can get this release via the git tree at: > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > > > > > > > > branch: v5.10-rt > > > > Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 > > > > > > > > Or to build 5.10.162-rt78 directly, the following patches should be applied: > > > > > I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] > > > Any pointers on what maybe wrong? > > > > We see the same failure. > > > > > AS arch/arm64/kernel/entry.o > > > arch/arm64/kernel/entry.S: Assembler messages: > > > arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' > > > make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 > > > make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 > > > make: *** [Makefile:1837: arch/arm64] Error 2 > > > > The line is: > > > > > and x2, x19, #_TIF_WORK_MASK > > I believe this is related to the arch/arm64/include/asm/thread_info.h > changes in 5.10.162-rt78, specifically: > > 79a9991e87fe arm64: add support for TIF_NOTIFY_SIGNAL > 1ba44dcf789d Merge tag 'v5.10.162' into v5.10-rt > > The first one is the original change, coming from stable v5.10.162 and the > second one has the merge conflict I fixed in that file due to the existence > of TIF_NEED_RESCHED_LAZY in PREEMPT_RT. > > It escaped me that having TIF_NEED_RESCHED_LAZY set to 13 breaks the AND > statement reported above. Looking at > > b5a5a01d8e9a arm64: uaccess: remove addr_limit_user_check() > > specially this note > > To ensure that _TIF_WORK_MASK can be used as an immediate value in an > AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is > renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. > > I understand that I need to either have to renumber TIF_NEED_RESCHED_LAZY > to 8, with the risk of breaking something else, or backport commit > b5a5a01d8e9a in order to remove TIF_FSCHECK and then safely renumber > TIF_NEED_RESCHED_LAZY. > > Guidance is welcome here :) Should we loop in here Jens, as having some overview of the needed changes for io_uring rebase in the 5.10.y version? (doing so in the mail). Regards, Salvatore ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-19 21:03 ` Salvatore Bonaccorso @ 2023-01-19 23:09 ` Jens Axboe 2023-01-20 3:44 ` Luis Claudio R. Goncalves 2023-01-20 6:01 ` Mike Galbraith 0 siblings, 2 replies; 20+ messages in thread From: Jens Axboe @ 2023-01-19 23:09 UTC (permalink / raw) To: Salvatore Bonaccorso, Luis Claudio R. Goncalves Cc: Pavel Machek, Vignesh Raghavendra, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady On 1/19/23 2:03?PM, Salvatore Bonaccorso wrote: > Hi Luis, all, > > On Thu, Jan 19, 2023 at 10:16:34AM -0300, Luis Claudio R. Goncalves wrote: >> On Thu, Jan 19, 2023 at 12:38:25PM +0100, Pavel Machek wrote: >>> Hi! >>> >>>>> I'm pleased to announce the 5.10.162-rt78 stable release. >>>>> >>>>> You can get this release via the git tree at: >>>>> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git >>>>> >>>>> branch: v5.10-rt >>>>> Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 >>>>> >>>>> Or to build 5.10.162-rt78 directly, the following patches should be applied: >>> >>>> I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] >>>> Any pointers on what maybe wrong? >>> >>> We see the same failure. >>> >>>> AS arch/arm64/kernel/entry.o >>>> arch/arm64/kernel/entry.S: Assembler messages: >>>> arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' >>>> make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 >>>> make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 >>>> make: *** [Makefile:1837: arch/arm64] Error 2 >>> >>> The line is: >>> >>>> and x2, x19, #_TIF_WORK_MASK >> >> I believe this is related to the arch/arm64/include/asm/thread_info.h >> changes in 5.10.162-rt78, specifically: >> >> 79a9991e87fe arm64: add support for TIF_NOTIFY_SIGNAL >> 1ba44dcf789d Merge tag 'v5.10.162' into v5.10-rt >> >> The first one is the original change, coming from stable v5.10.162 and the >> second one has the merge conflict I fixed in that file due to the existence >> of TIF_NEED_RESCHED_LAZY in PREEMPT_RT. >> >> It escaped me that having TIF_NEED_RESCHED_LAZY set to 13 breaks the AND >> statement reported above. Looking at >> >> b5a5a01d8e9a arm64: uaccess: remove addr_limit_user_check() >> >> specially this note >> >> To ensure that _TIF_WORK_MASK can be used as an immediate value in an >> AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is >> renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. >> >> I understand that I need to either have to renumber TIF_NEED_RESCHED_LAZY >> to 8, with the risk of breaking something else, or backport commit >> b5a5a01d8e9a in order to remove TIF_FSCHECK and then safely renumber >> TIF_NEED_RESCHED_LAZY. >> >> Guidance is welcome here :) > > Should we loop in here Jens, as having some overview of the needed > changes for io_uring rebase in the 5.10.y version? (doing so in the > mail). Huh that's funky, I built and (runtime) tested this on arm64 specifically. But I do remember some details about the first 8 bits on arm, but not arm64. I guess we need to twiddle that asm to deal with eg 16 bits, rather than attempt to backport any TIF removal patches. -- Jens Axboe ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-19 23:09 ` Jens Axboe @ 2023-01-20 3:44 ` Luis Claudio R. Goncalves 2023-01-20 3:49 ` Jens Axboe 2023-01-20 6:01 ` Mike Galbraith 1 sibling, 1 reply; 20+ messages in thread From: Luis Claudio R. Goncalves @ 2023-01-20 3:44 UTC (permalink / raw) To: Jens Axboe Cc: Salvatore Bonaccorso, Pavel Machek, Vignesh Raghavendra, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady On Thu, Jan 19, 2023 at 04:09:44PM -0700, Jens Axboe wrote: > On 1/19/23 2:03?PM, Salvatore Bonaccorso wrote: > > Hi Luis, all, > > > > On Thu, Jan 19, 2023 at 10:16:34AM -0300, Luis Claudio R. Goncalves wrote: > >> On Thu, Jan 19, 2023 at 12:38:25PM +0100, Pavel Machek wrote: > >>> Hi! > >>> > >>>>> I'm pleased to announce the 5.10.162-rt78 stable release. > >>>>> > >>>>> You can get this release via the git tree at: > >>>>> > >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > >>>>> > >>>>> branch: v5.10-rt > >>>>> Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 > >>>>> > >>>>> Or to build 5.10.162-rt78 directly, the following patches should be applied: > >>> > >>>> I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] > >>>> Any pointers on what maybe wrong? > >>> > >>> We see the same failure. > >>> > >>>> AS arch/arm64/kernel/entry.o > >>>> arch/arm64/kernel/entry.S: Assembler messages: > >>>> arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' > >>>> make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 > >>>> make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 > >>>> make: *** [Makefile:1837: arch/arm64] Error 2 > >>> > >>> The line is: > >>> > >>>> and x2, x19, #_TIF_WORK_MASK > >> > >> I believe this is related to the arch/arm64/include/asm/thread_info.h > >> changes in 5.10.162-rt78, specifically: > >> > >> 79a9991e87fe arm64: add support for TIF_NOTIFY_SIGNAL > >> 1ba44dcf789d Merge tag 'v5.10.162' into v5.10-rt > >> > >> The first one is the original change, coming from stable v5.10.162 and the > >> second one has the merge conflict I fixed in that file due to the existence > >> of TIF_NEED_RESCHED_LAZY in PREEMPT_RT. > >> > >> It escaped me that having TIF_NEED_RESCHED_LAZY set to 13 breaks the AND > >> statement reported above. Looking at > >> > >> b5a5a01d8e9a arm64: uaccess: remove addr_limit_user_check() > >> > >> specially this note > >> > >> To ensure that _TIF_WORK_MASK can be used as an immediate value in an > >> AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is > >> renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. > >> > >> I understand that I need to either have to renumber TIF_NEED_RESCHED_LAZY > >> to 8, with the risk of breaking something else, or backport commit > >> b5a5a01d8e9a in order to remove TIF_FSCHECK and then safely renumber > >> TIF_NEED_RESCHED_LAZY. > >> > >> Guidance is welcome here :) > > > > Should we loop in here Jens, as having some overview of the needed > > changes for io_uring rebase in the 5.10.y version? (doing so in the > > mail). > > Huh that's funky, I built and (runtime) tested this on arm64 > specifically. But I do remember some details about the first 8 bits on > arm, but not arm64. > > I guess we need to twiddle that asm to deal with eg 16 bits, rather than > attempt to backport any TIF removal patches. One simple solution, tested with defconfig plus FTRACE options (including FTRACE_SYSCALLS) enabled, is: diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h index 6eb36a2126e8..37f19bb49d38 100644 --- a/arch/arm64/include/asm/thread_info.h +++ b/arch/arm64/include/asm/thread_info.h @@ -70,12 +70,12 @@ void arch_release_task_struct(struct task_struct *tsk); #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ #define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ +#define TIF_NEED_RESCHED_LAZY 8 #define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ #define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ #define TIF_SECCOMP 11 /* syscall secure computing */ #define TIF_SYSCALL_EMU 12 /* syscall emulation active */ -#define TIF_NEED_RESCHED_LAZY 13 +#define TIF_SYSCALL_TRACE 13 /* syscall trace active */ #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ #define TIF_FREEZE 19 #define TIF_RESTORE_SIGMASK 20 Would that be acceptable? With that we ensure the bits in _TIF_WORK_MASK are contiguous and within the 8 bits limit you mentioned. And TIF_SYSCALL_TRACE did not seem to have any (build) problem with the new value. Luis > > -- > Jens Axboe > ---end quoted text--- ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-20 3:44 ` Luis Claudio R. Goncalves @ 2023-01-20 3:49 ` Jens Axboe 2023-01-20 5:36 ` Salvatore Bonaccorso ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Jens Axboe @ 2023-01-20 3:49 UTC (permalink / raw) To: Luis Claudio R. Goncalves Cc: Salvatore Bonaccorso, Pavel Machek, Vignesh Raghavendra, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady On 1/19/23 8:44?PM, Luis Claudio R. Goncalves wrote: > On Thu, Jan 19, 2023 at 04:09:44PM -0700, Jens Axboe wrote: >> On 1/19/23 2:03?PM, Salvatore Bonaccorso wrote: >>> Hi Luis, all, >>> >>> On Thu, Jan 19, 2023 at 10:16:34AM -0300, Luis Claudio R. Goncalves wrote: >>>> On Thu, Jan 19, 2023 at 12:38:25PM +0100, Pavel Machek wrote: >>>>> Hi! >>>>> >>>>>>> I'm pleased to announce the 5.10.162-rt78 stable release. >>>>>>> >>>>>>> You can get this release via the git tree at: >>>>>>> >>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git >>>>>>> >>>>>>> branch: v5.10-rt >>>>>>> Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 >>>>>>> >>>>>>> Or to build 5.10.162-rt78 directly, the following patches should be applied: >>>>> >>>>>> I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] >>>>>> Any pointers on what maybe wrong? >>>>> >>>>> We see the same failure. >>>>> >>>>>> AS arch/arm64/kernel/entry.o >>>>>> arch/arm64/kernel/entry.S: Assembler messages: >>>>>> arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' >>>>>> make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 >>>>>> make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 >>>>>> make: *** [Makefile:1837: arch/arm64] Error 2 >>>>> >>>>> The line is: >>>>> >>>>>> and x2, x19, #_TIF_WORK_MASK >>>> >>>> I believe this is related to the arch/arm64/include/asm/thread_info.h >>>> changes in 5.10.162-rt78, specifically: >>>> >>>> 79a9991e87fe arm64: add support for TIF_NOTIFY_SIGNAL >>>> 1ba44dcf789d Merge tag 'v5.10.162' into v5.10-rt >>>> >>>> The first one is the original change, coming from stable v5.10.162 and the >>>> second one has the merge conflict I fixed in that file due to the existence >>>> of TIF_NEED_RESCHED_LAZY in PREEMPT_RT. >>>> >>>> It escaped me that having TIF_NEED_RESCHED_LAZY set to 13 breaks the AND >>>> statement reported above. Looking at >>>> >>>> b5a5a01d8e9a arm64: uaccess: remove addr_limit_user_check() >>>> >>>> specially this note >>>> >>>> To ensure that _TIF_WORK_MASK can be used as an immediate value in an >>>> AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is >>>> renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. >>>> >>>> I understand that I need to either have to renumber TIF_NEED_RESCHED_LAZY >>>> to 8, with the risk of breaking something else, or backport commit >>>> b5a5a01d8e9a in order to remove TIF_FSCHECK and then safely renumber >>>> TIF_NEED_RESCHED_LAZY. >>>> >>>> Guidance is welcome here :) >>> >>> Should we loop in here Jens, as having some overview of the needed >>> changes for io_uring rebase in the 5.10.y version? (doing so in the >>> mail). >> >> Huh that's funky, I built and (runtime) tested this on arm64 >> specifically. But I do remember some details about the first 8 bits on >> arm, but not arm64. >> >> I guess we need to twiddle that asm to deal with eg 16 bits, rather than >> attempt to backport any TIF removal patches. > > One simple solution, tested with defconfig plus FTRACE options (including > FTRACE_SYSCALLS) enabled, is: > > diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h > index 6eb36a2126e8..37f19bb49d38 100644 > --- a/arch/arm64/include/asm/thread_info.h > +++ b/arch/arm64/include/asm/thread_info.h > @@ -70,12 +70,12 @@ void arch_release_task_struct(struct task_struct *tsk); > #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ > #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ > #define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ > -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ > +#define TIF_NEED_RESCHED_LAZY 8 > #define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ > #define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ > #define TIF_SECCOMP 11 /* syscall secure computing */ > #define TIF_SYSCALL_EMU 12 /* syscall emulation active */ > -#define TIF_NEED_RESCHED_LAZY 13 > +#define TIF_SYSCALL_TRACE 13 /* syscall trace active */ > #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ > #define TIF_FREEZE 19 > #define TIF_RESTORE_SIGMASK 20 > > Would that be acceptable? With that we ensure the bits in > _TIF_WORK_MASK are contiguous and within the 8 bits limit you > mentioned. And TIF_SYSCALL_TRACE did not seem to have any (build) > problem with the new value. That should work too, the _TIF_WORK_MASK bits being in the lower 8 bits is really all we should care about. I do wonder why I didn't see this in testing - the kernel build bot was also happy with it... But anyway, should be an easy fix. -- Jens Axboe ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-20 3:49 ` Jens Axboe @ 2023-01-20 5:36 ` Salvatore Bonaccorso 2023-01-20 10:01 ` Daniel Wagner 2023-01-20 12:51 ` Luis Claudio R. Goncalves 2 siblings, 0 replies; 20+ messages in thread From: Salvatore Bonaccorso @ 2023-01-20 5:36 UTC (permalink / raw) To: Jens Axboe Cc: Luis Claudio R. Goncalves, Pavel Machek, Vignesh Raghavendra, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady Hi Jens, hi Luis, On Thu, Jan 19, 2023 at 08:49:28PM -0700, Jens Axboe wrote: > On 1/19/23 8:44?PM, Luis Claudio R. Goncalves wrote: > > On Thu, Jan 19, 2023 at 04:09:44PM -0700, Jens Axboe wrote: > >> On 1/19/23 2:03?PM, Salvatore Bonaccorso wrote: > >>> Hi Luis, all, > >>> > >>> On Thu, Jan 19, 2023 at 10:16:34AM -0300, Luis Claudio R. Goncalves wrote: > >>>> On Thu, Jan 19, 2023 at 12:38:25PM +0100, Pavel Machek wrote: > >>>>> Hi! > >>>>> > >>>>>>> I'm pleased to announce the 5.10.162-rt78 stable release. > >>>>>>> > >>>>>>> You can get this release via the git tree at: > >>>>>>> > >>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > >>>>>>> > >>>>>>> branch: v5.10-rt > >>>>>>> Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 > >>>>>>> > >>>>>>> Or to build 5.10.162-rt78 directly, the following patches should be applied: > >>>>> > >>>>>> I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] > >>>>>> Any pointers on what maybe wrong? > >>>>> > >>>>> We see the same failure. > >>>>> > >>>>>> AS arch/arm64/kernel/entry.o > >>>>>> arch/arm64/kernel/entry.S: Assembler messages: > >>>>>> arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' > >>>>>> make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 > >>>>>> make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 > >>>>>> make: *** [Makefile:1837: arch/arm64] Error 2 > >>>>> > >>>>> The line is: > >>>>> > >>>>>> and x2, x19, #_TIF_WORK_MASK > >>>> > >>>> I believe this is related to the arch/arm64/include/asm/thread_info.h > >>>> changes in 5.10.162-rt78, specifically: > >>>> > >>>> 79a9991e87fe arm64: add support for TIF_NOTIFY_SIGNAL > >>>> 1ba44dcf789d Merge tag 'v5.10.162' into v5.10-rt > >>>> > >>>> The first one is the original change, coming from stable v5.10.162 and the > >>>> second one has the merge conflict I fixed in that file due to the existence > >>>> of TIF_NEED_RESCHED_LAZY in PREEMPT_RT. > >>>> > >>>> It escaped me that having TIF_NEED_RESCHED_LAZY set to 13 breaks the AND > >>>> statement reported above. Looking at > >>>> > >>>> b5a5a01d8e9a arm64: uaccess: remove addr_limit_user_check() > >>>> > >>>> specially this note > >>>> > >>>> To ensure that _TIF_WORK_MASK can be used as an immediate value in an > >>>> AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is > >>>> renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. > >>>> > >>>> I understand that I need to either have to renumber TIF_NEED_RESCHED_LAZY > >>>> to 8, with the risk of breaking something else, or backport commit > >>>> b5a5a01d8e9a in order to remove TIF_FSCHECK and then safely renumber > >>>> TIF_NEED_RESCHED_LAZY. > >>>> > >>>> Guidance is welcome here :) > >>> > >>> Should we loop in here Jens, as having some overview of the needed > >>> changes for io_uring rebase in the 5.10.y version? (doing so in the > >>> mail). > >> > >> Huh that's funky, I built and (runtime) tested this on arm64 > >> specifically. But I do remember some details about the first 8 bits on > >> arm, but not arm64. > >> > >> I guess we need to twiddle that asm to deal with eg 16 bits, rather than > >> attempt to backport any TIF removal patches. > > > > One simple solution, tested with defconfig plus FTRACE options (including > > FTRACE_SYSCALLS) enabled, is: > > > > diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h > > index 6eb36a2126e8..37f19bb49d38 100644 > > --- a/arch/arm64/include/asm/thread_info.h > > +++ b/arch/arm64/include/asm/thread_info.h > > @@ -70,12 +70,12 @@ void arch_release_task_struct(struct task_struct *tsk); > > #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ > > #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ > > #define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ > > -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ > > +#define TIF_NEED_RESCHED_LAZY 8 > > #define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ > > #define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ > > #define TIF_SECCOMP 11 /* syscall secure computing */ > > #define TIF_SYSCALL_EMU 12 /* syscall emulation active */ > > -#define TIF_NEED_RESCHED_LAZY 13 > > +#define TIF_SYSCALL_TRACE 13 /* syscall trace active */ > > #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ > > #define TIF_FREEZE 19 > > #define TIF_RESTORE_SIGMASK 20 > > > > Would that be acceptable? With that we ensure the bits in > > _TIF_WORK_MASK are contiguous and within the 8 bits limit you > > mentioned. And TIF_SYSCALL_TRACE did not seem to have any (build) > > problem with the new value. > > That should work too, the _TIF_WORK_MASK bits being in the lower 8 bits > is really all we should care about. Is the arm64 patch the only one which needs adjustment (apologies for my ignorance here, I was able to test build on arm64 on Debian's end as well confirming it fails)? Regards, Salvatore > I do wonder why I didn't see this in testing - the kernel build bot was > also happy with it... But anyway, should be an easy fix. > > -- > Jens Axboe > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-20 3:49 ` Jens Axboe 2023-01-20 5:36 ` Salvatore Bonaccorso @ 2023-01-20 10:01 ` Daniel Wagner 2023-01-20 14:48 ` Jens Axboe 2023-01-20 12:51 ` Luis Claudio R. Goncalves 2 siblings, 1 reply; 20+ messages in thread From: Daniel Wagner @ 2023-01-20 10:01 UTC (permalink / raw) To: Jens Axboe Cc: Luis Claudio R. Goncalves, Salvatore Bonaccorso, Pavel Machek, Vignesh Raghavendra, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady On Thu, Jan 19, 2023 at 08:49:28PM -0700, Jens Axboe wrote: > I do wonder why I didn't see this in testing - the kernel build bot was > also happy with it... But anyway, should be an easy fix. This is caused by the RT patch set, so you wouldn't see it without all the RT patches applied :) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-20 10:01 ` Daniel Wagner @ 2023-01-20 14:48 ` Jens Axboe 0 siblings, 0 replies; 20+ messages in thread From: Jens Axboe @ 2023-01-20 14:48 UTC (permalink / raw) To: Daniel Wagner Cc: Luis Claudio R. Goncalves, Salvatore Bonaccorso, Pavel Machek, Vignesh Raghavendra, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady On 1/20/23 3:01 AM, Daniel Wagner wrote: > On Thu, Jan 19, 2023 at 08:49:28PM -0700, Jens Axboe wrote: >> I do wonder why I didn't see this in testing - the kernel build bot was >> also happy with it... But anyway, should be an easy fix. > > This is caused by the RT patch set, so you wouldn't see it without all the RT > patches applied :) Ahhhh, I totally missed the 'rt' part of the subject. Thanks, at least it makes sense to me now :-) -- Jens Axboe ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-20 3:49 ` Jens Axboe 2023-01-20 5:36 ` Salvatore Bonaccorso 2023-01-20 10:01 ` Daniel Wagner @ 2023-01-20 12:51 ` Luis Claudio R. Goncalves 2023-01-20 13:04 ` Sebastian Andrzej Siewior 2023-01-20 15:37 ` Mark Rutland 2 siblings, 2 replies; 20+ messages in thread From: Luis Claudio R. Goncalves @ 2023-01-20 12:51 UTC (permalink / raw) To: Jens Axboe Cc: Salvatore Bonaccorso, Pavel Machek, Vignesh Raghavendra, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady On Thu, Jan 19, 2023 at 08:49:28PM -0700, Jens Axboe wrote: > On 1/19/23 8:44?PM, Luis Claudio R. Goncalves wrote: > > On Thu, Jan 19, 2023 at 04:09:44PM -0700, Jens Axboe wrote: > >> On 1/19/23 2:03?PM, Salvatore Bonaccorso wrote: > >>> Hi Luis, all, > >>> > >>> On Thu, Jan 19, 2023 at 10:16:34AM -0300, Luis Claudio R. Goncalves wrote: > >>>> On Thu, Jan 19, 2023 at 12:38:25PM +0100, Pavel Machek wrote: > >>>>> Hi! > >>>>> > >>>>>>> I'm pleased to announce the 5.10.162-rt78 stable release. > >>>>>>> > >>>>>>> You can get this release via the git tree at: > >>>>>>> > >>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > >>>>>>> > >>>>>>> branch: v5.10-rt > >>>>>>> Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 > >>>>>>> > >>>>>>> Or to build 5.10.162-rt78 directly, the following patches should be applied: > >>>>> > >>>>>> I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] > >>>>>> Any pointers on what maybe wrong? > >>>>> > >>>>> We see the same failure. > >>>>> > >>>>>> AS arch/arm64/kernel/entry.o > >>>>>> arch/arm64/kernel/entry.S: Assembler messages: > >>>>>> arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' > >>>>>> make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 > >>>>>> make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 > >>>>>> make: *** [Makefile:1837: arch/arm64] Error 2 > >>>>> > >>>>> The line is: > >>>>> > >>>>>> and x2, x19, #_TIF_WORK_MASK > >>>> > >>>> I believe this is related to the arch/arm64/include/asm/thread_info.h > >>>> changes in 5.10.162-rt78, specifically: > >>>> > >>>> 79a9991e87fe arm64: add support for TIF_NOTIFY_SIGNAL > >>>> 1ba44dcf789d Merge tag 'v5.10.162' into v5.10-rt > >>>> > >>>> The first one is the original change, coming from stable v5.10.162 and the > >>>> second one has the merge conflict I fixed in that file due to the existence > >>>> of TIF_NEED_RESCHED_LAZY in PREEMPT_RT. > >>>> > >>>> It escaped me that having TIF_NEED_RESCHED_LAZY set to 13 breaks the AND > >>>> statement reported above. Looking at > >>>> > >>>> b5a5a01d8e9a arm64: uaccess: remove addr_limit_user_check() > >>>> > >>>> specially this note > >>>> > >>>> To ensure that _TIF_WORK_MASK can be used as an immediate value in an > >>>> AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is > >>>> renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. > >>>> > >>>> I understand that I need to either have to renumber TIF_NEED_RESCHED_LAZY > >>>> to 8, with the risk of breaking something else, or backport commit > >>>> b5a5a01d8e9a in order to remove TIF_FSCHECK and then safely renumber > >>>> TIF_NEED_RESCHED_LAZY. > >>>> > >>>> Guidance is welcome here :) > >>> > >>> Should we loop in here Jens, as having some overview of the needed > >>> changes for io_uring rebase in the 5.10.y version? (doing so in the > >>> mail). > >> > >> Huh that's funky, I built and (runtime) tested this on arm64 > >> specifically. But I do remember some details about the first 8 bits on > >> arm, but not arm64. > >> > >> I guess we need to twiddle that asm to deal with eg 16 bits, rather than > >> attempt to backport any TIF removal patches. > > > > One simple solution, tested with defconfig plus FTRACE options (including > > FTRACE_SYSCALLS) enabled, is: > > > > diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h > > index 6eb36a2126e8..37f19bb49d38 100644 > > --- a/arch/arm64/include/asm/thread_info.h > > +++ b/arch/arm64/include/asm/thread_info.h > > @@ -70,12 +70,12 @@ void arch_release_task_struct(struct task_struct *tsk); > > #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ > > #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ > > #define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ > > -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ > > +#define TIF_NEED_RESCHED_LAZY 8 > > #define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ > > #define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ > > #define TIF_SECCOMP 11 /* syscall secure computing */ > > #define TIF_SYSCALL_EMU 12 /* syscall emulation active */ > > -#define TIF_NEED_RESCHED_LAZY 13 > > +#define TIF_SYSCALL_TRACE 13 /* syscall trace active */ > > #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ > > #define TIF_FREEZE 19 > > #define TIF_RESTORE_SIGMASK 20 > > > > Would that be acceptable? With that we ensure the bits in > > _TIF_WORK_MASK are contiguous and within the 8 bits limit you > > mentioned. And TIF_SYSCALL_TRACE did not seem to have any (build) > > problem with the new value. > > That should work too, the _TIF_WORK_MASK bits being in the lower 8 bits > is really all we should care about. Jens, Salvatore, Mike, I ran a few tests and confirmed that the current asm code is not restricted to 8 bits. The problems is that there is a requirement for the mask bits to be contiguous in that specific context. The explanation from commit b5a5a01d8e9a ("arm64: uaccess: remove addr_limit_user_check()") describes quite well our case: To ensure that _TIF_WORK_MASK can be used as an immediate value in an AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. My question is: do you prefer renumbering the bits or the neat asm hack that Mike proposed? Luis > I do wonder why I didn't see this in testing - the kernel build bot was > also happy with it... But anyway, should be an easy fix. > > -- > Jens Axboe > ---end quoted text--- ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-20 12:51 ` Luis Claudio R. Goncalves @ 2023-01-20 13:04 ` Sebastian Andrzej Siewior 2023-01-20 15:37 ` Mark Rutland 1 sibling, 0 replies; 20+ messages in thread From: Sebastian Andrzej Siewior @ 2023-01-20 13:04 UTC (permalink / raw) To: Luis Claudio R. Goncalves Cc: Jens Axboe, Salvatore Bonaccorso, Pavel Machek, Vignesh Raghavendra, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady On 2023-01-20 09:51:07 [-0300], Luis Claudio R. Goncalves wrote: > My question is: do you prefer renumbering the bits or the neat asm hack > that Mike proposed? That change, that was stable-backported, should have hit the devel tree first. Why not sync with that? > Luis Sebastian ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-20 12:51 ` Luis Claudio R. Goncalves 2023-01-20 13:04 ` Sebastian Andrzej Siewior @ 2023-01-20 15:37 ` Mark Rutland 2023-01-20 18:25 ` Luis Claudio R. Goncalves 1 sibling, 1 reply; 20+ messages in thread From: Mark Rutland @ 2023-01-20 15:37 UTC (permalink / raw) To: Luis Claudio R. Goncalves Cc: Jens Axboe, Salvatore Bonaccorso, Pavel Machek, Vignesh Raghavendra, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady On Fri, Jan 20, 2023 at 09:51:07AM -0300, Luis Claudio R. Goncalves wrote: > On Thu, Jan 19, 2023 at 08:49:28PM -0700, Jens Axboe wrote: > > On 1/19/23 8:44?PM, Luis Claudio R. Goncalves wrote: > > > On Thu, Jan 19, 2023 at 04:09:44PM -0700, Jens Axboe wrote: > > >> On 1/19/23 2:03?PM, Salvatore Bonaccorso wrote: > > >>> Hi Luis, all, > > >>> > > >>> On Thu, Jan 19, 2023 at 10:16:34AM -0300, Luis Claudio R. Goncalves wrote: > > >>>> On Thu, Jan 19, 2023 at 12:38:25PM +0100, Pavel Machek wrote: > > >>>>> Hi! > > >>>>> > > >>>>>>> I'm pleased to announce the 5.10.162-rt78 stable release. > > >>>>>>> > > >>>>>>> You can get this release via the git tree at: > > >>>>>>> > > >>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > > >>>>>>> > > >>>>>>> branch: v5.10-rt > > >>>>>>> Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 > > >>>>>>> > > >>>>>>> Or to build 5.10.162-rt78 directly, the following patches should be applied: > > >>>>> > > >>>>>> I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] > > >>>>>> Any pointers on what maybe wrong? > > >>>>> > > >>>>> We see the same failure. > > >>>>> > > >>>>>> AS arch/arm64/kernel/entry.o > > >>>>>> arch/arm64/kernel/entry.S: Assembler messages: > > >>>>>> arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' > > >>>>>> make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 > > >>>>>> make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 > > >>>>>> make: *** [Makefile:1837: arch/arm64] Error 2 > > >>>>> > > >>>>> The line is: > > >>>>> > > >>>>>> and x2, x19, #_TIF_WORK_MASK > > >>>> > > >>>> I believe this is related to the arch/arm64/include/asm/thread_info.h > > >>>> changes in 5.10.162-rt78, specifically: > > >>>> > > >>>> 79a9991e87fe arm64: add support for TIF_NOTIFY_SIGNAL > > >>>> 1ba44dcf789d Merge tag 'v5.10.162' into v5.10-rt > > >>>> > > >>>> The first one is the original change, coming from stable v5.10.162 and the > > >>>> second one has the merge conflict I fixed in that file due to the existence > > >>>> of TIF_NEED_RESCHED_LAZY in PREEMPT_RT. > > >>>> > > >>>> It escaped me that having TIF_NEED_RESCHED_LAZY set to 13 breaks the AND > > >>>> statement reported above. Looking at > > >>>> > > >>>> b5a5a01d8e9a arm64: uaccess: remove addr_limit_user_check() > > >>>> > > >>>> specially this note > > >>>> > > >>>> To ensure that _TIF_WORK_MASK can be used as an immediate value in an > > >>>> AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is > > >>>> renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. > > >>>> > > >>>> I understand that I need to either have to renumber TIF_NEED_RESCHED_LAZY > > >>>> to 8, with the risk of breaking something else, or backport commit > > >>>> b5a5a01d8e9a in order to remove TIF_FSCHECK and then safely renumber > > >>>> TIF_NEED_RESCHED_LAZY. > > >>>> > > >>>> Guidance is welcome here :) > > >>> > > >>> Should we loop in here Jens, as having some overview of the needed > > >>> changes for io_uring rebase in the 5.10.y version? (doing so in the > > >>> mail). > > >> > > >> Huh that's funky, I built and (runtime) tested this on arm64 > > >> specifically. But I do remember some details about the first 8 bits on > > >> arm, but not arm64. > > >> > > >> I guess we need to twiddle that asm to deal with eg 16 bits, rather than > > >> attempt to backport any TIF removal patches. > > > > > > One simple solution, tested with defconfig plus FTRACE options (including > > > FTRACE_SYSCALLS) enabled, is: > > > > > > diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h > > > index 6eb36a2126e8..37f19bb49d38 100644 > > > --- a/arch/arm64/include/asm/thread_info.h > > > +++ b/arch/arm64/include/asm/thread_info.h > > > @@ -70,12 +70,12 @@ void arch_release_task_struct(struct task_struct *tsk); > > > #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ > > > #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ > > > #define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ > > > -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ > > > +#define TIF_NEED_RESCHED_LAZY 8 > > > #define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ > > > #define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ > > > #define TIF_SECCOMP 11 /* syscall secure computing */ > > > #define TIF_SYSCALL_EMU 12 /* syscall emulation active */ > > > -#define TIF_NEED_RESCHED_LAZY 13 > > > +#define TIF_SYSCALL_TRACE 13 /* syscall trace active */ > > > #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ > > > #define TIF_FREEZE 19 > > > #define TIF_RESTORE_SIGMASK 20 > > > > > > Would that be acceptable? With that we ensure the bits in > > > _TIF_WORK_MASK are contiguous and within the 8 bits limit you > > > mentioned. And TIF_SYSCALL_TRACE did not seem to have any (build) > > > problem with the new value. > > > > That should work too, the _TIF_WORK_MASK bits being in the lower 8 bits > > is really all we should care about. > > Jens, Salvatore, Mike, I ran a few tests and confirmed that the current asm > code is not restricted to 8 bits. The problems is that there is a > requirement for the mask bits to be contiguous in that specific context. Just to confirm from the arm64 side, the instruction using this just requires the bits to be contiguous, there's no restriction on *which* bits those are. If you're going to mess around with the arm64 bits, please could you Cc someone form the arm64 side? e.g. I fixed a similar issue in mainline in commit: 870d16757ba8918c ("arm64: make _TIF_WORK_MASK bits contiguous") ... and either Will Deacon or Catalin Marinas may have had comments as they're the arm64 maintainers... > The explanation from commit b5a5a01d8e9a ("arm64: uaccess: remove > addr_limit_user_check()") describes quite well our case: > > To ensure that _TIF_WORK_MASK can be used as an immediate value in an > AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is > renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. > > My question is: do you prefer renumbering the bits or the neat asm hack > that Mike proposed? I would strongly recommend renumbering the bits over changing the asm. That's going to be closer to what mainline has already done, and it avoids introducing weird ifdeffery. That said, rather than swapping TIF_SYSCALL_TRACE and TIF_NEED_RESCHED_LAZY, you could just shuffle the bits down-by-one, keeping all the existing contiguity, e.g. #define TIF_NEED_RESCHED_LAZY 8 #define TIF_SYSCALL_TRACE 9 #define TIF_SYSCALL_AUDIT 10 #define TIF_SYSCALL_TRACEPOINT 11 ... and so on. Thanks, Mark. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-20 15:37 ` Mark Rutland @ 2023-01-20 18:25 ` Luis Claudio R. Goncalves 2023-01-20 18:38 ` Salvatore Bonaccorso 2023-01-23 16:32 ` Mark Rutland 0 siblings, 2 replies; 20+ messages in thread From: Luis Claudio R. Goncalves @ 2023-01-20 18:25 UTC (permalink / raw) To: Mark Rutland Cc: Jens Axboe, Salvatore Bonaccorso, Pavel Machek, Vignesh Raghavendra, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady On Fri, Jan 20, 2023 at 03:37:35PM +0000, Mark Rutland wrote: > On Fri, Jan 20, 2023 at 09:51:07AM -0300, Luis Claudio R. Goncalves wrote: > > On Thu, Jan 19, 2023 at 08:49:28PM -0700, Jens Axboe wrote: > > > On 1/19/23 8:44?PM, Luis Claudio R. Goncalves wrote: > > > > On Thu, Jan 19, 2023 at 04:09:44PM -0700, Jens Axboe wrote: > > > >> On 1/19/23 2:03?PM, Salvatore Bonaccorso wrote: > > > >>> Hi Luis, all, > > > >>> > > > >>> On Thu, Jan 19, 2023 at 10:16:34AM -0300, Luis Claudio R. Goncalves wrote: > > > >>>> On Thu, Jan 19, 2023 at 12:38:25PM +0100, Pavel Machek wrote: > > > >>>>> Hi! > > > >>>>> > > > >>>>>>> I'm pleased to announce the 5.10.162-rt78 stable release. > > > >>>>>>> > > > >>>>>>> You can get this release via the git tree at: > > > >>>>>>> > > > >>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > > > >>>>>>> > > > >>>>>>> branch: v5.10-rt > > > >>>>>>> Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 > > > >>>>>>> > > > >>>>>>> Or to build 5.10.162-rt78 directly, the following patches should be applied: > > > >>>>> > > > >>>>>> I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] > > > >>>>>> Any pointers on what maybe wrong? > > > >>>>> > > > >>>>> We see the same failure. > > > >>>>> > > > >>>>>> AS arch/arm64/kernel/entry.o > > > >>>>>> arch/arm64/kernel/entry.S: Assembler messages: > > > >>>>>> arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' > > > >>>>>> make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 > > > >>>>>> make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 > > > >>>>>> make: *** [Makefile:1837: arch/arm64] Error 2 > > > >>>>> > > > >>>>> The line is: > > > >>>>> > > > >>>>>> and x2, x19, #_TIF_WORK_MASK > > > >>>> > > > >>>> I believe this is related to the arch/arm64/include/asm/thread_info.h > > > >>>> changes in 5.10.162-rt78, specifically: > > > >>>> > > > >>>> 79a9991e87fe arm64: add support for TIF_NOTIFY_SIGNAL > > > >>>> 1ba44dcf789d Merge tag 'v5.10.162' into v5.10-rt > > > >>>> > > > >>>> The first one is the original change, coming from stable v5.10.162 and the > > > >>>> second one has the merge conflict I fixed in that file due to the existence > > > >>>> of TIF_NEED_RESCHED_LAZY in PREEMPT_RT. > > > >>>> > > > >>>> It escaped me that having TIF_NEED_RESCHED_LAZY set to 13 breaks the AND > > > >>>> statement reported above. Looking at > > > >>>> > > > >>>> b5a5a01d8e9a arm64: uaccess: remove addr_limit_user_check() > > > >>>> > > > >>>> specially this note > > > >>>> > > > >>>> To ensure that _TIF_WORK_MASK can be used as an immediate value in an > > > >>>> AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is > > > >>>> renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. > > > >>>> > > > >>>> I understand that I need to either have to renumber TIF_NEED_RESCHED_LAZY > > > >>>> to 8, with the risk of breaking something else, or backport commit > > > >>>> b5a5a01d8e9a in order to remove TIF_FSCHECK and then safely renumber > > > >>>> TIF_NEED_RESCHED_LAZY. > > > >>>> > > > >>>> Guidance is welcome here :) > > > >>> > > > >>> Should we loop in here Jens, as having some overview of the needed > > > >>> changes for io_uring rebase in the 5.10.y version? (doing so in the > > > >>> mail). > > > >> > > > >> Huh that's funky, I built and (runtime) tested this on arm64 > > > >> specifically. But I do remember some details about the first 8 bits on > > > >> arm, but not arm64. > > > >> > > > >> I guess we need to twiddle that asm to deal with eg 16 bits, rather than > > > >> attempt to backport any TIF removal patches. > > > > > > > > One simple solution, tested with defconfig plus FTRACE options (including > > > > FTRACE_SYSCALLS) enabled, is: > > > > > > > > diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h > > > > index 6eb36a2126e8..37f19bb49d38 100644 > > > > --- a/arch/arm64/include/asm/thread_info.h > > > > +++ b/arch/arm64/include/asm/thread_info.h > > > > @@ -70,12 +70,12 @@ void arch_release_task_struct(struct task_struct *tsk); > > > > #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ > > > > #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ > > > > #define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ > > > > -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ > > > > +#define TIF_NEED_RESCHED_LAZY 8 > > > > #define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ > > > > #define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ > > > > #define TIF_SECCOMP 11 /* syscall secure computing */ > > > > #define TIF_SYSCALL_EMU 12 /* syscall emulation active */ > > > > -#define TIF_NEED_RESCHED_LAZY 13 > > > > +#define TIF_SYSCALL_TRACE 13 /* syscall trace active */ > > > > #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ > > > > #define TIF_FREEZE 19 > > > > #define TIF_RESTORE_SIGMASK 20 > > > > > > > > Would that be acceptable? With that we ensure the bits in > > > > _TIF_WORK_MASK are contiguous and within the 8 bits limit you > > > > mentioned. And TIF_SYSCALL_TRACE did not seem to have any (build) > > > > problem with the new value. > > > > > > That should work too, the _TIF_WORK_MASK bits being in the lower 8 bits > > > is really all we should care about. > > > > Jens, Salvatore, Mike, I ran a few tests and confirmed that the current asm > > code is not restricted to 8 bits. The problems is that there is a > > requirement for the mask bits to be contiguous in that specific context. > > Just to confirm from the arm64 side, the instruction using this just requires > the bits to be contiguous, there's no restriction on *which* bits those are. Thank you, that's really helpful! > If you're going to mess around with the arm64 bits, please could you Cc someone > form the arm64 side? e.g. I fixed a similar issue in mainline in commit: > > 870d16757ba8918c ("arm64: make _TIF_WORK_MASK bits contiguous") > > ... and either Will Deacon or Catalin Marinas may have had comments as they're > the arm64 maintainers... Just to avoid confusion here, this change is specific to the v5.10-rt, not applicable upstream nor to newer RT. We only saw the problem because TIF_NOTIFY_SIGNAL was mapped to a bit used by TIF_NEED_RESCHED_LAZY in v5.10-rt (the PREEMPT_RT changes on top of stable v5.10). This is why nobody from the arm64 side was copied initially, as we were trying to assert what was the problem. > > The explanation from commit b5a5a01d8e9a ("arm64: uaccess: remove > > addr_limit_user_check()") describes quite well our case: > > > > To ensure that _TIF_WORK_MASK can be used as an immediate value in an > > AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is > > renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. > > > > My question is: do you prefer renumbering the bits or the neat asm hack > > that Mike proposed? > > I would strongly recommend renumbering the bits over changing the asm. That's > going to be closer to what mainline has already done, and it avoids introducing > weird ifdeffery. > > That said, rather than swapping TIF_SYSCALL_TRACE and TIF_NEED_RESCHED_LAZY, > you could just shuffle the bits down-by-one, keeping all the existing > contiguity, e.g. > > #define TIF_NEED_RESCHED_LAZY 8 > #define TIF_SYSCALL_TRACE 9 > #define TIF_SYSCALL_AUDIT 10 > #define TIF_SYSCALL_TRACEPOINT 11 > > ... and so on. Would something like this be a good interpretation of your suggestion? diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h index 6eb36a212..2afd9ceb6 100644 --- a/arch/arm64/include/asm/thread_info.h +++ b/arch/arm64/include/asm/thread_info.h @@ -70,12 +70,12 @@ void arch_release_task_struct(struct task_struct *tsk); #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ #define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ -#define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ -#define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ -#define TIF_SECCOMP 11 /* syscall secure computing */ -#define TIF_SYSCALL_EMU 12 /* syscall emulation active */ -#define TIF_NEED_RESCHED_LAZY 13 +#define TIF_NEED_RESCHED_LAZY 8 +#define TIF_SYSCALL_TRACE 9 /* syscall trace active */ +#define TIF_SYSCALL_AUDIT 10 /* syscall auditing */ +#define TIF_SYSCALL_TRACEPOINT 11 /* syscall tracepoint for ftrace */ +#define TIF_SECCOMP 12 /* syscall secure computing */ +#define TIF_SYSCALL_EMU 13 /* syscall emulation active */ #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ #define TIF_FREEZE 19 #define TIF_RESTORE_SIGMASK 20 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-20 18:25 ` Luis Claudio R. Goncalves @ 2023-01-20 18:38 ` Salvatore Bonaccorso 2023-01-23 16:32 ` Mark Rutland 1 sibling, 0 replies; 20+ messages in thread From: Salvatore Bonaccorso @ 2023-01-20 18:38 UTC (permalink / raw) To: Luis Claudio R. Goncalves Cc: Mark Rutland, Jens Axboe, Pavel Machek, Vignesh Raghavendra, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady [-- Attachment #1: Type: text/plain, Size: 9697 bytes --] Hi all, On Fri, Jan 20, 2023 at 03:25:57PM -0300, Luis Claudio R. Goncalves wrote: > On Fri, Jan 20, 2023 at 03:37:35PM +0000, Mark Rutland wrote: > > On Fri, Jan 20, 2023 at 09:51:07AM -0300, Luis Claudio R. Goncalves wrote: > > > On Thu, Jan 19, 2023 at 08:49:28PM -0700, Jens Axboe wrote: > > > > On 1/19/23 8:44?PM, Luis Claudio R. Goncalves wrote: > > > > > On Thu, Jan 19, 2023 at 04:09:44PM -0700, Jens Axboe wrote: > > > > >> On 1/19/23 2:03?PM, Salvatore Bonaccorso wrote: > > > > >>> Hi Luis, all, > > > > >>> > > > > >>> On Thu, Jan 19, 2023 at 10:16:34AM -0300, Luis Claudio R. Goncalves wrote: > > > > >>>> On Thu, Jan 19, 2023 at 12:38:25PM +0100, Pavel Machek wrote: > > > > >>>>> Hi! > > > > >>>>> > > > > >>>>>>> I'm pleased to announce the 5.10.162-rt78 stable release. > > > > >>>>>>> > > > > >>>>>>> You can get this release via the git tree at: > > > > >>>>>>> > > > > >>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > > > > >>>>>>> > > > > >>>>>>> branch: v5.10-rt > > > > >>>>>>> Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 > > > > >>>>>>> > > > > >>>>>>> Or to build 5.10.162-rt78 directly, the following patches should be applied: > > > > >>>>> > > > > >>>>>> I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] > > > > >>>>>> Any pointers on what maybe wrong? > > > > >>>>> > > > > >>>>> We see the same failure. > > > > >>>>> > > > > >>>>>> AS arch/arm64/kernel/entry.o > > > > >>>>>> arch/arm64/kernel/entry.S: Assembler messages: > > > > >>>>>> arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' > > > > >>>>>> make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 > > > > >>>>>> make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 > > > > >>>>>> make: *** [Makefile:1837: arch/arm64] Error 2 > > > > >>>>> > > > > >>>>> The line is: > > > > >>>>> > > > > >>>>>> and x2, x19, #_TIF_WORK_MASK > > > > >>>> > > > > >>>> I believe this is related to the arch/arm64/include/asm/thread_info.h > > > > >>>> changes in 5.10.162-rt78, specifically: > > > > >>>> > > > > >>>> 79a9991e87fe arm64: add support for TIF_NOTIFY_SIGNAL > > > > >>>> 1ba44dcf789d Merge tag 'v5.10.162' into v5.10-rt > > > > >>>> > > > > >>>> The first one is the original change, coming from stable v5.10.162 and the > > > > >>>> second one has the merge conflict I fixed in that file due to the existence > > > > >>>> of TIF_NEED_RESCHED_LAZY in PREEMPT_RT. > > > > >>>> > > > > >>>> It escaped me that having TIF_NEED_RESCHED_LAZY set to 13 breaks the AND > > > > >>>> statement reported above. Looking at > > > > >>>> > > > > >>>> b5a5a01d8e9a arm64: uaccess: remove addr_limit_user_check() > > > > >>>> > > > > >>>> specially this note > > > > >>>> > > > > >>>> To ensure that _TIF_WORK_MASK can be used as an immediate value in an > > > > >>>> AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is > > > > >>>> renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. > > > > >>>> > > > > >>>> I understand that I need to either have to renumber TIF_NEED_RESCHED_LAZY > > > > >>>> to 8, with the risk of breaking something else, or backport commit > > > > >>>> b5a5a01d8e9a in order to remove TIF_FSCHECK and then safely renumber > > > > >>>> TIF_NEED_RESCHED_LAZY. > > > > >>>> > > > > >>>> Guidance is welcome here :) > > > > >>> > > > > >>> Should we loop in here Jens, as having some overview of the needed > > > > >>> changes for io_uring rebase in the 5.10.y version? (doing so in the > > > > >>> mail). > > > > >> > > > > >> Huh that's funky, I built and (runtime) tested this on arm64 > > > > >> specifically. But I do remember some details about the first 8 bits on > > > > >> arm, but not arm64. > > > > >> > > > > >> I guess we need to twiddle that asm to deal with eg 16 bits, rather than > > > > >> attempt to backport any TIF removal patches. > > > > > > > > > > One simple solution, tested with defconfig plus FTRACE options (including > > > > > FTRACE_SYSCALLS) enabled, is: > > > > > > > > > > diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h > > > > > index 6eb36a2126e8..37f19bb49d38 100644 > > > > > --- a/arch/arm64/include/asm/thread_info.h > > > > > +++ b/arch/arm64/include/asm/thread_info.h > > > > > @@ -70,12 +70,12 @@ void arch_release_task_struct(struct task_struct *tsk); > > > > > #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ > > > > > #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ > > > > > #define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ > > > > > -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ > > > > > +#define TIF_NEED_RESCHED_LAZY 8 > > > > > #define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ > > > > > #define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ > > > > > #define TIF_SECCOMP 11 /* syscall secure computing */ > > > > > #define TIF_SYSCALL_EMU 12 /* syscall emulation active */ > > > > > -#define TIF_NEED_RESCHED_LAZY 13 > > > > > +#define TIF_SYSCALL_TRACE 13 /* syscall trace active */ > > > > > #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ > > > > > #define TIF_FREEZE 19 > > > > > #define TIF_RESTORE_SIGMASK 20 > > > > > > > > > > Would that be acceptable? With that we ensure the bits in > > > > > _TIF_WORK_MASK are contiguous and within the 8 bits limit you > > > > > mentioned. And TIF_SYSCALL_TRACE did not seem to have any (build) > > > > > problem with the new value. > > > > > > > > That should work too, the _TIF_WORK_MASK bits being in the lower 8 bits > > > > is really all we should care about. > > > > > > Jens, Salvatore, Mike, I ran a few tests and confirmed that the current asm > > > code is not restricted to 8 bits. The problems is that there is a > > > requirement for the mask bits to be contiguous in that specific context. > > > > Just to confirm from the arm64 side, the instruction using this just requires > > the bits to be contiguous, there's no restriction on *which* bits those are. > > Thank you, that's really helpful! > > > If you're going to mess around with the arm64 bits, please could you Cc someone > > form the arm64 side? e.g. I fixed a similar issue in mainline in commit: > > > > 870d16757ba8918c ("arm64: make _TIF_WORK_MASK bits contiguous") > > > > ... and either Will Deacon or Catalin Marinas may have had comments as they're > > the arm64 maintainers... > > Just to avoid confusion here, this change is specific to the v5.10-rt, not > applicable upstream nor to newer RT. We only saw the problem because > TIF_NOTIFY_SIGNAL was mapped to a bit used by TIF_NEED_RESCHED_LAZY in > v5.10-rt (the PREEMPT_RT changes on top of stable v5.10). This is why > nobody from the arm64 side was copied initially, as we were trying to > assert what was the problem. > > > > The explanation from commit b5a5a01d8e9a ("arm64: uaccess: remove > > > addr_limit_user_check()") describes quite well our case: > > > > > > To ensure that _TIF_WORK_MASK can be used as an immediate value in an > > > AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is > > > renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. > > > > > > My question is: do you prefer renumbering the bits or the neat asm hack > > > that Mike proposed? > > > > I would strongly recommend renumbering the bits over changing the asm. That's > > going to be closer to what mainline has already done, and it avoids introducing > > weird ifdeffery. > > > > That said, rather than swapping TIF_SYSCALL_TRACE and TIF_NEED_RESCHED_LAZY, > > you could just shuffle the bits down-by-one, keeping all the existing > > contiguity, e.g. > > > > #define TIF_NEED_RESCHED_LAZY 8 > > #define TIF_SYSCALL_TRACE 9 > > #define TIF_SYSCALL_AUDIT 10 > > #define TIF_SYSCALL_TRACEPOINT 11 > > > > ... and so on. > > Would something like this be a good interpretation of your suggestion? > > diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h > index 6eb36a212..2afd9ceb6 100644 > --- a/arch/arm64/include/asm/thread_info.h > +++ b/arch/arm64/include/asm/thread_info.h > @@ -70,12 +70,12 @@ void arch_release_task_struct(struct task_struct *tsk); > #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ > #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ > #define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ > -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ > -#define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ > -#define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ > -#define TIF_SECCOMP 11 /* syscall secure computing */ > -#define TIF_SYSCALL_EMU 12 /* syscall emulation active */ > -#define TIF_NEED_RESCHED_LAZY 13 > +#define TIF_NEED_RESCHED_LAZY 8 > +#define TIF_SYSCALL_TRACE 9 /* syscall trace active */ > +#define TIF_SYSCALL_AUDIT 10 /* syscall auditing */ > +#define TIF_SYSCALL_TRACEPOINT 11 /* syscall tracepoint for ftrace */ > +#define TIF_SECCOMP 12 /* syscall secure computing */ > +#define TIF_SYSCALL_EMU 13 /* syscall emulation active */ > #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ > #define TIF_FREEZE 19 > #define TIF_RESTORE_SIGMASK 20 I tried to follow the discussion as well which resulted in the following change, which matches how you interpreted it as well. It's just for reference, you can trow away the patch here in favour of your change by all means. Regards, Salvatore [-- Attachment #2: 0001-arm64-make-_TIF_WORK_MASK-bits-contiguous.patch --] [-- Type: text/x-diff, Size: 2456 bytes --] From 2c84672db9b8a6bd61b9c0939cb94652b62aa39d Mon Sep 17 00:00:00 2001 From: Salvatore Bonaccorso <carnil@debian.org> Date: Fri, 20 Jan 2023 19:23:03 +0100 Subject: [PATCH] arm64: make _TIF_WORK_MASK bits contiguous As same as in commit 870d16757ba8 ("arm64: make _TIF_WORK_MASK bits contiguous") in mainline, we need to make the bits of _TIF_WORK_MASK to be contiguous in order to use this as an immediate argument to an AND instruction in entry.S. We shuffle these bits down-by-one keeping the existing contiguity after inserting TIF_NEED_RESCHED_LAZY. Otherwise, omitting this change will result in a build failure as below: arch/arm64/kernel/entry.S: Assembler messages: arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' Reported-by: Vignesh Raghavendra <vigneshr@ti.com> Reported-by: Pavel Machek <pavel@denx.de> Link: https://lore.kernel.org/lkml/40de655e-26f3-aa7b-f1ec-6877396a9f1e@ti.com/ Signed-off-by: Salvatore Bonaccorso <carnil@debian.org> --- arch/arm64/include/asm/thread_info.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h index 6eb36a2126e8..2afd9ceb66c9 100644 --- a/arch/arm64/include/asm/thread_info.h +++ b/arch/arm64/include/asm/thread_info.h @@ -70,12 +70,12 @@ void arch_release_task_struct(struct task_struct *tsk); #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ #define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ -#define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ -#define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ -#define TIF_SECCOMP 11 /* syscall secure computing */ -#define TIF_SYSCALL_EMU 12 /* syscall emulation active */ -#define TIF_NEED_RESCHED_LAZY 13 +#define TIF_NEED_RESCHED_LAZY 8 +#define TIF_SYSCALL_TRACE 9 /* syscall trace active */ +#define TIF_SYSCALL_AUDIT 10 /* syscall auditing */ +#define TIF_SYSCALL_TRACEPOINT 11 /* syscall tracepoint for ftrace */ +#define TIF_SECCOMP 12 /* syscall secure computing */ +#define TIF_SYSCALL_EMU 13 /* syscall emulation active */ #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ #define TIF_FREEZE 19 #define TIF_RESTORE_SIGMASK 20 -- 2.39.0 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-20 18:25 ` Luis Claudio R. Goncalves 2023-01-20 18:38 ` Salvatore Bonaccorso @ 2023-01-23 16:32 ` Mark Rutland 2023-01-28 8:24 ` Raghavendra, Vignesh 1 sibling, 1 reply; 20+ messages in thread From: Mark Rutland @ 2023-01-23 16:32 UTC (permalink / raw) To: Luis Claudio R. Goncalves Cc: Jens Axboe, Salvatore Bonaccorso, Pavel Machek, Vignesh Raghavendra, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady On Fri, Jan 20, 2023 at 03:25:57PM -0300, Luis Claudio R. Goncalves wrote: > On Fri, Jan 20, 2023 at 03:37:35PM +0000, Mark Rutland wrote: > > On Fri, Jan 20, 2023 at 09:51:07AM -0300, Luis Claudio R. Goncalves wrote: > > > On Thu, Jan 19, 2023 at 08:49:28PM -0700, Jens Axboe wrote: > > > > On 1/19/23 8:44?PM, Luis Claudio R. Goncalves wrote: > > > > > On Thu, Jan 19, 2023 at 04:09:44PM -0700, Jens Axboe wrote: > > > > >> On 1/19/23 2:03?PM, Salvatore Bonaccorso wrote: > > > > >>> Hi Luis, all, > > > > >>> > > > > >>> On Thu, Jan 19, 2023 at 10:16:34AM -0300, Luis Claudio R. Goncalves wrote: > > > > >>>> On Thu, Jan 19, 2023 at 12:38:25PM +0100, Pavel Machek wrote: > > > > >>>>> Hi! > > > > >>>>> > > > > >>>>>>> I'm pleased to announce the 5.10.162-rt78 stable release. > > > > >>>>>>> > > > > >>>>>>> You can get this release via the git tree at: > > > > >>>>>>> > > > > >>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > > > > >>>>>>> > > > > >>>>>>> branch: v5.10-rt > > > > >>>>>>> Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 > > > > >>>>>>> > > > > >>>>>>> Or to build 5.10.162-rt78 directly, the following patches should be applied: > > > > >>>>> > > > > >>>>>> I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] > > > > >>>>>> Any pointers on what maybe wrong? > > > > >>>>> > > > > >>>>> We see the same failure. > > > > >>>>> > > > > >>>>>> AS arch/arm64/kernel/entry.o > > > > >>>>>> arch/arm64/kernel/entry.S: Assembler messages: > > > > >>>>>> arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' > > > > >>>>>> make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 > > > > >>>>>> make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 > > > > >>>>>> make: *** [Makefile:1837: arch/arm64] Error 2 > > > > >>>>> > > > > >>>>> The line is: > > > > >>>>> > > > > >>>>>> and x2, x19, #_TIF_WORK_MASK > > > > >>>> > > > > >>>> I believe this is related to the arch/arm64/include/asm/thread_info.h > > > > >>>> changes in 5.10.162-rt78, specifically: > > > > >>>> > > > > >>>> 79a9991e87fe arm64: add support for TIF_NOTIFY_SIGNAL > > > > >>>> 1ba44dcf789d Merge tag 'v5.10.162' into v5.10-rt > > > > >>>> > > > > >>>> The first one is the original change, coming from stable v5.10.162 and the > > > > >>>> second one has the merge conflict I fixed in that file due to the existence > > > > >>>> of TIF_NEED_RESCHED_LAZY in PREEMPT_RT. > > > > >>>> > > > > >>>> It escaped me that having TIF_NEED_RESCHED_LAZY set to 13 breaks the AND > > > > >>>> statement reported above. Looking at > > > > >>>> > > > > >>>> b5a5a01d8e9a arm64: uaccess: remove addr_limit_user_check() > > > > >>>> > > > > >>>> specially this note > > > > >>>> > > > > >>>> To ensure that _TIF_WORK_MASK can be used as an immediate value in an > > > > >>>> AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is > > > > >>>> renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. > > > > >>>> > > > > >>>> I understand that I need to either have to renumber TIF_NEED_RESCHED_LAZY > > > > >>>> to 8, with the risk of breaking something else, or backport commit > > > > >>>> b5a5a01d8e9a in order to remove TIF_FSCHECK and then safely renumber > > > > >>>> TIF_NEED_RESCHED_LAZY. > > > > >>>> > > > > >>>> Guidance is welcome here :) > > > > >>> > > > > >>> Should we loop in here Jens, as having some overview of the needed > > > > >>> changes for io_uring rebase in the 5.10.y version? (doing so in the > > > > >>> mail). > > > > >> > > > > >> Huh that's funky, I built and (runtime) tested this on arm64 > > > > >> specifically. But I do remember some details about the first 8 bits on > > > > >> arm, but not arm64. > > > > >> > > > > >> I guess we need to twiddle that asm to deal with eg 16 bits, rather than > > > > >> attempt to backport any TIF removal patches. > > > > > > > > > > One simple solution, tested with defconfig plus FTRACE options (including > > > > > FTRACE_SYSCALLS) enabled, is: > > > > > > > > > > diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h > > > > > index 6eb36a2126e8..37f19bb49d38 100644 > > > > > --- a/arch/arm64/include/asm/thread_info.h > > > > > +++ b/arch/arm64/include/asm/thread_info.h > > > > > @@ -70,12 +70,12 @@ void arch_release_task_struct(struct task_struct *tsk); > > > > > #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ > > > > > #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ > > > > > #define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ > > > > > -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ > > > > > +#define TIF_NEED_RESCHED_LAZY 8 > > > > > #define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ > > > > > #define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ > > > > > #define TIF_SECCOMP 11 /* syscall secure computing */ > > > > > #define TIF_SYSCALL_EMU 12 /* syscall emulation active */ > > > > > -#define TIF_NEED_RESCHED_LAZY 13 > > > > > +#define TIF_SYSCALL_TRACE 13 /* syscall trace active */ > > > > > #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ > > > > > #define TIF_FREEZE 19 > > > > > #define TIF_RESTORE_SIGMASK 20 > > > > > > > > > > Would that be acceptable? With that we ensure the bits in > > > > > _TIF_WORK_MASK are contiguous and within the 8 bits limit you > > > > > mentioned. And TIF_SYSCALL_TRACE did not seem to have any (build) > > > > > problem with the new value. > > > > > > > > That should work too, the _TIF_WORK_MASK bits being in the lower 8 bits > > > > is really all we should care about. > > > > > > Jens, Salvatore, Mike, I ran a few tests and confirmed that the current asm > > > code is not restricted to 8 bits. The problems is that there is a > > > requirement for the mask bits to be contiguous in that specific context. > > > > Just to confirm from the arm64 side, the instruction using this just requires > > the bits to be contiguous, there's no restriction on *which* bits those are. > > Thank you, that's really helpful! > > > If you're going to mess around with the arm64 bits, please could you Cc someone > > form the arm64 side? e.g. I fixed a similar issue in mainline in commit: > > > > 870d16757ba8918c ("arm64: make _TIF_WORK_MASK bits contiguous") > > > > ... and either Will Deacon or Catalin Marinas may have had comments as they're > > the arm64 maintainers... > > Just to avoid confusion here, this change is specific to the v5.10-rt, not > applicable upstream nor to newer RT. We only saw the problem because > TIF_NOTIFY_SIGNAL was mapped to a bit used by TIF_NEED_RESCHED_LAZY in > v5.10-rt (the PREEMPT_RT changes on top of stable v5.10). This is why > nobody from the arm64 side was copied initially, as we were trying to > assert what was the problem. Sure, and sorry, I think my reply came across a bit stronger than I intended. I probably should have said something like: "please feel free to rope in one of us from the arm64 side". I know from experience that this area is fairly subtle, and I'd like to help to ensure that the fix doesn't introduce a subtle breakage or interact poorly with future backports. > > > The explanation from commit b5a5a01d8e9a ("arm64: uaccess: remove > > > addr_limit_user_check()") describes quite well our case: > > > > > > To ensure that _TIF_WORK_MASK can be used as an immediate value in an > > > AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is > > > renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. > > > > > > My question is: do you prefer renumbering the bits or the neat asm hack > > > that Mike proposed? > > > > I would strongly recommend renumbering the bits over changing the asm. That's > > going to be closer to what mainline has already done, and it avoids introducing > > weird ifdeffery. > > > > That said, rather than swapping TIF_SYSCALL_TRACE and TIF_NEED_RESCHED_LAZY, > > you could just shuffle the bits down-by-one, keeping all the existing > > contiguity, e.g. > > > > #define TIF_NEED_RESCHED_LAZY 8 > > #define TIF_SYSCALL_TRACE 9 > > #define TIF_SYSCALL_AUDIT 10 > > #define TIF_SYSCALL_TRACEPOINT 11 > > > > ... and so on. > > Would something like this be a good interpretation of your suggestion? > > diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h > index 6eb36a212..2afd9ceb6 100644 > --- a/arch/arm64/include/asm/thread_info.h > +++ b/arch/arm64/include/asm/thread_info.h > @@ -70,12 +70,12 @@ void arch_release_task_struct(struct task_struct *tsk); > #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ > #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ > #define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ > -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ > -#define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ > -#define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ > -#define TIF_SECCOMP 11 /* syscall secure computing */ > -#define TIF_SYSCALL_EMU 12 /* syscall emulation active */ > -#define TIF_NEED_RESCHED_LAZY 13 > +#define TIF_NEED_RESCHED_LAZY 8 > +#define TIF_SYSCALL_TRACE 9 /* syscall trace active */ > +#define TIF_SYSCALL_AUDIT 10 /* syscall auditing */ > +#define TIF_SYSCALL_TRACEPOINT 11 /* syscall tracepoint for ftrace */ > +#define TIF_SECCOMP 12 /* syscall secure computing */ > +#define TIF_SYSCALL_EMU 13 /* syscall emulation active */ Yup, that looks god to me! Thanks, Mark. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-23 16:32 ` Mark Rutland @ 2023-01-28 8:24 ` Raghavendra, Vignesh 0 siblings, 0 replies; 20+ messages in thread From: Raghavendra, Vignesh @ 2023-01-28 8:24 UTC (permalink / raw) To: Luis Claudio R. Goncalves Cc: Jens Axboe, Salvatore Bonaccorso, Pavel Machek, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady, Mark Rutland Hi Luis, On 1/23/2023 10:02 PM, Mark Rutland wrote: > On Fri, Jan 20, 2023 at 03:25:57PM -0300, Luis Claudio R. Goncalves wrote: >> On Fri, Jan 20, 2023 at 03:37:35PM +0000, Mark Rutland wrote: >>> On Fri, Jan 20, 2023 at 09:51:07AM -0300, Luis Claudio R. Goncalves wrote: >>>> On Thu, Jan 19, 2023 at 08:49:28PM -0700, Jens Axboe wrote: >>>>> On 1/19/23 8:44?PM, Luis Claudio R. Goncalves wrote: >>>>>> On Thu, Jan 19, 2023 at 04:09:44PM -0700, Jens Axboe wrote: >>>>>>> On 1/19/23 2:03?PM, Salvatore Bonaccorso wrote: >>>>>>>> Hi Luis, all, >>>>>>>> >>>>>>>> On Thu, Jan 19, 2023 at 10:16:34AM -0300, Luis Claudio R. Goncalves wrote: >>>>>>>>> On Thu, Jan 19, 2023 at 12:38:25PM +0100, Pavel Machek wrote: >>>>>>>>>> Hi! >>>>>>>>>> >>>>>>>>>>>> I'm pleased to announce the 5.10.162-rt78 stable release. >>>>>>>>>>>> >>>>>>>>>>>> You can get this release via the git tree at: >>>>>>>>>>>> >>>>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git >>>>>>>>>>>> >>>>>>>>>>>> branch: v5.10-rt >>>>>>>>>>>> Head SHA1: 143ef105f40a65f3ddd57121d4b4bc36eb10cc06 >>>>>>>>>>>> >>>>>>>>>>>> Or to build 5.10.162-rt78 directly, the following patches should be applied: >>>>>>>>>> >>>>>>>>>>> I see that vanilla 5.10.162-rt78 fails to build with arm64 defconfig. [0] Full log [1] >>>>>>>>>>> Any pointers on what maybe wrong? >>>>>>>>>> >>>>>>>>>> We see the same failure. >>>>>>>>>> >>>>>>>>>>> AS arch/arm64/kernel/entry.o >>>>>>>>>>> arch/arm64/kernel/entry.S: Assembler messages: >>>>>>>>>>> arch/arm64/kernel/entry.S:763: Error: immediate out of range at operand 3 -- `and x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<13)|(1<<7))' >>>>>>>>>>> make[2]: *** [scripts/Makefile.build:367: arch/arm64/kernel/entry.o] Error 1 >>>>>>>>>>> make[1]: *** [scripts/Makefile.build:503: arch/arm64/kernel] Error 2 >>>>>>>>>>> make: *** [Makefile:1837: arch/arm64] Error 2 >>>>>>>>>> >>>>>>>>>> The line is: >>>>>>>>>> >>>>>>>>>>> and x2, x19, #_TIF_WORK_MASK >>>>>>>>> >>>>>>>>> I believe this is related to the arch/arm64/include/asm/thread_info.h >>>>>>>>> changes in 5.10.162-rt78, specifically: >>>>>>>>> >>>>>>>>> 79a9991e87fe arm64: add support for TIF_NOTIFY_SIGNAL >>>>>>>>> 1ba44dcf789d Merge tag 'v5.10.162' into v5.10-rt >>>>>>>>> >>>>>>>>> The first one is the original change, coming from stable v5.10.162 and the >>>>>>>>> second one has the merge conflict I fixed in that file due to the existence >>>>>>>>> of TIF_NEED_RESCHED_LAZY in PREEMPT_RT. >>>>>>>>> >>>>>>>>> It escaped me that having TIF_NEED_RESCHED_LAZY set to 13 breaks the AND >>>>>>>>> statement reported above. Looking at >>>>>>>>> >>>>>>>>> b5a5a01d8e9a arm64: uaccess: remove addr_limit_user_check() >>>>>>>>> >>>>>>>>> specially this note >>>>>>>>> >>>>>>>>> To ensure that _TIF_WORK_MASK can be used as an immediate value in an >>>>>>>>> AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is >>>>>>>>> renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. >>>>>>>>> >>>>>>>>> I understand that I need to either have to renumber TIF_NEED_RESCHED_LAZY >>>>>>>>> to 8, with the risk of breaking something else, or backport commit >>>>>>>>> b5a5a01d8e9a in order to remove TIF_FSCHECK and then safely renumber >>>>>>>>> TIF_NEED_RESCHED_LAZY. >>>>>>>>> >>>>>>>>> Guidance is welcome here :) >>>>>>>> >>>>>>>> Should we loop in here Jens, as having some overview of the needed >>>>>>>> changes for io_uring rebase in the 5.10.y version? (doing so in the >>>>>>>> mail). >>>>>>> >>>>>>> Huh that's funky, I built and (runtime) tested this on arm64 >>>>>>> specifically. But I do remember some details about the first 8 bits on >>>>>>> arm, but not arm64. >>>>>>> >>>>>>> I guess we need to twiddle that asm to deal with eg 16 bits, rather than >>>>>>> attempt to backport any TIF removal patches. >>>>>> >>>>>> One simple solution, tested with defconfig plus FTRACE options (including >>>>>> FTRACE_SYSCALLS) enabled, is: >>>>>> >>>>>> diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h >>>>>> index 6eb36a2126e8..37f19bb49d38 100644 >>>>>> --- a/arch/arm64/include/asm/thread_info.h >>>>>> +++ b/arch/arm64/include/asm/thread_info.h >>>>>> @@ -70,12 +70,12 @@ void arch_release_task_struct(struct task_struct *tsk); >>>>>> #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ >>>>>> #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ >>>>>> #define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ >>>>>> -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ >>>>>> +#define TIF_NEED_RESCHED_LAZY 8 >>>>>> #define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ >>>>>> #define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ >>>>>> #define TIF_SECCOMP 11 /* syscall secure computing */ >>>>>> #define TIF_SYSCALL_EMU 12 /* syscall emulation active */ >>>>>> -#define TIF_NEED_RESCHED_LAZY 13 >>>>>> +#define TIF_SYSCALL_TRACE 13 /* syscall trace active */ >>>>>> #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ >>>>>> #define TIF_FREEZE 19 >>>>>> #define TIF_RESTORE_SIGMASK 20 >>>>>> >>>>>> Would that be acceptable? With that we ensure the bits in >>>>>> _TIF_WORK_MASK are contiguous and within the 8 bits limit you >>>>>> mentioned. And TIF_SYSCALL_TRACE did not seem to have any (build) >>>>>> problem with the new value. >>>>> >>>>> That should work too, the _TIF_WORK_MASK bits being in the lower 8 bits >>>>> is really all we should care about. >>>> >>>> Jens, Salvatore, Mike, I ran a few tests and confirmed that the current asm >>>> code is not restricted to 8 bits. The problems is that there is a >>>> requirement for the mask bits to be contiguous in that specific context. >>> >>> Just to confirm from the arm64 side, the instruction using this just requires >>> the bits to be contiguous, there's no restriction on *which* bits those are. >> >> Thank you, that's really helpful! >> >>> If you're going to mess around with the arm64 bits, please could you Cc someone >>> form the arm64 side? e.g. I fixed a similar issue in mainline in commit: >>> >>> 870d16757ba8918c ("arm64: make _TIF_WORK_MASK bits contiguous") >>> >>> ... and either Will Deacon or Catalin Marinas may have had comments as they're >>> the arm64 maintainers... >> >> Just to avoid confusion here, this change is specific to the v5.10-rt, not >> applicable upstream nor to newer RT. We only saw the problem because >> TIF_NOTIFY_SIGNAL was mapped to a bit used by TIF_NEED_RESCHED_LAZY in >> v5.10-rt (the PREEMPT_RT changes on top of stable v5.10). This is why >> nobody from the arm64 side was copied initially, as we were trying to >> assert what was the problem. > > Sure, and sorry, I think my reply came across a bit stronger than I intended. I > probably should have said something like: "please feel free to rope in one of > us from the arm64 side". > > I know from experience that this area is fairly subtle, and I'd like to help to > ensure that the fix doesn't introduce a subtle breakage or interact poorly with > future backports. > >>>> The explanation from commit b5a5a01d8e9a ("arm64: uaccess: remove >>>> addr_limit_user_check()") describes quite well our case: >>>> >>>> To ensure that _TIF_WORK_MASK can be used as an immediate value in an >>>> AND instruction (as it is in `ret_to_user`), TIF_MTE_ASYNC_FAULT is >>>> renumbered to keep the constituent bits of _TIF_WORK_MASK contiguous. >>>> >>>> My question is: do you prefer renumbering the bits or the neat asm hack >>>> that Mike proposed? >>> >>> I would strongly recommend renumbering the bits over changing the asm. That's >>> going to be closer to what mainline has already done, and it avoids introducing >>> weird ifdeffery. >>> >>> That said, rather than swapping TIF_SYSCALL_TRACE and TIF_NEED_RESCHED_LAZY, >>> you could just shuffle the bits down-by-one, keeping all the existing >>> contiguity, e.g. >>> >>> #define TIF_NEED_RESCHED_LAZY 8 >>> #define TIF_SYSCALL_TRACE 9 >>> #define TIF_SYSCALL_AUDIT 10 >>> #define TIF_SYSCALL_TRACEPOINT 11 >>> >>> ... and so on. >> >> Would something like this be a good interpretation of your suggestion? >> >> diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h >> index 6eb36a212..2afd9ceb6 100644 >> --- a/arch/arm64/include/asm/thread_info.h >> +++ b/arch/arm64/include/asm/thread_info.h >> @@ -70,12 +70,12 @@ void arch_release_task_struct(struct task_struct *tsk); >> #define TIF_FSCHECK 5 /* Check FS is USER_DS on return */ >> #define TIF_MTE_ASYNC_FAULT 6 /* MTE Asynchronous Tag Check Fault */ >> #define TIF_NOTIFY_SIGNAL 7 /* signal notifications exist */ >> -#define TIF_SYSCALL_TRACE 8 /* syscall trace active */ >> -#define TIF_SYSCALL_AUDIT 9 /* syscall auditing */ >> -#define TIF_SYSCALL_TRACEPOINT 10 /* syscall tracepoint for ftrace */ >> -#define TIF_SECCOMP 11 /* syscall secure computing */ >> -#define TIF_SYSCALL_EMU 12 /* syscall emulation active */ >> -#define TIF_NEED_RESCHED_LAZY 13 >> +#define TIF_NEED_RESCHED_LAZY 8 >> +#define TIF_SYSCALL_TRACE 9 /* syscall trace active */ >> +#define TIF_SYSCALL_AUDIT 10 /* syscall auditing */ >> +#define TIF_SYSCALL_TRACEPOINT 11 /* syscall tracepoint for ftrace */ >> +#define TIF_SECCOMP 12 /* syscall secure computing */ >> +#define TIF_SYSCALL_EMU 13 /* syscall emulation active */ > I can confirm v5.10.162-rt179 which has above fix builds fine for arm64 defconfig. Thanks everyone addressing this issue! Regards Vignesh ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ANNOUNCE] 5.10.162-rt78 2023-01-19 23:09 ` Jens Axboe 2023-01-20 3:44 ` Luis Claudio R. Goncalves @ 2023-01-20 6:01 ` Mike Galbraith 1 sibling, 0 replies; 20+ messages in thread From: Mike Galbraith @ 2023-01-20 6:01 UTC (permalink / raw) To: Jens Axboe, Salvatore Bonaccorso, Luis Claudio R. Goncalves Cc: Pavel Machek, Vignesh Raghavendra, LKML, linux-rt-users, stable-rt, Steven Rostedt, Thomas Gleixner, Carsten Emde, Sebastian Andrzej Siewior, Daniel Wagner, Tom Zanussi, Clark Williams, Mark Gross, Jeff Brady On Thu, 2023-01-19 at 16:09 -0700, Jens Axboe wrote: > > I guess we need to twiddle that asm to deal with eg 16 bits, rather than > attempt to backport any TIF removal patches. Hm, 'mov' gets past the weird ass rules committee, so seems it should be trivial for someone who speaks arm. This built/booted once on rpi4. diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index d5bc1dbdd2fd..a4931bff8ea9 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -751,7 +760,12 @@ SYM_CODE_START_LOCAL(ret_to_user) bl trace_hardirqs_off #endif ldr x19, [tsk, #TSK_TI_FLAGS] +#ifndef CONFIG_PREEMPT_RT and x2, x19, #_TIF_WORK_MASK +#else + mov x2, #_TIF_WORK_MASK + and x2, x19, x2 +#endif cbnz x2, work_pending finish_ret_to_user: user_enter_irqoff ^ permalink raw reply related [flat|nested] 20+ messages in thread
end of thread, other threads:[~2023-01-28 8:25 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-01-16 13:35 [ANNOUNCE] 5.10.162-rt78 Luis Claudio R. Goncalves 2023-01-19 8:32 ` Vignesh Raghavendra 2023-01-19 11:38 ` Pavel Machek 2023-01-19 12:37 ` Pavel Machek 2023-01-19 13:16 ` Luis Claudio R. Goncalves 2023-01-19 21:03 ` Salvatore Bonaccorso 2023-01-19 23:09 ` Jens Axboe 2023-01-20 3:44 ` Luis Claudio R. Goncalves 2023-01-20 3:49 ` Jens Axboe 2023-01-20 5:36 ` Salvatore Bonaccorso 2023-01-20 10:01 ` Daniel Wagner 2023-01-20 14:48 ` Jens Axboe 2023-01-20 12:51 ` Luis Claudio R. Goncalves 2023-01-20 13:04 ` Sebastian Andrzej Siewior 2023-01-20 15:37 ` Mark Rutland 2023-01-20 18:25 ` Luis Claudio R. Goncalves 2023-01-20 18:38 ` Salvatore Bonaccorso 2023-01-23 16:32 ` Mark Rutland 2023-01-28 8:24 ` Raghavendra, Vignesh 2023-01-20 6:01 ` Mike Galbraith
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).