Question about the maintenance of OOT RT patches for LTS releases (v12.x and v18.x)

Question about the maintenance of OOT RT patches for LTS releases (v12.x and v18.x)

[Luis Claudio R. Goncalves]

Hello!

The question is simple:

   Should we have somebody maintaining the OOT RT patches for v12.x and v18.x,
   the LTS versions that already have PREEMPT_RT in-tree?

As we still have a few OOT patches, after a while, people using PREEMPT_RT on
those versions may encounter conflicts trying to apply the old patches. And
as those patches are not in-tree, the fixes won't probably be routed via
Stable.

Best regards,
Luis

Re: Question about the maintenance of OOT RT patches for LTS releases (v12.x and v18.x)

[Sebastian Andrzej Siewior]

On 2026-06-22 13:11:59 [-0300], Luis Claudio R. Goncalves wrote:
> Hello!
> 
> The question is simple:
> 
>    Should we have somebody maintaining the OOT RT patches for v12.x and v18.x,
>    the LTS versions that already have PREEMPT_RT in-tree?
> 
> As we still have a few OOT patches, after a while, people using PREEMPT_RT on
> those versions may encounter conflicts trying to apply the old patches. And
> as those patches are not in-tree, the fixes won't probably be routed via
> Stable.

For 6.18, we have:
- 8250 console
- i915
- arm-32
- powerpc

For 6.12, we have additionally
- ktimers thread
- the whole lazy-preempt

So for v6.12 there are bits outstanding which can impact you.
For v6.18 if you are on arm64 then the mainline version is slightly
better than on x86 because on arm64 you might be using the pl011 UART
which has nbcon support since v6.15 while on x86 you almost always have
the 8250 which is not yet with nbcon support in-tree.

These are the missing bits. None of them are essential. If you on x86
and your kernel crashes, it is more likely to see a backtrace with nbcon
driver than without it.

> Best regards,
> Luis

Sebastian

Re: Question about the maintenance of OOT RT patches for LTS releases (v12.x and v18.x)

[Luis Claudio R. Goncalves]

On Wed, Jun 24, 2026 at 08:49:44AM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-06-22 13:11:59 [-0300], Luis Claudio R. Goncalves wrote:
> > Hello!
> > 
> > The question is simple:
> > 
> >    Should we have somebody maintaining the OOT RT patches for v12.x and v18.x,
> >    the LTS versions that already have PREEMPT_RT in-tree?
> > 
> > As we still have a few OOT patches, after a while, people using PREEMPT_RT on
> > those versions may encounter conflicts trying to apply the old patches. And
> > as those patches are not in-tree, the fixes won't probably be routed via
> > Stable.
> 
> For 6.18, we have:
> - 8250 console
> - i915
> - arm-32
> - powerpc
> 
> For 6.12, we have additionally
> - ktimers thread
> - the whole lazy-preempt

I need to correct myself here, our local hero Daniel Wagner is maintaining
the v6.12-rt version. Sorry for that :)

Sebastian, just to make sure I understood your answer, then we don't need
to keep the OOT patches up-to-date for v6.18-rt specifically? My question
came from comments raised on the last two RT maintainers meetings and the
LF RT Board meeting. I just want to have a good answer if somebody else
asks about that. And to volunteer if work is needed.

Best,
Luis
 
> So for v6.12 there are bits outstanding which can impact you.
> For v6.18 if you are on arm64 then the mainline version is slightly
> better than on x86 because on arm64 you might be using the pl011 UART
> which has nbcon support since v6.15 while on x86 you almost always have
> the 8250 which is not yet with nbcon support in-tree.
> 
> These are the missing bits. None of them are essential. If you on x86
> and your kernel crashes, it is more likely to see a backtrace with nbcon
> driver than without it.
> 
> > Best regards,
> > Luis
> 
> Sebastian
> 
---end quoted text---

Re: Question about the maintenance of OOT RT patches for LTS releases (v12.x and v18.x)

[Alexander Dahl]

Hello,

just adding one datapoint here in case someone is wondering if there
are users out there? ;-)

Am Wed, Jun 24, 2026 at 08:14:51AM -0300 schrieb Luis Claudio R. Goncalves:
> I need to correct myself here, our local hero Daniel Wagner is maintaining
> the v6.12-rt version. Sorry for that :)

Good to know.  Thank you for maintaing it for v6.12. :-)

> Sebastian, just to make sure I understood your answer, then we don't need
> to keep the OOT patches up-to-date for v6.18-rt specifically? My question
> came from comments raised on the last two RT maintainers meetings and the
> LF RT Board meeting. I just want to have a good answer if somebody else
> asks about that. And to volunteer if work is needed.

We still use v6.12 LTS with PREEMPT_RT on arm32 (at91),
and plan to use PREEMPT_RT on at91 (sam9x60, sama5d2) in the future.

If there are no regular patches for v6.18 we will probably skip that
and use the LTS coming later this year.

Greets
Alex

Re: Question about the maintenance of OOT RT patches for LTS releases (v12.x and v18.x)

[Sebastian Andrzej Siewior]

On 2026-06-24 08:14:51 [-0300], Luis Claudio R. Goncalves wrote:
> Sebastian, just to make sure I understood your answer, then we don't need
> to keep the OOT patches up-to-date for v6.18-rt specifically? My question

I did update v6.18 recently. I do think at the very least the 8250 bits
are important in case something goes wrong.

> came from comments raised on the last two RT maintainers meetings and the
> LF RT Board meeting. I just want to have a good answer if somebody else
> asks about that. And to volunteer if work is needed.

There isn't a lot that clashes in v6.12 and it is even less in v6.18.
However the printk/ serial changes in v6.18 caused some fallout exactly
there.
Hopefully we get the 8250 bits by the end of the year including i915 and
then we have just powerpc left and that one sysfs file and we can call
it a day.

> Best,
> Luis

Sebastian

Re: Question about the maintenance of OOT RT patches for LTS releases (v12.x and v18.x)

[Sebastian Andrzej Siewior]

On 2026-06-25 09:35:19 [+0200], Alexander Dahl wrote:
> Hello,
> 
> just adding one datapoint here in case someone is wondering if there
> are users out there? ;-)

Sure. Having an update from _any_ user feels good. At least the work is
used ;)

> > Sebastian, just to make sure I understood your answer, then we don't need
> > to keep the OOT patches up-to-date for v6.18-rt specifically? My question
> > came from comments raised on the last two RT maintainers meetings and the
> > LF RT Board meeting. I just want to have a good answer if somebody else
> > asks about that. And to volunteer if work is needed.
> 
> We still use v6.12 LTS with PREEMPT_RT on arm32 (at91),
> and plan to use PREEMPT_RT on at91 (sam9x60, sama5d2) in the future.
> 
> If there are no regular patches for v6.18 we will probably skip that
> and use the LTS coming later this year.

I did assume we have v6.18 in maintenance but somehow it skipped. *I*
usually skip updates if there are no clashes and nothing changes.

> Greets
> Alex

Sebastian

Re: Question about the maintenance of OOT RT patches for LTS releases (v12.x and v18.x)

[Bryan Brattlof]

On June 25, 2026 thus sayeth Sebastian Andrzej Siewior:
> On 2026-06-25 09:35:19 [+0200], Alexander Dahl wrote:
> > Hello,
> > 
> > just adding one datapoint here in case someone is wondering if there
> > are users out there? ;-)
> 
> Sure. Having an update from _any_ user feels good. At least the work is
> used ;)

Yeah I should probably be better at thanking everyone for providing the 
stable branches. Thank you all :)

> 
> > > Sebastian, just to make sure I understood your answer, then we don't need
> > > to keep the OOT patches up-to-date for v6.18-rt specifically? My question
> > > came from comments raised on the last two RT maintainers meetings and the
> > > LF RT Board meeting. I just want to have a good answer if somebody else
> > > asks about that. And to volunteer if work is needed.
> > 
> > We still use v6.12 LTS with PREEMPT_RT on arm32 (at91),
> > and plan to use PREEMPT_RT on at91 (sam9x60, sama5d2) in the future.
> > 
> > If there are no regular patches for v6.18 we will probably skip that
> > and use the LTS coming later this year.
> 
> I did assume we have v6.18 in maintenance but somehow it skipped. *I*
> usually skip updates if there are no clashes and nothing changes.

Did we decide to skip v6.18 ? There are a few people internally asking 
me for a roadmap again with some guidance on the lifetime of the branch.

~Bryan

Re: Question about the maintenance of OOT RT patches for LTS releases (v12.x and v18.x)

[Sebastian Andrzej Siewior]

On 2026-08-19 11:30:11 [-0500], Bryan Brattlof wrote:
> > I did assume we have v6.18 in maintenance but somehow it skipped. *I*
> > usually skip updates if there are no clashes and nothing changes.
> 
> Did we decide to skip v6.18 ? There are a few people internally asking 
> me for a roadmap again with some guidance on the lifetime of the branch.

As of v6.18.45 the v6.18.37-rt6 applies as-is. Winthin the git tree, the
stable tree tag can be merged. Does this work?

> ~Bryan

Sebastian

Re: Question about the maintenance of OOT RT patches for LTS releases (v12.x and v18.x)

[Luis Claudio R. Goncalves]

On Thu, Aug 20, 2026 at 04:23:14PM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-08-19 11:30:11 [-0500], Bryan Brattlof wrote:
> > > I did assume we have v6.18 in maintenance but somehow it skipped. *I*
> > > usually skip updates if there are no clashes and nothing changes.
> > 
> > Did we decide to skip v6.18 ? There are a few people internally asking 
> > me for a roadmap again with some guidance on the lifetime of the branch.
> 
> As of v6.18.45 the v6.18.37-rt6 applies as-is. Winthin the git tree, the
> stable tree tag can be merged. Does this work?

There seems to be a conflict when applying the 8250 nbcon patches. IIRC you
fixed that conflict (or something quite close to that) on v7.1-rc.

The conflict:

$ git checkout -b test01 v6.18.37-rt6
$ git rebase -v v6.18.45
  Changes from 0c503cf3dde2e53614f05261ece12f9d3d4c3c20 to bf3be28f6721e24961992ebb9e61c0cf21a56806:
  ...
  Rebasing (1/29)
  dropping bea58d7ab5ba4367a3208ecd1854a74b66b21f51 net: gro_cells: fix lock imbalance in gro_cells_receive() -- patch contents already upstream
  Rebasing (2/29)
  Auto-merging drivers/tty/serial/8250/8250_port.c
  CONFLICT (content): Merge conflict in drivers/tty/serial/8250/8250_port.c
  Auto-merging include/linux/serial_8250.h
  error: could not apply 0b053910fa95... Reapply "serial: 8250: Switch to nbcon console"

Bryan, is this the problem you are seeing?

Luis

> 
> > ~Bryan
> 
> Sebastian
> 
---end quoted text---

Re: Question about the maintenance of OOT RT patches for LTS releases (v12.x and v18.x)

[Sebastian Andrzej Siewior]

On 2026-08-20 12:57:47 [-0300], Luis Claudio R. Goncalves wrote:
> On Thu, Aug 20, 2026 at 04:23:14PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2026-08-19 11:30:11 [-0500], Bryan Brattlof wrote:
> > > > I did assume we have v6.18 in maintenance but somehow it skipped. *I*
> > > > usually skip updates if there are no clashes and nothing changes.
> > > 
> > > Did we decide to skip v6.18 ? There are a few people internally asking 
> > > me for a roadmap again with some guidance on the lifetime of the branch.
> > 
> > As of v6.18.45 the v6.18.37-rt6 applies as-is. Winthin the git tree, the
> > stable tree tag can be merged. Does this work?
> 
> There seems to be a conflict when applying the 8250 nbcon patches. IIRC you
> fixed that conflict (or something quite close to that) on v7.1-rc.
> 
> The conflict:
> 
> $ git checkout -b test01 v6.18.37-rt6
> $ git rebase -v v6.18.45
>   Changes from 0c503cf3dde2e53614f05261ece12f9d3d4c3c20 to bf3be28f6721e24961992ebb9e61c0cf21a56806:
>   ...
>   Rebasing (1/29)
>   dropping bea58d7ab5ba4367a3208ecd1854a74b66b21f51 net: gro_cells: fix lock imbalance in gro_cells_receive() -- patch contents already upstream
>   Rebasing (2/29)
>   Auto-merging drivers/tty/serial/8250/8250_port.c
>   CONFLICT (content): Merge conflict in drivers/tty/serial/8250/8250_port.c
>   Auto-merging include/linux/serial_8250.h
>   error: could not apply 0b053910fa95... Reapply "serial: 8250: Switch to nbcon console"
> 
> Bryan, is this the problem you are seeing?

This is odd. Why does it drop "net: gro_cells: fix lock imbalance"? This
has been removed in -rt2 already.
I'm able here to merge v6.18.45 into v6.18.37-rt6 without a conflict.
Also applying the quilt queue on top v6.18.45 works.

> Luis

Sebastian

Re: Question about the maintenance of OOT RT patches for LTS releases (v12.x and v18.x)

[Luis Claudio R. Goncalves]

On Thu, Aug 20, 2026 at 06:12:46PM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-08-20 12:57:47 [-0300], Luis Claudio R. Goncalves wrote:
> > On Thu, Aug 20, 2026 at 04:23:14PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2026-08-19 11:30:11 [-0500], Bryan Brattlof wrote:
> > > > > I did assume we have v6.18 in maintenance but somehow it skipped. *I*
> > > > > usually skip updates if there are no clashes and nothing changes.
> > > > 
> > > > Did we decide to skip v6.18 ? There are a few people internally asking 
> > > > me for a roadmap again with some guidance on the lifetime of the branch.
> > > 
> > > As of v6.18.45 the v6.18.37-rt6 applies as-is. Winthin the git tree, the
> > > stable tree tag can be merged. Does this work?
> > 
> > There seems to be a conflict when applying the 8250 nbcon patches. IIRC you
> > fixed that conflict (or something quite close to that) on v7.1-rc.
> > 
> > The conflict:
> > 
> > $ git checkout -b test01 v6.18.37-rt6
> > $ git rebase -v v6.18.45
> >   Changes from 0c503cf3dde2e53614f05261ece12f9d3d4c3c20 to bf3be28f6721e24961992ebb9e61c0cf21a56806:
> >   ...
> >   Rebasing (1/29)
> >   dropping bea58d7ab5ba4367a3208ecd1854a74b66b21f51 net: gro_cells: fix lock imbalance in gro_cells_receive() -- patch contents already upstream
> >   Rebasing (2/29)
> >   Auto-merging drivers/tty/serial/8250/8250_port.c
> >   CONFLICT (content): Merge conflict in drivers/tty/serial/8250/8250_port.c
> >   Auto-merging include/linux/serial_8250.h
> >   error: could not apply 0b053910fa95... Reapply "serial: 8250: Switch to nbcon console"
> > 
> > Bryan, is this the problem you are seeing?
> 
> This is odd. Why does it drop "net: gro_cells: fix lock imbalance"? This
> has been removed in -rt2 already.
> I'm able here to merge v6.18.45 into v6.18.37-rt6 without a conflict.
> Also applying the quilt queue on top v6.18.45 works.

Sebastian, I can merge v6.18.45 into v6.18.37-rt6 too. I can not rebase
from v6.18.37-rt6 to v6.18.45. But if I repeat the process with
v6.18.37-rt6-rebase, it works fine. In any case, if that is not the
problem that prompted Bryan's email, no need to focus on that. I was just
trying to understand the reasoning behind the question and spotted the
rebase failure.

Just for reference:

$ git show v6.18.37-rt6 | grep ^commit
  commit a3c2a803731b7b3d139c45a019cf43c8759fcc93

$ git show v6.18.37-rt6-rebase | grep ^commit
  commit 2fdaf62aeab36227d0789a3132780ea74b7e06c5

$ git diff v6.18.37-rt6 v6.18.37-rt6-rebase
$ 

Best
Luis