Skip to content

Commit 4ba54a6

Browse files
committed
sched_ext: Refactor lockup handlers into handle_lockup()
scx_rcu_cpu_stall() and scx_softlockup() share the same pattern: check if the scheduler is enabled under RCU read lock and trigger an error if so. Extract the common pattern into handle_lockup() helper. Add scx_verror() macro and use guard(rcu)(). This simplifies both handlers, reduces code duplication, and prepares for hardlockup handling. Reviewed-by: Dan Schatzberg <schatzberg.dan@gmail.com> Reviewed-by: Andrea Righi <arighi@nvidia.com> Cc: Emil Tsalapatis <etsal@meta.com> Signed-off-by: Tejun Heo <tj@kernel.org>
1 parent f2fe382 commit 4ba54a6

1 file changed

Lines changed: 25 additions & 40 deletions

File tree

kernel/sched/ext.c

Lines changed: 25 additions & 40 deletions
Original file line numberDiff line numberDiff line change
@@ -192,6 +192,7 @@ static __printf(4, 5) bool scx_exit(struct scx_sched *sch,
192192
}
193193

194194
#define scx_error(sch, fmt, args...) scx_exit((sch), SCX_EXIT_ERROR, 0, fmt, ##args)
195+
#define scx_verror(sch, fmt, args) scx_vexit((sch), SCX_EXIT_ERROR, 0, fmt, args)
195196

196197
#define SCX_HAS_OP(sch, op) test_bit(SCX_OP_IDX(op), (sch)->has_op)
197198

@@ -3654,39 +3655,40 @@ bool scx_allow_ttwu_queue(const struct task_struct *p)
36543655
return false;
36553656
}
36563657

3657-
/**
3658-
* scx_rcu_cpu_stall - sched_ext RCU CPU stall handler
3659-
*
3660-
* While there are various reasons why RCU CPU stalls can occur on a system
3661-
* that may not be caused by the current BPF scheduler, try kicking out the
3662-
* current scheduler in an attempt to recover the system to a good state before
3663-
* issuing panics.
3664-
*/
3665-
bool scx_rcu_cpu_stall(void)
3658+
static __printf(1, 2) bool handle_lockup(const char *fmt, ...)
36663659
{
36673660
struct scx_sched *sch;
3661+
va_list args;
36683662

3669-
rcu_read_lock();
3663+
guard(rcu)();
36703664

36713665
sch = rcu_dereference(scx_root);
3672-
if (unlikely(!sch)) {
3673-
rcu_read_unlock();
3666+
if (unlikely(!sch))
36743667
return false;
3675-
}
36763668

36773669
switch (scx_enable_state()) {
36783670
case SCX_ENABLING:
36793671
case SCX_ENABLED:
3680-
break;
3672+
va_start(args, fmt);
3673+
scx_verror(sch, fmt, args);
3674+
va_end(args);
3675+
return true;
36813676
default:
3682-
rcu_read_unlock();
36833677
return false;
36843678
}
3679+
}
36853680

3686-
scx_error(sch, "RCU CPU stall detected!");
3687-
rcu_read_unlock();
3688-
3689-
return true;
3681+
/**
3682+
* scx_rcu_cpu_stall - sched_ext RCU CPU stall handler
3683+
*
3684+
* While there are various reasons why RCU CPU stalls can occur on a system
3685+
* that may not be caused by the current BPF scheduler, try kicking out the
3686+
* current scheduler in an attempt to recover the system to a good state before
3687+
* issuing panics.
3688+
*/
3689+
bool scx_rcu_cpu_stall(void)
3690+
{
3691+
return handle_lockup("RCU CPU stall detected!");
36903692
}
36913693

36923694
/**
@@ -3701,28 +3703,11 @@ bool scx_rcu_cpu_stall(void)
37013703
*/
37023704
void scx_softlockup(u32 dur_s)
37033705
{
3704-
struct scx_sched *sch;
3705-
3706-
rcu_read_lock();
3707-
3708-
sch = rcu_dereference(scx_root);
3709-
if (unlikely(!sch))
3710-
goto out_unlock;
3711-
3712-
switch (scx_enable_state()) {
3713-
case SCX_ENABLING:
3714-
case SCX_ENABLED:
3715-
break;
3716-
default:
3717-
goto out_unlock;
3718-
}
3719-
3720-
printk_deferred(KERN_ERR "sched_ext: Soft lockup - CPU%d stuck for %us, disabling \"%s\"\n",
3721-
smp_processor_id(), dur_s, scx_root->ops.name);
3706+
if (!handle_lockup("soft lockup - CPU %d stuck for %us", smp_processor_id(), dur_s))
3707+
return;
37223708

3723-
scx_error(sch, "soft lockup - CPU#%d stuck for %us", smp_processor_id(), dur_s);
3724-
out_unlock:
3725-
rcu_read_unlock();
3709+
printk_deferred(KERN_ERR "sched_ext: Soft lockup - CPU %d stuck for %us, disabling BPF scheduler\n",
3710+
smp_processor_id(), dur_s);
37263711
}
37273712

37283713
/**

0 commit comments

Comments
 (0)