Re: [cip-dev] Request for review for 4.19-st21, 4.19-cip137

[Ulrich Hecht <uli@fpond.eu>]

> On 11/06/2026 11:03 AM CET Pavel Machek via cip-dev <pavel=nabladev.com@lists.cip-project.org> wrote:
> > Here are the adapted backports for the upcoming 4.19 kernel release. There's a total of 95; 1 written by me, 2 by Qwen-3.8-27B and 92 by Qwen-3.8-Flash-Next. (The latter are labeled with "Assisted-by: SLTR:qwen-3.8" and "Assisted-by: SLTR:qwen-3.8-flash-next", respectively.)
> > 
> > As always they can be found in https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-st-rc
> >
> 
> Some patches are ok, Reviewed-by: Pavel Machek
> <pavel@nabladev.com>. There are some comments below.
> 
> e37dae2a4576c5, for example. That was an obvious two-liner, but it is
> quite significant locking redone after backport. I'm afraid this
> should get specific testing.

The reasoning is as follows:
```
unlike 5.10 (where SIOCGSTAMP moved to the lockless `.gettstamp` op, which 4.19 lacks), three 4.19 ioctl handlers hold the socket lock around the stamp calls and would self-deadlock with the new inner `lock_sock()`: `ax25_ioctl` (lock over whole switch), `nr_ioctl` (lock per case), `qrtr_ioctl` (lock over whole switch). These callers must be adjusted, mirroring upstream's eventual direction. All other callers (inet, inet6, packet, rose, x25, can, bluetooth, atm, appletalk, ieee802154, compat) run lockless
```

As it happens, none of the affected handlers are enabled in any CIP configs, so technically we could also a) drop the additional fixes, or b) leave them in without testing because it doesn't matter anyway.

> cbf63e3778be51 is example of different problem. That rmmod path is
> likely seriously broken in 4.19-st20. That's why it got redesign in
> mainline. It is still broken in 4.19-st21, that barrier won't fix it
> with nf_flow_table_module_exit() missing. Nobody should unload modules
> in production, and this risks regressions.

OK, there's at least two things I don't understand here:
1. Why is nf_flow_table_module_exit() missing? The patch adds it.
2. How does that risk a regression if the path doesn't work anyway and is not supposed to be used in production?

CU
Uli