Select, manage, and backport the long term stable kernels

Select, Manage, and Backport the
LongTerm Stable Kernels
林上智 (SZ LIN) szlin@debian.org
蔡鎮宇 wens@csie.org
1
Date: 2021/7/31

2
Disclaimer
• The information contained in the slide deck
represents the views and opinions of the
presenters and does not necessarily represent
the views or opinions of presenters’ past,
current, and future employers.

> 80 %
> 75 % 100 %
> 95 %
img src: https://kernel.org
src: https://www.linuxfoundation.org/about/
of the top one
million domains run
with Linux
of cloud-enabled
enterprises report
using Linux as their
primary cloud
platform
of new smartphones
sold run Android,
which is based on
the Linux kernel
of the top 500
supercomputers in
the world run on
Linux

4
Kernel Selection
Kernel Selection

5
img src: https://www.kernel.org

Mainline Kernel [1]
Mainline tree is maintained by Linus Torvalds. It's the tree where all new features are introduced
and where all the exciting new development happens. New mainline kernels are released every
2-3 months.
Mainline Kernel [1]
Mainline tree is maintained by Linus Torvalds. It's the tree where all new features are introduced
and where all the exciting new development happens. New mainline kernels are released every
2-3 months.

Stable Kernel [1]
After each mainline kernel is released, it is considered "stable." Any bug fixes for a stable kernel
are backported from the mainline tree and applied by a designated stable kernel maintainer.
There are usually only a few bugfix kernel releases until next mainline kernel becomes available -
- unless it is designated a "longterm maintenance kernel." Stable kernel updates are released on
as-needed basis, usually once a week.
Stable Kernel [1]
After each mainline kernel is released, it is considered "stable." Any bug fixes for a stable kernel
are backported from the mainline tree and applied by a designated stable kernel maintainer.
There are usually only a few bugfix kernel releases until next mainline kernel becomes available -
- unless it is designated a "longterm maintenance kernel." Stable kernel updates are released on
as-needed basis, usually once a week.

Longterm Kernel [1]
There are usually several "longterm maintenance" kernel releases provided for the purposes of
backporting bugfixes for older kernel trees. Only important bugfixes are applied to such kernels
and they don't usually see very frequent releases, especially for older trees.
Longterm Kernel [1]
There are usually several "longterm maintenance" kernel releases provided for the purposes of
backporting bugfixes for older kernel trees. Only important bugfixes are applied to such kernels
and they don't usually see very frequent releases, especially for older trees.

End of LTS
9
Linux Kernel Releases
Mainline
Longterm
v4.4
Longterm
6+? years
v4.5 v4.19 v5.x
EOL
v4.4.x v4.4.y v4.4.z
v4.19.a v4.19.b
img src: https://en.wikipedia.org/wiki/Linux_kernel_version_history
End of LTS
6+? years
v4.4 v4.5 v4.19
Stable

27.8
60-90 Day 66,492 3,386,347
21,074
Mainline Kernel
Release Cycle
Million Lines Files Lines of New Codes
in 2019
Different Authors
10
src: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Git-Stats-EOY2019
img src: https://kernel.org

LTS: Long Term Stable Kernel [3]
Extend software uptime for stable kernel
• Only accept bug fixes and security fixes
img: https://www.kernel.org/category/releases.html
Retrieved 7th July
11

SoC Board Support Package Kernel
• Kernel version depends on SoC vendors
– Well made but not well maintained
• Contain lots of in-house patches
– Errata patches
– Specific feature patches
– …
• Different SoC might use different versions of kernel
• The lifetime is unsure
12

LTSI: Long Term Support Initiative [6]
• Linux Foundation collaborative project
– Based on LTS
– Add another chance to include further patches on top of LTS
– Auto Test framework
– Same lifetime with LTS (yearly release and 2 years life time)
13

CIP (Civil Infrastructure Platform) [7]
• Linux Foundation collaborative project
– Support kernel and core package
– Auto Test framework
– Maintenance period
• 10 years and more (10-20 years)
14
More info: CIP Kernel Team Activities to Accomplish Super Long Term Support
Embedded Linux Conference, 2020 [8]

Linux Kernel Source Comparison Table
Version
Maintenance
Period
(years)
Features
Latest
Version
Supported Real-
time kernel
Maintainer
SoC
BSP kernel
? Bug fixes ? N SoC vendor kernel team
LTS
kernel
2 ~ ?
• Bug fixes
• Security fixes
5.10 N Kernel.org
LTSI kernel 2 ~ ?
• Bug fixes
• Security fixes
• Specific features
• New features
4.14 N
LTSI
(Linux Foundation Projects)
CIP
kernel
10 +
• Bug fixes
• Security fixes
• Specific features
• New features
5.10 Y
CIP
(Linux Foundation Projects)
15

Use Release Version Instead of Rolling Version
v4.4.1
Security fixes
Security fixes
Bug fixes
Bug fixes
Upstream
rolling version
16
v4.4.2 v4.4.3

17
Kernel Management
Kernel Management

18
img src:https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33

Supply Chain Risk Management Practices
for Federal Information Systems and
Organizations
Special Publication 800-161 [4]
SM-9: Security requirements for
externally provided components
ISA/ IEC 62443-4-1 [5] NERCCIP-010-2 [6]
Configuration Change Management and
Vulnerability Assessments
img src: https://pixabay.com/illustrations/policies-standards-compliance-4720824/
20

src: https://www.ithome.com.tw/news/138633
2020-07-07發表
21

22
Release Date Kernel 4.4 Kernel 4.9 Kernel 4.14 Kernel 4.19 Kernel 5.4 Kernel 5.10
7/20, 2021 4.4.276 4.9.276 4.14.240 4.19.198 5.4.134 5.10.52
7/19, 2021 5.4.133 5.10.51
7/14, 2021 5.4.132 5.10.50
7/11, 2021 4.4.275 4.9.275 4.14.239 4.19.197 5.4.131 5.10.49
7/7, 2021 5.4.130 5.10.48
6/30, 2021 4.4.274 4.9.274 4.14.238 4.19.196 5.4.129 5.10.47
6/23, 2021 5.4.128 5.10.46
6/18, 2021 5.4.127 5.10.45
6/16, 2021 4.4.273 4.9.273 4.14.237 4.19.195 5.4.126 5.10.44
6/10, 2021 4.4.272 4.9.272 4.14.236 4.19.194 5.4.125 5.10.43
6/3, 2021 4.4.271 4.9.271 4.14.235 4.19.193 5.4.124 5.10.42

23
Proactive Management
- Monitor the status of stable kernel by subscribing
the mailing list
• http://vger.kernel.org/vger-lists.html#stable
From Greg Kroah-Hartman <>
Subject [PATCH 5.10 000/243] 5.10.52-rc1 review
Date Mon, 19 Jul 2021 16:50:29 +0200
This is the start of the stable review cycle for the 5.10.52 release.
There are 243 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed, 21 Jul 2021 14:47:42 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.52-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 5.10.52-rc1
Dan Carpenter <dan.carpenter@oracle.com>
scsi: scsi_dh_alua: Fix signedness bug in alua_rtpg()
…
From Greg Kroah-Hartman <>
Subject [PATCH 5.10 000/243] 5.10.52-rc1 review
Date Mon, 19 Jul 2021 16:50:29 +0200
This is the start of the stable review cycle for the 5.10.52 release.
There are 243 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed, 21 Jul 2021 14:47:42 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.52-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 5.10.52-rc1
Dan Carpenter <dan.carpenter@oracle.com>
scsi: scsi_dh_alua: Fix signedness bug in alua_rtpg()
…

24
From "kernelci.org bot" <bot@xxxxxxxxxxxx>
Subject stable-rc/queue/5.10 baseline: 189 runs, 7 regressions (v5.10.51-362-
g3c5cb67dccf3)
Date Fri, 23 Jul 2021 21:46:18 -0700 (PDT)
stable-rc/queue/5.10 baseline: 189 runs, 7 regressions (v5.10.51-362-g3c5cb67dccf3)
Regressions Summary
-------------------
platform | arch | lab | compiler | defconfig | regressions
------------------------+-------+---------------+----------+--------------------+------------
bcm2837-rpi-3-b-32 | arm | lab-baylibre | gcc-8 | bcm2835_defconfig | 1
meson-gxm-q200 | arm64 | lab-baylibre | gcc-8 | defconfig | 2
rk3288-veyron-jaq | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 3
sun50i-a64-bananapi-m64 | arm64 | lab-clabbe | gcc-8 | defconfig | 1
Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F5.10/kernel/v5.10.51-362-
g3c5cb67dccf3/plan/baseline/
Test: baseline
Tree: stable-rc
Branch: queue/5.10
Describe: v5.10.51-362-g3c5cb67dccf3
URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
SHA: 3c5cb67dccf32b3b2349007ca5b3551bfb9b9864
Test Regressions
----------------
------------------------+-------+---------------+----------+--------------------+------------
…
From "kernelci.org bot" <bot@xxxxxxxxxxxx>
Subject stable-rc/queue/5.10 baseline: 189 runs, 7 regressions (v5.10.51-362-
g3c5cb67dccf3)
Date Fri, 23 Jul 2021 21:46:18 -0700 (PDT)
stable-rc/queue/5.10 baseline: 189 runs, 7 regressions (v5.10.51-362-g3c5cb67dccf3)
Regressions Summary
-------------------
------------------------+-------+---------------+----------+--------------------+------------
meson-gxm-q200 | arm64 | lab-baylibre | gcc-8 | defconfig | 2
rk3288-veyron-jaq | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 3
sun50i-a64-bananapi-m64 | arm64 | lab-clabbe | gcc-8 | defconfig | 1
Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F5.10/kernel/v5.10.51-362-
g3c5cb67dccf3/plan/baseline/
Test: baseline
Tree: stable-rc
Branch: queue/5.10
Describe: v5.10.51-362-g3c5cb67dccf3
URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
SHA: 3c5cb67dccf32b3b2349007ca5b3551bfb9b9864
Test Regressions
----------------
------------------------+-------+---------------+----------+--------------------+------------
…
Proactive Management
- Monitor the status of stable kernel by subscribing
the mailing list
• http://vger.kernel.org/vger-lists.html#stable

25
2cd5fe24a7f0 Linux 5.10.52
174c34d9cda1 seq_file: disallow extremely large seq buffer allocations
b33aa0dbd72f scsi: scsi_dh_alua: Fix signedness bug in alua_rtpg()
e09c9b558436 MIPS: vdso: Invalid GIC access through VDSO
20f79ce2b1ab mips: disable branch profiling in boot/decompress.o
4e2764e96a15 mips: always link byteswap helpers into decompressor
53c5c2496fc9 static_call: Fix static_call_text_reserved() vs __init
59ae35884c5e jump_label: Fix jump_label_text_reserved() vs __init
143a6b8ec5c6 sched/uclamp: Ignore max aggregation if rq is idle
43b89ef7bc4a scsi: be2iscsi: Fix an error handling path in beiscsi_dev_probe()
f71f13034f3b arm64: dts: rockchip: Re-add regulator-always-on for vcc_sdio for rk3399-roc-pc
b3231050c75c arm64: dts: rockchip: Re-add regulator-boot-on, regulator-always-on for vdd_gpu on rk3399-roc-pc
9436e9001d40 firmware: turris-mox-rwtm: show message about HWRNG registration
b2a5949a91a7 firmware: turris-mox-rwtm: fail probing when firmware does not support hwrng
ddf380b0941f firmware: turris-mox-rwtm: report failures better
271c12dbeb62 firmware: turris-mox-rwtm: fix reply status decoding function
804aabb50990 thermal/drivers/rcar_gen3_thermal: Fix coefficient calculations
dae777523234 ARM: dts: imx6q-dhcom: Add gpios pinctrl for i2c bus recovery
936446f15aef ARM: dts: imx6q-dhcom: Fix ethernet plugin detection problems
f12a456f1c3b ARM: dts: imx6q-dhcom: Fix ethernet reset time properties
b1995806d008 thermal/drivers/sprd: Add missing MODULE_DEVICE_TABLE
4d9ea2858607 ARM: dts: am437x: align ti,pindir-d0-out-d1-in property with dt-shema
6641724d68fd ARM: dts: am335x: align ti,pindir-d0-out-d1-in property with dt-shema
0724764c085a ARM: dts: dra7: Fix duplicate USB4 target module node
6cd58375c532 arm64: dts: allwinner: a64-sopine-baseboard: change RGMII mode to TXID
b5789e23773f memory: fsl_ifc: fix leak of private memory on probe failure
8d071d270afb memory: fsl_ifc: fix leak of IO mapping on probe failure
1479998d8027 arm64: dts: ti: k3-j721e-main: Fix external refclk input to SERDES
668ca468702e arm64: dts: renesas: r8a779a0: Drop power-domains property from GIC node
884d09d1f18c reset: bail if try_module_get() fails
8c07e1a8c57c ARM: dts: BCM5301X: Fixup SPI binding
db4e87ab60e8 dt-bindings: i2c: at91: fix example for scl-gpios
4b4c61049ec5 firmware: arm_scmi: Reset Rx buffer to max size during async commands
c381e695cfcd firmware: tegra: Fix error return code in tegra210_bpmp_init()
f58a3bc94aae arm64: dts: qcom: trogdor: Add no-hpd to DSI bridge node
d99524d13df9 ARM: dts: stm32: Rework LAN8710Ai PHY reset on DHCOM SoM
91df7f4a0410 ARM: dts: stm32: Connect PHY IRQ line on DH STM32MP1 SoM
c4218acd688e arm64: dts: renesas: r8a7796[01]: Fix OPP table entry voltages
2cd5fe24a7f0 Linux 5.10.52
174c34d9cda1 seq_file: disallow extremely large seq buffer allocations
b33aa0dbd72f scsi: scsi_dh_alua: Fix signedness bug in alua_rtpg()
e09c9b558436 MIPS: vdso: Invalid GIC access through VDSO
20f79ce2b1ab mips: disable branch profiling in boot/decompress.o
4e2764e96a15 mips: always link byteswap helpers into decompressor
53c5c2496fc9 static_call: Fix static_call_text_reserved() vs __init
59ae35884c5e jump_label: Fix jump_label_text_reserved() vs __init
143a6b8ec5c6 sched/uclamp: Ignore max aggregation if rq is idle
43b89ef7bc4a scsi: be2iscsi: Fix an error handling path in beiscsi_dev_probe()
f71f13034f3b arm64: dts: rockchip: Re-add regulator-always-on for vcc_sdio for rk3399-roc-pc
b3231050c75c arm64: dts: rockchip: Re-add regulator-boot-on, regulator-always-on for vdd_gpu on rk3399-roc-pc
9436e9001d40 firmware: turris-mox-rwtm: show message about HWRNG registration
b2a5949a91a7 firmware: turris-mox-rwtm: fail probing when firmware does not support hwrng
ddf380b0941f firmware: turris-mox-rwtm: report failures better
271c12dbeb62 firmware: turris-mox-rwtm: fix reply status decoding function
804aabb50990 thermal/drivers/rcar_gen3_thermal: Fix coefficient calculations
dae777523234 ARM: dts: imx6q-dhcom: Add gpios pinctrl for i2c bus recovery
936446f15aef ARM: dts: imx6q-dhcom: Fix ethernet plugin detection problems
f12a456f1c3b ARM: dts: imx6q-dhcom: Fix ethernet reset time properties
b1995806d008 thermal/drivers/sprd: Add missing MODULE_DEVICE_TABLE
4d9ea2858607 ARM: dts: am437x: align ti,pindir-d0-out-d1-in property with dt-shema
6641724d68fd ARM: dts: am335x: align ti,pindir-d0-out-d1-in property with dt-shema
0724764c085a ARM: dts: dra7: Fix duplicate USB4 target module node
6cd58375c532 arm64: dts: allwinner: a64-sopine-baseboard: change RGMII mode to TXID
b5789e23773f memory: fsl_ifc: fix leak of private memory on probe failure
8d071d270afb memory: fsl_ifc: fix leak of IO mapping on probe failure
1479998d8027 arm64: dts: ti: k3-j721e-main: Fix external refclk input to SERDES
668ca468702e arm64: dts: renesas: r8a779a0: Drop power-domains property from GIC node
884d09d1f18c reset: bail if try_module_get() fails
8c07e1a8c57c ARM: dts: BCM5301X: Fixup SPI binding
db4e87ab60e8 dt-bindings: i2c: at91: fix example for scl-gpios
4b4c61049ec5 firmware: arm_scmi: Reset Rx buffer to max size during async commands
c381e695cfcd firmware: tegra: Fix error return code in tegra210_bpmp_init()
f58a3bc94aae arm64: dts: qcom: trogdor: Add no-hpd to DSI bridge node
d99524d13df9 ARM: dts: stm32: Rework LAN8710Ai PHY reset on DHCOM SoM
91df7f4a0410 ARM: dts: stm32: Connect PHY IRQ line on DH STM32MP1 SoM
c4218acd688e arm64: dts: renesas: r8a7796[01]: Fix OPP table entry voltages
Reactive Management
- Check the difference between the sublevel
in the source code if needed
• git log --oneline v5.10.52...v5.10.51

Kernel inside the organization
Upstream
27
v4.4.1

In-house security or
bug patches
bug patches
Upstream
28
v4.4.1
v4.4.1

Security fixes
Security fixes
Bug fixes
Bug fixes
Upstream
29
v4.4.1 v4.4.2
v4.4.1
bug patches
bug patches

Security fixes
Security fixes
bug patches
bug patches
Bug fixes
Bug fixes
Upstream
30
v4.4.1 v4.4.2
v4.4.1 v4.4.2

Security fixes
Security fixes
bug patches
bug patches
Bug fixes
Bug fixes
Upstream
31
v4.4.1 v4.4.2
Security fixes
Security fixes
v4.4.3
v4.4.1 v4.4.2 v4.4.3

Security fixes
Security fixes
bug patches
bug patches
Bug fixes
Bug fixes
Upstream
32
v4.4.1 v4.4.2
Security fixes
Security fixes
v4.4.3
v4.4.1 v4.4.2 v4.4.3

Security fixes
Security fixes
bug patches
bug patches
Bug fixes
Bug fixes
Upstream
33
v4.4.1 v4.4.2
Security fixes
Security fixes
v4.4.3
v4.4.1 v4.4.2 v4.4.3

• The project shares its results with the upstream
• The project fulfills longer time maintenance and
security fixes
• The project develops their code very quickly
• The project faces difficulties to backport upstream
patches due to conflicts as time goes by
34

35
Kernel Backport
Kernel Backport

36
Suitable changes in LongTerm Stable Kernels [10]
1. It must be obviously correct and tested.
2. It cannot be bigger than 100 lines, with context.
3. It must fix only one thing.
4. It must fix a real bug that bothers people (not a, “This could be a problem…” type thing).
5. It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang,
data corruption, a real security issue, or some “oh, that's not good” issue. In short, something critical.
6. Serious issues as reported by a user of a distribution kernel may also be considered if they fix a notable
performance or interactivity issue. As these fixes are not as obvious and have a higher risk of a subtle
regression they should only be submitted by a distribution kernel maintainer and include an addendum linking
to a bugzilla entry if it exists and additional information on the user-visible impact.
7. New device IDs and quirks are also accepted.
8. No “theoretical race condition” issues, unless an explanation of how the race can be exploited is also provided.
9. It cannot contain any “trivial” fixes in it (spelling changes, whitespace cleanups, etc).
10. It must follow the Documentation/Submitting Patches rules.
11. It or an equivalent fix must already exist in Linus' tree (upstream).
In practice, exceptions are sometimes made to rules 2, 3, 8 and 9, and we will likewise treat those as should rather than must rules.

37
Option 1. To have the patch automatically included in
the stable tree, add the tag
Subject: USB: serial: digi_acceleport: fix write-wakeup deadlocks
The driver must not call tty_wakeup() while holding its private lock as
line disciplines are allowed to call back into write() from
write_wakeup(), leading to a deadlock.
Also remove the unneeded work struct that was used to defer wakeup in
order to work around a possible race in ancient times (see comment about
n_tty write_chan() in commit 14b54e3 ("USB: serial: remove
changelogs and old todo entries")).
Fixes: 1da177e ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Subject: USB: serial: digi_acceleport: fix write-wakeup deadlocks
The driver must not call tty_wakeup() while holding its private lock as
line disciplines are allowed to call back into write() from
write_wakeup(), leading to a deadlock.
Also remove the unneeded work struct that was used to defer wakeup in
order to work around a possible race in ancient times (see comment about
n_tty write_chan() in commit 14b54e3 ("USB: serial: remove
changelogs and old todo entries")).
Fixes: 1da177e ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
src: https://github.com/torvalds/linux/commit/5098e77962e7c8947f87bd8c5869c83e000a522a
Procedure for submitting patches to the -stable tree [9]

38
Option 2. After the patch has been merged to Linus’
tree, send an email
to stable@vger.kernel.org containing the subject of
the patch, the commit ID, why you think it should be
applied, and what kernel version you wish it to be
applied to.
Subject: request for 4.4-stable: 08474cc1e6ea7 ("bridge: Propagate vlan
add failure to user")
From: SZ Lin (林上智) <sz.lin@xxxxxxxx>
Date: Wed, 22 Aug 2018 20:07:14 +0800
Hi Greg,
This patch is not marked for 4.4-stable, but it's already in 4.9 and 4.14
stable.
Please apply to 4.4-stable.
This patch fixed the kernel oops issue when executing bridge tool, please
see reproducible steps with kernel 4.4 in below.
# brctl addbr br0
# brctl addif br0 eth0
[ 1073.390028] device eth0 entered promiscuous mode
[ 1073.395022] cpsw 4a100000.ethernet eth0: failed to initialize vlan
filtering on this port
[ 1092.205685] net eth1: promiscuity not disabled as the other interface is
still in promiscuity mode
# ifconfig br0 192.168.127.253 netmask 255.255.254.0
[ 1112.412740] br0: port 1(eth0) entered forwarding state
...
Subject: request for 4.4-stable: 08474cc1e6ea7 ("bridge: Propagate vlan
add failure to user")
Date: Wed, 22 Aug 2018 20:07:14 +0800
Hi Greg,
This patch is not marked for 4.4-stable, but it's already in 4.9 and 4.14
stable.
Please apply to 4.4-stable.
This patch fixed the kernel oops issue when executing bridge tool, please
see reproducible steps with kernel 4.4 in below.
# brctl addbr br0
[ 1092.205685] net eth1: promiscuity not disabled as the other interface is
still in promiscuity mode
# ifconfig br0 192.168.127.253 netmask 255.255.254.0
...

Subject: [PATCH 4.4 1/3] ovl: rename is_merge to is_lowest
Date: Wed, 22 Aug 2018 20:07:14 +0800
From: Miklos Szeredi
commit 56656e960b555cb98bc414382566dcb59aae99a2 upstream
The 'is_merge' is an historical naming from when only a single lower layer
could exist. With the introduction of multiple lower layers the meaning of
this flag was changed to mean only the "lowest layer" (while all lower
layers were being merged).
So now 'is_merge' is inaccurate and hence renaming to 'is_lowest'
Signed-off-by: Miklos Szeredi
Signed-off-by: SZ Lin (林上智)
...
Subject: [PATCH 4.4 1/3] ovl: rename is_merge to is_lowest
Date: Wed, 22 Aug 2018 20:07:14 +0800
From: Miklos Szeredi
commit 56656e960b555cb98bc414382566dcb59aae99a2 upstream
The 'is_merge' is an historical naming from when only a single lower layer
could exist. With the introduction of multiple lower layers the meaning of
this flag was changed to mean only the "lowest layer" (while all lower
layers were being merged).
So now 'is_merge' is inaccurate and hence renaming to 'is_lowest'
Signed-off-by: Miklos Szeredi
...
39
Option 3. Send the patch, after verifying that it follows
the above rules, to stable@vger.kernel.org. You must
note the upstream commit ID in the changelog of your
submission, as well as the kernel version you wish it to
be applied to.

40
Option 1 is strongly preferred, is the easiest and most common. Option 2 and Option 3 are
more useful if the patch isn’t deemed worthy at the time it is applied to a public git tree
(for instance, because it deserves more regression testing first). Option 3 is especially
useful if the patch needs some special handling to apply to an older kernel (e.g., if API’s
have changed in the meantime).
Note that for Option 3, if the patch deviates from the original upstream patch (for example
because it had to be backported) this must be very clearly documented and justified in the
patch description. [9]
note: another entry point of patch is AUTOSEL bot, which is a neural network for finding fixes [11].

41
commit d733f7542ad47cf73e033c90cf55158587e1d060 upstream.
If an emac node has a phy-handle property that points to something
which is not a phy, then a segmentation fault will occur when the
interface is brought up. This is because while phy_connect() will
return ERR_PTR() on failure, of_phy_connect() will return NULL.
The common error check uses IS_ERR(), and so missed when
of_phy_connect() fails. The NULL pointer is then dereferenced.
Also, the common error message referenced slave->data->phy_id,
which would be empty in the case of phy-handle. Instead, use the
name of the device_node as a useful identifier. And in the phy_id
case add the error code for completeness.
Fixes: 9e42f715264f ("drivers: net: cpsw: add phy-handle parsing")
Signed-off-by: David Rivshin
Signed-off-by: David S. Miller
[SZ Lin (林上智): Tweak the patch to use original print function of dev_info()]
Signed-off-by: Greg Kroah-Hartman
commit d733f7542ad47cf73e033c90cf55158587e1d060 upstream.
If an emac node has a phy-handle property that points to something
which is not a phy, then a segmentation fault will occur when the
interface is brought up. This is because while phy_connect() will
return ERR_PTR() on failure, of_phy_connect() will return NULL.
The common error check uses IS_ERR(), and so missed when
of_phy_connect() fails. The NULL pointer is then dereferenced.
Also, the common error message referenced slave->data->phy_id,
which would be empty in the case of phy-handle. Instead, use the
name of the device_node as a useful identifier. And in the phy_id
case add the error code for completeness.
Fixes: 9e42f715264f ("drivers: net: cpsw: add phy-handle parsing")
Signed-off-by: David Rivshin
Signed-off-by: David S. Miller
[SZ Lin (林上智): Tweak the patch to use original print function of dev_info()]
Signed-off-by: Greg Kroah-Hartman
Elaborate the difference from
the original source

42
Review cycle [9]
• When the -stable maintainers decide for a review cycle, the patches will be sent to
the review committee, and the maintainer of the affected area of the patch
(unless the submitter is the maintainer of the area) and CC: to the linux-kernel
mailing list.
• The review committee has 48 hours in which to ACK or NAK the patch.
• If the patch is rejected by a member of the committee, or linux-kernel members
object to the patch, bringing up issues that the maintainers and members did not
realize, the patch will be dropped from the queue.
• At the end of the review cycle, the ACKed patches will be added to the latest -
stable release, and a new -stable release will happen.
• Security patches will be accepted into the -stable tree directly from the security
kernel team, and not go through the normal review cycle. Contact the kernel
security team for more details on this procedure.

44
Thank you
林上智 (SZ LIN) szlin@debian.org
蔡鎮宇 wens@csie.org

45
References
[1] https://www.kernel.org/category/releases.html
[2] https://www.cvedetails.com/version/261041/Linux-Linux-Kernel-4.19.html
[6] https://ltsi.linuxfoundation.org/
[7] https://www.cip-project.org/
[8] https://static.sched.com/hosted_files/ossna2020/d0/OSSNA2020-CIPKernelTeam-2.pdf
[9] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
[10] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance
[11] https://lwn.net/Articles/825536/

Select, manage, and backport the long term stable kernels

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Select, manage, and backport the long term stable kernels

Ähnlich wie Select, manage, and backport the long term stable kernels (20)

Mehr von SZ Lin

Mehr von SZ Lin (8)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Select, manage, and backport the long term stable kernels