starlingx/kernel
Code Issues Proposed changes

kernel: Update 5.10 Kernel to 5.10.99

Browse Source 
This commit removes two rcu related patches, because the fix is now
integrated into 5.10.99 kernel, adds new configs
CONFIG_BPF_UNPRIV_DEFAULT_OFF and
CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION.

Verification:
- Install success onto a StarlingX system with two controller and two
  compute nodes with std kernel.
- Install success onto a All-in-One Duplex lab with rt kernel.
- The network performance test is done with rt system. The result is
  almost same with 5.10.74.
- The regression testing was run including kernel and applications
  by our test team.
- The cyclictest benchmark was run by our test team, the result is
  little better than 5.10.74. Test result is "samples:431999998 avg:5317
  max:24981 99.9999th percentile:10482 overflows:2" for 20 hours.
- The cyclictest benchmark was also run on the starlingx lab, the result
  is "samples:43199987 avg:1617 max:5103 99.9999th percentile:3355
  overflows: 0". It is not big difference with 5.10.74.

Story: 2009884
Task: 44639
Depends-On: https://review.opendev.org/c/starlingx/manifest/+/831792

Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
Change-Id: I7afb83d0e02f9d53077a7430a988fe2246247e8e
This commit is contained in:
Jiping Ma 2022-03-01 00:05:11 -08:00
parent 3201fe2890
commit 06295a93ee
10 changed files with 16 additions and 230 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
kernel-rt/centos/build_srpm.data
View File

@ -7,9 +7,9 @@ BUILD_IS_BIG=21
BUILD_IS_SLOW=16
# The base branch is: v5.10/standard/preempt-rt/base
# commit 8048444fc7 points to v5.10.74-rt47 in linux-yocto.
TIS_BASE_SRCREV=8048444fc7e44c6fc04a5e0b35d6117fe51c17fc
# commit 53a27dc510 points to v5.10.99-rt56 in linux-yocto.
TIS_BASE_SRCREV=53a27dc510c8d9152ffa4d2d95b888db7d3d97b6
PKG_BASE_SRCREV=4013790c6ef43fd9f936579b0cac50b8e0c4505a
TIS_PATCH_VER=GITREVCOUNT+PKG_GITREVCOUNT+2000
TIS_PATCH_VER=GITREVCOUNT+PKG_GITREVCOUNT

4
kernel-rt/centos/kernel-rt.spec
View File

@ -90,7 +90,7 @@ Summary: The Linux kernel
%define base_sublevel 10
# Do we have a -stable update to apply?
%define stable_update 74
%define stable_update 99
# Set rpm version accordingly
%define stablerev %{stable_update}
%define stable_base %{stable_update}
@ -788,8 +788,6 @@ Patch8: 0009-tpm-ignore-burstcount-to-improve-tpm_tis-send-perfor.patch
Patch9: 0010-restrict-iSCSI-kthreads-to-CPUs-in-cpu_kthread_mask.patch
Patch10: 0011-scsi-smartpqi-Enable-sas_address-sysfs-for-SATA-dev.patch
Patch11: 0012-workqueue-Affine-rescuer-threads-and-unbound-wqs.patch
Patch12: 0013-rcu-Mark-accesses-to-rcu_state.n_force_qs.patch
Patch13: 0014-rcu-Tighten-rcu_advance_cbs_nowake-checks.patch
Patch14: 0015-Revert-scsi-sd-Inline-sd_probe_part2.patch
Patch15: 0016-Revert-commit-f049cf1a7b.patch
Patch16: 0017-genirq-Export-affinity-setter-for-modules.patch

64
kernel-rt/centos/patches/0013-rcu-Mark-accesses-to-rcu_state.n_force_qs.patch
View File

@ -1,64 +0,0 @@
From e21cab0b7f1a6634ee57950600b68f6df960e3f5 Mon Sep 17 00:00:00 2001
From: "Paul E. McKenney" <paulmck@kernel.org>
Date: Tue, 20 Jul 2021 06:16:27 -0700
Subject: [PATCH] rcu: Mark accesses to rcu_state.n_force_qs
This commit marks accesses to the rcu_state.n_force_qs. These data
races are hard to make happen, but syzkaller was equal to the task.
Reported-by: syzbot+e08a83a1940ec3846cd5@syzkaller.appspotmail.com
Acked-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
(cherry picked from commit 2431774f04d1050292054c763070021bade7b151)
Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
---
kernel/rcu/tree.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 4cc5af7f2b91..30cb9af8284c 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1890,7 +1890,7 @@ static void rcu_gp_fqs(bool first_time)
struct rcu_node *rnp = rcu_get_root();
WRITE_ONCE(rcu_state.gp_activity, jiffies);
- rcu_state.n_force_qs++;
+ WRITE_ONCE(rcu_state.n_force_qs, rcu_state.n_force_qs + 1);
if (first_time) {
/* Collect dyntick-idle snapshots. */
force_qs_rnp(dyntick_save_progress_counter);
@@ -2532,7 +2532,7 @@ static void rcu_do_batch(struct rcu_data *rdp)
/* Reset ->qlen_last_fqs_check trigger if enough CBs have drained. */
if (count == 0 && rdp->qlen_last_fqs_check != 0) {
rdp->qlen_last_fqs_check = 0;
- rdp->n_force_qs_snap = rcu_state.n_force_qs;
+ rdp->n_force_qs_snap = READ_ONCE(rcu_state.n_force_qs);
} else if (count < rdp->qlen_last_fqs_check - qhimark)
rdp->qlen_last_fqs_check = count;
@@ -2878,10 +2878,10 @@ static void __call_rcu_core(struct rcu_data *rdp, struct rcu_head *head,
} else {
/* Give the grace period a kick. */
rdp->blimit = DEFAULT_MAX_RCU_BLIMIT;
- if (rcu_state.n_force_qs == rdp->n_force_qs_snap &&
+ if (READ_ONCE(rcu_state.n_force_qs) == rdp->n_force_qs_snap &&
rcu_segcblist_first_pend_cb(&rdp->cblist) != head)
rcu_force_quiescent_state();
- rdp->n_force_qs_snap = rcu_state.n_force_qs;
+ rdp->n_force_qs_snap = READ_ONCE(rcu_state.n_force_qs);
rdp->qlen_last_fqs_check = rcu_segcblist_n_cbs(&rdp->cblist);
}
}
@@ -3988,7 +3988,7 @@ int rcutree_prepare_cpu(unsigned int cpu)
/* Set up local state, ensuring consistent view of global state. */
raw_spin_lock_irqsave_rcu_node(rnp, flags);
rdp->qlen_last_fqs_check = 0;
- rdp->n_force_qs_snap = rcu_state.n_force_qs;
+ rdp->n_force_qs_snap = READ_ONCE(rcu_state.n_force_qs);
rdp->blimit = blimit;
if (rcu_segcblist_empty(&rdp->cblist) && /* No early-boot CBs? */
!rcu_segcblist_is_offloaded(&rdp->cblist))
--
2.31.1

45
kernel-rt/centos/patches/0014-rcu-Tighten-rcu_advance_cbs_nowake-checks.patch
View File

@ -1,45 +0,0 @@
From 21e034adb9df3581fda926a29b3a11bda38ba93b Mon Sep 17 00:00:00 2001
From: "Paul E. McKenney" <paulmck@kernel.org>
Date: Fri, 17 Sep 2021 15:04:48 -0700
Subject: [PATCH] rcu: Tighten rcu_advance_cbs_nowake() checks
Currently, rcu_advance_cbs_nowake() checks that a grace period is in
progress, however, that grace period could end just after the check.
This commit rechecks that a grace period is still in progress the lock.
The grace period cannot end while the current CPU's rcu_node structure's
->lock is held, thus avoiding false positives from the WARN_ON_ONCE().
As Daniel Vacek noted, it is not necessary for the rcu_node structure
to have a CPU that has not yet passed through its quiescent state.
Tested-By: Guillaume Morin <guillaume@morinfr.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
(Cherry pick from https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/
linux-rcu.git/commit/?h=rcu/next&id=325a2030b90376d179a129794e2fae2b24d73923)
Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
---
kernel/rcu/tree.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index ef8d36f580fc..8706b30c2ac8 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1590,10 +1590,11 @@ static void __maybe_unused rcu_advance_cbs_nowake(struct rcu_node *rnp,
struct rcu_data *rdp)
{
rcu_lockdep_assert_cblist_protected(rdp);
- if (!rcu_seq_state(rcu_seq_current(&rnp->gp_seq)) ||
- !raw_spin_trylock_rcu_node(rnp))
+ if (!rcu_seq_state(rcu_seq_current(&rnp->gp_seq)) || !raw_spin_trylock_rcu_node(rnp))
return;
- WARN_ON_ONCE(rcu_advance_cbs(rnp, rdp));
+ // The grace period cannot end while we hold the rcu_node lock.
+ if (rcu_seq_state(rcu_seq_current(&rnp->gp_seq)))
+ WARN_ON_ONCE(rcu_advance_cbs(rnp, rdp));
raw_spin_unlock_rcu_node(rnp);
}
--
2.31.1

4
kernel-rt/files/kernel-x86_64-rt.config.tis_extra
View File

@ -1085,3 +1085,7 @@ CONFIG_PCI_REALLOC_ENABLE_AUTO=y
# Refer to 3.10 that set CONFIG_GVE=m
CONFIG_GVE=m
# upgrade to 5.10.99
# CONFIG_BPF_UNPRIV_DEFAULT_OFF is not set
# CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION is not set

6
kernel-std/centos/build_srpm.data
View File

@ -7,9 +7,9 @@ BUILD_IS_BIG=21
BUILD_IS_SLOW=16
# The base branch is: v5.10/standard/base
# commit 9e84a42af6 points to v5.10.74 in linux-yocto.
TIS_BASE_SRCREV=9e84a42af61ff9c6feb89ab8d61ee5f25fb35c72
# commit 84f6a75f64 points to v5.10.99 in linux-yocto.
TIS_BASE_SRCREV=84f6a75f64961e59d61bf3d70ab17e8bb430386b
PKG_BASE_SRCREV=4013790c6ef43fd9f936579b0cac50b8e0c4505a
TIS_PATCH_VER=GITREVCOUNT+PKG_GITREVCOUNT+2000
TIS_PATCH_VER=GITREVCOUNT+PKG_GITREVCOUNT

4
kernel-std/centos/kernel.spec
View File

@ -93,7 +93,7 @@ Summary: The Linux kernel
%if 0%{?released_kernel}
# Do we have a -stable update to apply?
%define stable_update 74
%define stable_update 99
# Set rpm version accordingly
%if 0%{?stable_update}
%define stablerev %{stable_update}
@ -821,8 +821,6 @@ Patch8: 0009-tpm-ignore-burstcount-to-improve-tpm_tis-send-perfor.patch
Patch9: 0010-bpf-cgroups-Fix-cgroup-v2-fallback-on-v1-v2-mixed-mo.patch
Patch10: 0011-scsi-smartpqi-Enable-sas_address-sysfs-for-SATA-dev.patch
Patch11: 0012-workqueue-Affine-rescuer-threads-and-unbound-wqs.patch
Patch12: 0013-rcu-Mark-accesses-to-rcu_state.n_force_qs.patch
Patch13: 0014-rcu-Tighten-rcu_advance_cbs_nowake-checks.patch
Patch14: 0015-Revert-scsi-sd-Inline-sd_probe_part2.patch
Patch15: 0016-Revert-commit-f049cf1a7b.patch
Patch16: 0017-genirq-Export-affinity-setter-for-modules.patch

64
kernel-std/centos/patches/0013-rcu-Mark-accesses-to-rcu_state.n_force_qs.patch
View File

@ -1,64 +0,0 @@
From e21cab0b7f1a6634ee57950600b68f6df960e3f5 Mon Sep 17 00:00:00 2001
From: "Paul E. McKenney" <paulmck@kernel.org>
Date: Tue, 20 Jul 2021 06:16:27 -0700
Subject: [PATCH] rcu: Mark accesses to rcu_state.n_force_qs
This commit marks accesses to the rcu_state.n_force_qs. These data
races are hard to make happen, but syzkaller was equal to the task.
Reported-by: syzbot+e08a83a1940ec3846cd5@syzkaller.appspotmail.com
Acked-by: Marco Elver <elver@google.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
(cherry picked from commit 2431774f04d1050292054c763070021bade7b151)
Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
---
kernel/rcu/tree.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 4cc5af7f2b91..30cb9af8284c 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1890,7 +1890,7 @@ static void rcu_gp_fqs(bool first_time)
struct rcu_node *rnp = rcu_get_root();
WRITE_ONCE(rcu_state.gp_activity, jiffies);
- rcu_state.n_force_qs++;
+ WRITE_ONCE(rcu_state.n_force_qs, rcu_state.n_force_qs + 1);
if (first_time) {
/* Collect dyntick-idle snapshots. */
force_qs_rnp(dyntick_save_progress_counter);
@@ -2532,7 +2532,7 @@ static void rcu_do_batch(struct rcu_data *rdp)
/* Reset ->qlen_last_fqs_check trigger if enough CBs have drained. */
if (count == 0 && rdp->qlen_last_fqs_check != 0) {
rdp->qlen_last_fqs_check = 0;
- rdp->n_force_qs_snap = rcu_state.n_force_qs;
+ rdp->n_force_qs_snap = READ_ONCE(rcu_state.n_force_qs);
} else if (count < rdp->qlen_last_fqs_check - qhimark)
rdp->qlen_last_fqs_check = count;
@@ -2878,10 +2878,10 @@ static void __call_rcu_core(struct rcu_data *rdp, struct rcu_head *head,
} else {
/* Give the grace period a kick. */
rdp->blimit = DEFAULT_MAX_RCU_BLIMIT;
- if (rcu_state.n_force_qs == rdp->n_force_qs_snap &&
+ if (READ_ONCE(rcu_state.n_force_qs) == rdp->n_force_qs_snap &&
rcu_segcblist_first_pend_cb(&rdp->cblist) != head)
rcu_force_quiescent_state();
- rdp->n_force_qs_snap = rcu_state.n_force_qs;
+ rdp->n_force_qs_snap = READ_ONCE(rcu_state.n_force_qs);
rdp->qlen_last_fqs_check = rcu_segcblist_n_cbs(&rdp->cblist);
}
}
@@ -3988,7 +3988,7 @@ int rcutree_prepare_cpu(unsigned int cpu)
/* Set up local state, ensuring consistent view of global state. */
raw_spin_lock_irqsave_rcu_node(rnp, flags);
rdp->qlen_last_fqs_check = 0;
- rdp->n_force_qs_snap = rcu_state.n_force_qs;
+ rdp->n_force_qs_snap = READ_ONCE(rcu_state.n_force_qs);
rdp->blimit = blimit;
if (rcu_segcblist_empty(&rdp->cblist) && /* No early-boot CBs? */
!rcu_segcblist_is_offloaded(&rdp->cblist))
--
2.31.1

45
kernel-std/centos/patches/0014-rcu-Tighten-rcu_advance_cbs_nowake-checks.patch
View File

@ -1,45 +0,0 @@
From 21e034adb9df3581fda926a29b3a11bda38ba93b Mon Sep 17 00:00:00 2001
From: "Paul E. McKenney" <paulmck@kernel.org>
Date: Fri, 17 Sep 2021 15:04:48 -0700
Subject: [PATCH] rcu: Tighten rcu_advance_cbs_nowake() checks
Currently, rcu_advance_cbs_nowake() checks that a grace period is in
progress, however, that grace period could end just after the check.
This commit rechecks that a grace period is still in progress the lock.
The grace period cannot end while the current CPU's rcu_node structure's
->lock is held, thus avoiding false positives from the WARN_ON_ONCE().
As Daniel Vacek noted, it is not necessary for the rcu_node structure
to have a CPU that has not yet passed through its quiescent state.
Tested-By: Guillaume Morin <guillaume@morinfr.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
(Cherry pick from https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/
linux-rcu.git/commit/?h=rcu/next&id=325a2030b90376d179a129794e2fae2b24d73923)
Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
---
kernel/rcu/tree.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index ef8d36f580fc..8706b30c2ac8 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1590,10 +1590,11 @@ static void __maybe_unused rcu_advance_cbs_nowake(struct rcu_node *rnp,
struct rcu_data *rdp)
{
rcu_lockdep_assert_cblist_protected(rdp);
- if (!rcu_seq_state(rcu_seq_current(&rnp->gp_seq)) ||
- !raw_spin_trylock_rcu_node(rnp))
+ if (!rcu_seq_state(rcu_seq_current(&rnp->gp_seq)) || !raw_spin_trylock_rcu_node(rnp))
return;
- WARN_ON_ONCE(rcu_advance_cbs(rnp, rdp));
+ // The grace period cannot end while we hold the rcu_node lock.
+ if (rcu_seq_state(rcu_seq_current(&rnp->gp_seq)))
+ WARN_ON_ONCE(rcu_advance_cbs(rnp, rdp));
raw_spin_unlock_rcu_node(rnp);
}
--
2.31.1

4
kernel-std/files/kernel-x86_64.config.tis_extra
View File

@ -1593,3 +1593,7 @@ CONFIG_SERIAL_8250_LPSS=y
CONFIG_ZRAM_WRITEBACK=y
CONFIG_PCI_REALLOC_ENABLE_AUTO=y
# CONFIG_CMA is not set
# upgrade to 5.10.99
# CONFIG_BPF_UNPRIV_DEFAULT_OFF is not set
# CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION is not set