Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1421899 > unrolled thread

Re: [RFC][PATCH 6/8] sched/rtmutex: Refactor rt_mutex_setprio()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC][PATCH 6/8] sched/rtmutex: Refactor rt_mutex_setprio() Juri Lelli <juri.lelli@arm.com> - 2016-06-14 15:20 +0200
    Re: [RFC][PATCH 6/8] sched/rtmutex: Refactor rt_mutex_setprio() Peter Zijlstra <peterz@infradead.org> - 2016-06-14 16:10 +0200

#1421899 — Re: [RFC][PATCH 6/8] sched/rtmutex: Refactor rt_mutex_setprio()

Hi,

still digesting this change, but I'll point out below why I think you
are hitting a NULL ptr dereference (discussed on IRC).

On 07/06/16 21:56, Peter Zijlstra wrote:
> With the introduction of SCHED_DEADLINE the whole notion that priority
> is a single number is gone, therefore the @prio argument to
> rt_mutex_setprio() doesn't make sense anymore.
> 
> So rework the code to pass a pi_task instead.
> 
> Note this also fixes a problem with pi_top_task caching; previously we
> would not set the pointer (call rt_mutex_update_top_task) if the
> priority didn't change, this could lead to a stale pointer.
> 
> As for the XXX, I think its fine to use pi_task->prio, because if it
> differs from waiter->prio, a PI chain update is immenent.
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
>  include/linux/sched/rt.h        |   21 +-------
>  kernel/locking/rtmutex.c        |  105 +++++++++++-----------------------------
>  kernel/locking/rtmutex_common.h |    1 
>  kernel/sched/core.c             |   66 ++++++++++++++++++++-----
>  4 files changed, 88 insertions(+), 105 deletions(-)
> 

[...]

> --- a/kernel/locking/rtmutex.c
> +++ b/kernel/locking/rtmutex.c
> @@ -256,61 +256,16 @@ rt_mutex_dequeue_pi(struct task_struct *
>  	RB_CLEAR_NODE(&waiter->pi_tree_entry);
>  }
>  
> -void rt_mutex_update_top_task(struct task_struct *p)
> +static void rt_mutex_adjust_prio(struct task_struct *p)
>  {
> -	if (!task_has_pi_waiters(p)) {
> -		p->pi_top_task = NULL;
> -		return;
> -	}
> +	struct task_struct *pi_task = NULL;
>  
> -	p->pi_top_task = task_top_pi_waiter(p)->task;
> -}
> -
> -/*
> - * Calculate task priority from the waiter tree priority
> - *
> - * Return task->normal_prio when the waiter tree is empty or when
> - * the waiter is not allowed to do priority boosting
> - */
> -int rt_mutex_getprio(struct task_struct *task)
> -{
> -	if (likely(!task_has_pi_waiters(task)))
> -		return task->normal_prio;
> +	lockdep_assert_held(&p->pi_lock);
>  
> -	return min(task_top_pi_waiter(task)->prio,
> -		   task->normal_prio);
> -}
> +	if (!task_has_pi_waiters(p))

Shouldn't this be the other way around?

 if (task_has_pi_waiters(p))
 	pi_task = ...

Best,

- Juri

[toc] | [next] | [standalone]

#1421916

On Tue, Jun 14, 2016 at 02:14:24PM +0100, Juri Lelli wrote:
> Hi,
> 
> still digesting this change, but I'll point out below why I think you
> are hitting a NULL ptr dereference (discussed on IRC).
> 
> On 07/06/16 21:56, Peter Zijlstra wrote:
> 
> > --- a/kernel/locking/rtmutex.c
> > +++ b/kernel/locking/rtmutex.c
> > @@ -256,61 +256,16 @@ rt_mutex_dequeue_pi(struct task_struct *
> >  	RB_CLEAR_NODE(&waiter->pi_tree_entry);
> >  }
> >  
> > +static void rt_mutex_adjust_prio(struct task_struct *p)
> >  {
> > +	struct task_struct *pi_task = NULL;
> >  
> > +	lockdep_assert_held(&p->pi_lock);
> >  
> > +	if (!task_has_pi_waiters(p))
> 
> Shouldn't this be the other way around?
> 
>  if (task_has_pi_waiters(p))
>  	pi_task = ...

Yeah, that would make more sense :-)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web