From: "Luis Claudio R. Goncalves" <lgoncalv@redhat.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Salvatore Bonaccorso <carnil@debian.org>,
Pavel Machek <pavel@denx.de>,
Vignesh Raghavendra <vigneshr@ti.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-rt-users <linux-rt-users@vger.kernel.org>,
stable-rt <stable-rt@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
Carsten Emde <C.Emde@osadl.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Daniel Wagner <daniel.wagner@suse.com>,
Tom Zanussi <tom.zanussi@linux.intel.com>,
Clark Williams <williams@redhat.com>,
Mark Gross <markgross@kernel.org>,
Jeff Brady <jeffreyjbrady@gmail.com>
Subject: Re: [ANNOUNCE] 5.10.162-rt78
Date: Fri, 20 Jan 2023 00:44:15 -0300 [thread overview]
Message-ID: <Y8oNTkUVDr7iQWzp@uudg.org> (raw)
In-Reply-To: <a4f62523-b01e-3986-7914-767f999b4153@kernel.dk>
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---
next prev parent reply other threads:[~2023-01-20 3:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y8oNTkUVDr7iQWzp@uudg.org \
--to=lgoncalv@redhat.com \
--cc=C.Emde@osadl.org \
--cc=axboe@kernel.dk \
--cc=bigeasy@linutronix.de \
--cc=carnil@debian.org \
--cc=daniel.wagner@suse.com \
--cc=jeffreyjbrady@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=markgross@kernel.org \
--cc=pavel@denx.de \
--cc=rostedt@goodmis.org \
--cc=stable-rt@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tom.zanussi@linux.intel.com \
--cc=vigneshr@ti.com \
--cc=williams@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox