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

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