[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250611101457.13ea44f5@batman.local.home>
Date: Wed, 11 Jun 2025 10:14:57 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
linux-kernel@...r.kernel.org, Ben Segall <bsegall@...gle.com>, Dietmar
Eggemann <dietmar.eggemann@....com>, Ingo Molnar <mingo@...hat.com>, Juri
Lelli <juri.lelli@...hat.com>, Mel Gorman <mgorman@...e.de>, Thomas
Gleinxer <tglx@...utronix.de>, Valentin Schneider <vschneid@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH v2] sched: Remove a preempt-disable section in
rt_mutex_setprio()
On Wed, 11 Jun 2025 11:03:06 +0200
Peter Zijlstra <peterz@...radead.org> wrote:
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -7292,14 +7292,10 @@ void rt_mutex_setprio(struct task_struct *p, struct task_struct *pi_task)
> >
> > check_class_changed(rq, p, prev_class, oldprio);
> > out_unlock:
> > - /* Avoid rq from going away on us: */
> > - preempt_disable();
>
> Perhaps add:
>
> /* IRQs are still disabled */
>
> or something to that effect such that it is obvious from reading the
> code that dropping the lock will not enable preemption?
Hmm, wouldn't lockdep_assert_irqs_disabled() be better than a comment.
It lets people know that interrupts are disabled and when lockdep is
enabled it also makes sure they are.
-- Steve
Powered by blists - more mailing lists