sched_ext, rcu: Eject BPF scheduler on RCU CPU stall panic

For systems using a sched_ext scheduler and has panic_on_rcu_stall
enabled, try kicking out the current scheduler before issuing a panic.

While there are numerous reasons for RCU CPU stalls that are not
directly attributed to the scheduler, deferring the panic gives
sched_ext an opportunity to provide additional debug info when ejecting
the current scheduler. Also, handling the event more gracefully allows
us to potentially recover the system instead of incurring additional
down time.

Suggested-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: David Dai <david.dai@linux.dev>
Signed-off-by: Tejun Heo <tj@kernel.org>

diff --git a/include/linux/sched/ext.h b/include/linux/sched/ext.h
index 8b92842776cb3b6292e72f40eb7625be00459f80..0cf0915572c9d69dce5ca691a2570d0308ac6ea6 100644 (file)
--- a/include/linux/sched/ext.h
+++ b/include/linux/sched/ext.h
@@ -206,12 +206,14 @@ struct sched_ext_entity {
 void sched_ext_free(struct task_struct *p);
 void print_scx_info(const char *log_lvl, struct task_struct *p);
 void scx_softlockup(u32 dur_s);
+bool scx_rcu_cpu_stall(void);
 
 #else  /* !CONFIG_SCHED_CLASS_EXT */
 
 static inline void sched_ext_free(struct task_struct *p) {}
 static inline void print_scx_info(const char *log_lvl, struct task_struct *p) {}
 static inline void scx_softlockup(u32 dur_s) {}
+static inline bool scx_rcu_cpu_stall(void) { return false; }
 
 #endif /* CONFIG_SCHED_CLASS_EXT */
 

diff --git a/kernel/rcu/tree_stall.h b/kernel/rcu/tree_stall.h
index 486c00536207d58a621ee97cf2e83834cdb186aa..af61b2d0d31171ac0570966a05a77ae5958ad162 100644 (file)
--- a/kernel/rcu/tree_stall.h
+++ b/kernel/rcu/tree_stall.h
@@ -134,6 +134,13 @@ static void panic_on_rcu_stall(void)
 {
        static int cpu_stall;
 
+       /*
+        * Attempt to kick out the BPF scheduler if it's installed and defer
+        * the panic to give the system a chance to recover.
+        */
+       if (scx_rcu_cpu_stall())
+               return;
+
        if (++cpu_stall < sysctl_max_rcu_stall_to_panic)
                return;
 

diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
index bee98fdcdd01b88ee4e201d12fd8c0f05b4fc0e2..df5b2c952cf7e4ab4fd240b90d9227ce5608cd39 100644 (file)
--- a/kernel/sched/ext.c
+++ b/kernel/sched/ext.c
@@ -4672,6 +4672,41 @@ bool scx_allow_ttwu_queue(const struct task_struct *p)
                p->sched_class != &ext_sched_class;
 }
 
+/**
+ * scx_rcu_cpu_stall - sched_ext RCU CPU stall handler
+ *
+ * While there are various reasons why RCU CPU stalls can occur on a system
+ * that may not be caused by the current BPF scheduler, try kicking out the
+ * current scheduler in an attempt to recover the system to a good state before
+ * issuing panics.
+ */
+bool scx_rcu_cpu_stall(void)
+{
+       struct scx_sched *sch;
+
+       rcu_read_lock();
+
+       sch = rcu_dereference(scx_root);
+       if (unlikely(!sch)) {
+               rcu_read_unlock();
+               return false;
+       }
+
+       switch (scx_enable_state()) {
+       case SCX_ENABLING:
+       case SCX_ENABLED:
+               break;
+       default:
+               rcu_read_unlock();
+               return false;
+       }
+
+       scx_error(sch, "RCU CPU stall detected!");
+       rcu_read_unlock();
+
+       return true;
+}
+
 /**
  * scx_softlockup - sched_ext softlockup handler
  * @dur_s: number of seconds of CPU stuck due to soft lockup