I'm pleased to announce the 5.10.162-rt79 stable release.
This release contains a single change, a fix to the aarch64 build failure
I introduced while fixing merge conflicts in 5.10.162-rt78.
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: 10ea07eb47e2f5a82c5dabba993635c73c11592f
Or to build 5.10.162-rt79 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-rt79.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
Changes from v5.10.162-rt78:
---
Luis Claudio R. Goncalves (1):
Linux 5.10.162-rt79
Salvatore Bonaccorso (1):
rt: arm64: make _TIF_WORK_MASK bits contiguous
---
arch/arm64/include/asm/thread_info.h | 12 ++++++------
localversion-rt | 2 +-
2 files changed, 7 insertions(+), 7 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
diff --git a/localversion-rt b/localversion-rt
index 30758e0b2242..cf94a551bf32 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt78
+-rt79
Hi all, especially to stable-rt maintainers,
On Thu, 2023-01-26 at 11:31 -0300, Luis Claudio R. Goncalves wrote:
> I'm pleased to announce the 5.10.162-rt79 stable release.
>
> This release contains a single change, a fix to the aarch64 build failure
> I introduced while fixing merge conflicts in 5.10.162-rt78.
The CIP (see [1] for technical infos about CIP) kernel maintainers
(especially Pavel) noticed this build failure while trying to prepare
the next 5.10 based rt-cip release.
Looking at the kernel CI logs [2] this build failure was detected by
kernel-ci as well but it seems the build result did not make it back to
the maintainers. Is that correct?
From the CIP projects perspective we would like to improve the
situation.
From my perspective the following could be done:
- Instead of (or in addition to) building and testing released -rt
branches enable testing of -rt release candidates
- Make sure the build results get back to the maintainers
I'm not sure if every -rt branch has a -rc branch. I'm not familiar
with the -rt release process yet.
What do you think? Does that make sense?
The discussion did not start yet, but it might be possible that I'm
able to do such kernel-ci improvements under the CIP umbrella.
Best regards,
Florian
[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/start
[2] https://linux.kernelci.org/build/rt-stable/branch/v5.10-rt/kernel/v5.10.162-rt78/
>
> 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: 10ea07eb47e2f5a82c5dabba993635c73c11592f
>
Hi Florian,
On Thu, Jan 26, 2023 at 06:41:27PM +0100, Florian Bezdeka wrote:
> From the CIP projects perspective we would like to improve the
> situation.
>
> From my perspective the following could be done:
>
> - Instead of (or in addition to) building and testing released -rt
> branches enable testing of -rt release candidates
> - Make sure the build results get back to the maintainers
>
> I'm not sure if every -rt branch has a -rc branch. I'm not familiar
> with the -rt release process yet.
The process so far is, that every stable maintainer updates his tree (merges the
stable tree) and does a local build and local tests. Usually when merging latest
upstream stable release there are no or little fallouts. When the maintainer is
happy he does the release by pushing the changes to the usptream branch. The
release candiates come only into play when there is something the maintainer is
not sure how to handle or -rt patches are backported which need some more eyes
to look on. That means Sebastian's approval :)
IIRC, I did give a presentation on the workflow some time ago...
https://lpc.events/event/4/contributions/293/attachments/237/416/maintaining-out-of-tree-patches-over-the-long-term.pdf
https://www.youtube.com/watch?v=2ab4Knwlmo4
When we started with this process kernelci didn't build these branches but that
is long time ago.
Personally, I don't mind doing an official -rc for every release and getting
some additional builds and tests run by kernelci.
Though just piping the results back is the easy thing, the time consuming task
is to fix those problems. Do you plan to help out here?
Thanks,
Daniel
On Thu, 2023-02-23 at 15:33 +0100, Daniel Wagner wrote:
> Hi Florian,
>
> On Thu, Jan 26, 2023 at 06:41:27PM +0100, Florian Bezdeka wrote:
> > From the CIP projects perspective we would like to improve the
> > situation.
> >
> > From my perspective the following could be done:
> >
> > - Instead of (or in addition to) building and testing released -rt
> > branches enable testing of -rt release candidates
> > - Make sure the build results get back to the maintainers
> >
> > I'm not sure if every -rt branch has a -rc branch. I'm not familiar
> > with the -rt release process yet.
>
> The process so far is, that every stable maintainer updates his tree (merges the
> stable tree) and does a local build and local tests. Usually when merging latest
> upstream stable release there are no or little fallouts. When the maintainer is
> happy he does the release by pushing the changes to the usptream branch. The
> release candiates come only into play when there is something the maintainer is
> not sure how to handle or -rt patches are backported which need some more eyes
> to look on. That means Sebastian's approval :)
Ok, so there are no automated test for each release.
>
> IIRC, I did give a presentation on the workflow some time ago...
>
> https://lpc.events/event/4/contributions/293/attachments/237/416/maintaining-out-of-tree-patches-over-the-long-term.pdf
> https://www.youtube.com/watch?v=2ab4Knwlmo4
Thanks for the hint!
>
> When we started with this process kernelci didn't build these branches but that
> is long time ago.
At least (some) stable release branches are being build now but it
seems that nobody is caring about the result. That's one of the things
I would like to address.
>
> Personally, I don't mind doing an official -rc for every release and getting
> some additional builds and tests run by kernelci.
Ok, but that would be something that "all" -rt-stable maintainers
should agree on, no? At least to some degree to make the testing part
consistent.
>
> Though just piping the results back is the easy thing, the time consuming task
> is to fix those problems. Do you plan to help out here?
Well, having the pipelines might be easy, but we don't have them yet,
right? Reacting on the pipeline results would be the next step that
possibly could happen in cooperation with the CIP project.
But yes, generally speaking we want to help. But we don't have infinite
resources (as usual), so we'd like to know where most impact could be
achieved.
Are there any plans to build and test the stable -rt branches with the
help of automation, for example by using the kernelci infrastructure?
If no: Would that be something that the RT project is interested in?
I'm asking for kernelci because the CIP project is already using that.
They defined a clear set of supported architectures, kernel configs,
test suites and concrete hardware (to some degree). This allows them to
make sure each release candidate of each branch is in good shape before
doing the actual release.
Regards,
Florian
>
> Thanks,
> Daniel