On Tue, 11 Jul 2017 22:39:24 +0800 Alex Shi <[email protected]> wrote:
> Any comments for this little change? It's passed on 0day testing. I think the problem was that this was a third patch after two documentation patches. Where, people put documentation review at the bottom of their priority list. This should have been sent as separate patch on its own. > > Thanks > Alex > > On 07/07/2017 10:52 AM, Alex Shi wrote: > > We don't need to adjust prio before new pi_waiter adding. The prio > > only need update after pi_waiter change or task priority change. > > > > Signed-off-by: Alex Shi <[email protected]> > > Cc: Steven Rostedt <[email protected]> > > Cc: Sebastian Siewior <[email protected]> > > Cc: Mathieu Poirier <[email protected]> > > Cc: Juri Lelli <[email protected]> > > Cc: Thomas Gleixner <[email protected]> > > To: [email protected] > > To: Ingo Molnar <[email protected]> > > To: Peter Zijlstra <[email protected]> > > --- > > kernel/locking/rtmutex.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c > > index 28cd09e..d1fe41f 100644 > > --- a/kernel/locking/rtmutex.c > > +++ b/kernel/locking/rtmutex.c > > @@ -963,7 +963,6 @@ static int task_blocks_on_rt_mutex(struct rt_mutex > > *lock, > > return -EDEADLK; > > > > raw_spin_lock(&task->pi_lock); > > - rt_mutex_adjust_prio(task); Interesting, I did some git mining and this was added with the original entry of the rtmutex.c (23f78d4a0). Looking at even that version, I don't see the purpose of adjusting the task prio here. It is done before anything changes in the task. Reviewed-by: Steven Rostedt (VMware) <[email protected]> -- Steve > > waiter->task = task; > > waiter->lock = lock; > > waiter->prio = task->prio; > >
