[PATCH] rtmutex.c: Fix incorrect waiter check

[PATCH] rtmutex.c: Fix incorrect waiter check

[Brad Mouring]

In task_blocks_on_lock, there's a null check on pi_blocked_on
of the task_struct. This pointer can encode the fact that the
task that contains the pointer is waking (preventing requeuing)
and therefore is non-null. Use the inline function to avoid
dereferencing an invalid "pointer"

Signed-off-by: Brad Mouring <brad.mouring@ni.com>
Reported-by: Ben Shelton <ben.shelton@ni.com>
---
 kernel/locking/rtmutex.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 6c40660..535321e 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -335,7 +335,8 @@ int max_lock_depth = 1024;
 
 static inline struct rt_mutex *task_blocked_on_lock(struct task_struct *p)
 {
-	return p->pi_blocked_on ? p->pi_blocked_on->lock : NULL;
+	return rt_mutex_real_waiter(p->pi_blocked_on) ?
+		p->pi_blocked_on->lock : NULL;
 }
 
 /*
-- 
1.8.3-rc3

Re: [PATCH] rtmutex.c: Fix incorrect waiter check

[Thavatchai Makphaibulchoke]

Yes, agreed.  Using the macro (), as done in the patch, is the correct
way to avoid invalid pointer dereferencing.

Tested with patch-3.14.25-rt22 patch on a 2 socket platform.

Reviewed-by: T Makphaibulchoke <tmac@hp.cojm>
Tested-by: T Makphaibulchoke <tmac@hp.cojm>


On 12/05/2014 12:35 PM, Brad Mouring wrote:
> In task_blocks_on_lock, there's a null check on pi_blocked_on
> of the task_struct. This pointer can encode the fact that the
> task that contains the pointer is waking (preventing requeuing)
> and therefore is non-null. Use the inline function to avoid
> dereferencing an invalid "pointer"
> 
> Signed-off-by: Brad Mouring <brad.mouring@ni.com>
> Reported-by: Ben Shelton <ben.shelton@ni.com>
> ---
>  kernel/locking/rtmutex.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
> index 6c40660..535321e 100644
> --- a/kernel/locking/rtmutex.c
> +++ b/kernel/locking/rtmutex.c
> @@ -335,7 +335,8 @@ int max_lock_depth = 1024;
>  
>  static inline struct rt_mutex *task_blocked_on_lock(struct task_struct *p)
>  {
> -	return p->pi_blocked_on ? p->pi_blocked_on->lock : NULL;
> +	return rt_mutex_real_waiter(p->pi_blocked_on) ?
> +		p->pi_blocked_on->lock : NULL;
>  }
>  
>  /*
> 

[re: PATCH] rtmutex.c: Fix incorrect waiter check

[Brad Mouring]

Putting this back to the list since I've only received positive feedback for this simple change.

[PATCH] rtmutex.c: Fix incorrect waiter check

[Brad Mouring]

In task_blocks_on_lock, there's a null check on pi_blocked_on
of the task_struct. This pointer can encode the fact that the
task that contains the pointer is waking (preventing requeuing)
and therefore is non-null. Use the inline function to avoid
dereferencing an invalid "pointer"

Signed-off-by: Brad Mouring <brad.mouring@ni.com>
Reported-by: Ben Shelton <ben.shelton@ni.com>
Reviewed-by: T Makphaibulchoke <tmac@hp.com>
Tested-by: T Makphaibulchoke <tmac@hp.com>
---
 kernel/locking/rtmutex.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 6c40660..535321e 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -335,7 +335,8 @@ int max_lock_depth = 1024;
 
 static inline struct rt_mutex *task_blocked_on_lock(struct task_struct *p)
 {
-	return p->pi_blocked_on ? p->pi_blocked_on->lock : NULL;
+	return rt_mutex_real_waiter(p->pi_blocked_on) ?
+		p->pi_blocked_on->lock : NULL;
 }
 
 /*
-- 
1.8.3-rc3

Re: [PATCH] rtmutex.c: Fix incorrect waiter check

[Steven Rostedt]

On Wed, 14 Jan 2015 15:11:38 -0600
"Brad Mouring" <bmouring@ni.com> wrote:

> In task_blocks_on_lock, there's a null check on pi_blocked_on
> of the task_struct. This pointer can encode the fact that the
> task that contains the pointer is waking (preventing requeuing)
> and therefore is non-null. Use the inline function to avoid
> dereferencing an invalid "pointer"

Yep, this looks legit. I can apply it to the series I maintain.

-- Steve

> 
> Signed-off-by: Brad Mouring <brad.mouring@ni.com>
> Reported-by: Ben Shelton <ben.shelton@ni.com>
> Reviewed-by: T Makphaibulchoke <tmac@hp.com>
> Tested-by: T Makphaibulchoke <tmac@hp.com>
> ---
>  kernel/locking/rtmutex.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
> index 6c40660..535321e 100644
> --- a/kernel/locking/rtmutex.c
> +++ b/kernel/locking/rtmutex.c
> @@ -335,7 +335,8 @@ int max_lock_depth = 1024;
>  
>  static inline struct rt_mutex *task_blocked_on_lock(struct task_struct *p)
>  {
> -	return p->pi_blocked_on ? p->pi_blocked_on->lock : NULL;
> +	return rt_mutex_real_waiter(p->pi_blocked_on) ?
> +		p->pi_blocked_on->lock : NULL;
>  }
>  
>  /*

Re: [PATCH] rtmutex.c: Fix incorrect waiter check

[Sebastian Andrzej Siewior]

* Steven Rostedt | 2015-01-21 15:13:52 [-0500]:

>On Wed, 14 Jan 2015 15:11:38 -0600
>"Brad Mouring" <bmouring@ni.com> wrote:
>
>> In task_blocks_on_lock, there's a null check on pi_blocked_on
>> of the task_struct. This pointer can encode the fact that the
>> task that contains the pointer is waking (preventing requeuing)
>> and therefore is non-null. Use the inline function to avoid
>> dereferencing an invalid "pointer"
>
>Yep, this looks legit. I can apply it to the series I maintain.

I added it to v3.18 with a stable tag. I don't know why this did not
pop-up earlier or if this is part of the rtmutex re-write.

>-- Steve

Sebastian

AW: [PATCH] rtmutex.c: Fix incorrect waiter check

[eg Engleder Gerhard]

Hello Steven,

I had the following problem with 3.2.68-rt99:
<1>[ 1615.388250] BUG: unable to handle kernel NULL pointer dereference at 0000002d
<1>[ 1615.388261] IP: [<c106d006>] task_blocks_on_rt_mutex+0x126/0x240

We could reproduce it rather good, 2 times BUG out of 4 tries. Sebastian pointed
me to the patch below. 8 times no BUG out of 8 tries with the patch now. As Sebastian
is not available currently, I thought I should let you know. Could you add this patch
to 3.2.69-rt102?

Regards, Gerhard

> On Wed, 14 Jan 2015 15:11:38 -0600
> "Brad Mouring" <bmouring@ni.com> wrote:
> 
> > In task_blocks_on_lock, there's a null check on pi_blocked_on of the
> > task_struct. This pointer can encode the fact that the task that
> > contains the pointer is waking (preventing requeuing) and therefore is
> > non-null. Use the inline function to avoid dereferencing an invalid
> > "pointer"
> 
> Yep, this looks legit. I can apply it to the series I maintain.
> 
> -- Steve
> 
> >
> > Signed-off-by: Brad Mouring <brad.mouring@ni.com>
> > Reported-by: Ben Shelton <ben.shelton@ni.com>
> > Reviewed-by: T Makphaibulchoke <tmac@hp.com>
> > Tested-by: T Makphaibulchoke <tmac@hp.com>
> > ---
> >  kernel/locking/rtmutex.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index
> > 6c40660..535321e 100644
> > --- a/kernel/locking/rtmutex.c
> > +++ b/kernel/locking/rtmutex.c
> > @@ -335,7 +335,8 @@ int max_lock_depth = 1024;
> >
> >  static inline struct rt_mutex *task_blocked_on_lock(struct
> > task_struct *p)  {
> > -	return p->pi_blocked_on ? p->pi_blocked_on->lock : NULL;
> > +	return rt_mutex_real_waiter(p->pi_blocked_on) ?
> > +		p->pi_blocked_on->lock : NULL;
> >  }
> >
> >  /*
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body
> of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rtmutex.c: Fix incorrect waiter check

[Steven Rostedt]

On Mon, 17 Aug 2015 12:41:47 +0200
eg Engleder Gerhard <eg@keba.com> wrote:

> Hello Steven,
> 
> I had the following problem with 3.2.68-rt99:
> <1>[ 1615.388250] BUG: unable to handle kernel NULL pointer dereference at 0000002d
> <1>[ 1615.388261] IP: [<c106d006>] task_blocks_on_rt_mutex+0x126/0x240
> 
> We could reproduce it rather good, 2 times BUG out of 4 tries. Sebastian pointed
> me to the patch below. 8 times no BUG out of 8 tries with the patch now. As Sebastian
> is not available currently, I thought I should let you know. Could you add this patch
> to 3.2.69-rt102?
> 

Yes, I'm the one to apply it to 3.2-rt, as Sebastian is responsible for
the development branch and I'm responsible for the stable tree.

I'm currently at LinuxCon, but I'll see if I can get this done sometime
while I watch the key notes. That's usually when I get the most work
done during a conference ;-)

-- Steve