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

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

Quoted 11 lines · 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.

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.

Quoted 2 lines

Best regards,
Luis

Sebastian

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.

Hello,

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

Quoted 5 lines

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

Quoted 4 lines

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 ;)

Quoted 7 lines

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 2 lines

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

Quoted 5 lines · Bryan Brattlof

Quoted 2 lines

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?

Quoted 2 lines

~Bryan

Sebastian

Quoted 9 lines · Sebastian Andrzej Siewior

Quoted 5 lines · Bryan Brattlof

Quoted 2 lines

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

Quoted 28 lines · Luis Claudio R. Goncalves

Quoted 9 lines · Sebastian Andrzej Siewior

Quoted 5 lines · Bryan Brattlof

Quoted 2 lines

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"

Quoted 1 line

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.

Best
Luis

Quoted 9 lines · Bryan Brattlof

Quoted 5 lines

Quoted 2 lines

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?

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