[PATCH] Fix check after use in kernel/exit.c

[PATCH] Fix check after use in kernel/exit.c

[WANG Cong]

mm_release won't check the mm_struct pointer, so it should
be checked before this call.

This patch was first posted here[1], and I don't know
why it was not accepted yet.

Thanks to "G. Vaughan" to remind me about this.

1. http://lkml.org/lkml/2007/11/15/520

Cc: Ingo Molnar <mingo@elte.hu>
Cc: "G. Vaughan" <gvaughan@jpl.nasa.gov>
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>

---
 kernel/exit.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index cd20bf0..0cb9cce 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -582,9 +582,9 @@ static void exit_mm(struct task_struct * tsk)
 {
 	struct mm_struct *mm = tsk->mm;
 
-	mm_release(tsk, mm);
 	if (!mm)
 		return;
+	mm_release(tsk, mm);
 	/*
 	 * Serialize with any possible pending coredump.
 	 * We must hold mmap_sem around checking core_waiters
-- 
1.5.2.4

Re: [PATCH] Fix check after use in kernel/exit.c

[Ingo Molnar]

* WANG Cong <xiyou.wangcong@gmail.com> wrote:

> mm_release won't check the mm_struct pointer, so it should be checked 
> before this call.

> @@ -582,9 +582,9 @@ static void exit_mm(struct task_struct * tsk)
>  {
>  	struct mm_struct *mm = tsk->mm;
>  
> -	mm_release(tsk, mm);
>  	if (!mm)
>  		return;
> +	mm_release(tsk, mm);

thanks, applied. I'm wondering why this never seems to hit in practice.

	Ingo

Re: [PATCH] Fix check after use in kernel/exit.c

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> > @@ -582,9 +582,9 @@ static void exit_mm(struct task_struct * tsk)
> >  {
> >  	struct mm_struct *mm = tsk->mm;
> >  
> > -	mm_release(tsk, mm);
> >  	if (!mm)
> >  		return;
> > +	mm_release(tsk, mm);
> 
> thanks, applied. I'm wondering why this never seems to hit in 
> practice.

actually, i unapplied it again because the patch is wrong: mm_release() 
has side-effects for kernel threads such as the deactivate_mm() [which 
is important even if the user-mm is NULL]. If the NULL mm dereference 
can really trigger then it should be avoided within mm_release().

	Ingo

Re: [PATCH] Fix check after use in kernel/exit.c

[WANG Cong]

From: Ingo Molnar <mingo@elte.hu>
Date: Sat, 8 Mar 2008 09:53:22 +0100

> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > > @@ -582,9 +582,9 @@ static void exit_mm(struct task_struct * tsk)
> > >  {
> > >  	struct mm_struct *mm = tsk->mm;
> > >  
> > > -	mm_release(tsk, mm);
> > >  	if (!mm)
> > >  		return;
> > > +	mm_release(tsk, mm);
> > 
> > thanks, applied. I'm wondering why this never seems to hit in 
> > practice.
> 
> actually, i unapplied it again because the patch is wrong: mm_release() 
> has side-effects for kernel threads such as the deactivate_mm() [which 
> is important even if the user-mm is NULL]. If the NULL mm dereference 
> can really trigger then it should be avoided within mm_release().
> 

Do you mean that the NULL check should be moved into mm_release()?

Thanks!

Re: [PATCH] Fix check after use in kernel/exit.c

[Ingo Molnar]

* WANG Cong <xiyou.wangcong@gmail.com> wrote:

> > actually, i unapplied it again because the patch is wrong: 
> > mm_release() has side-effects for kernel threads such as the 
> > deactivate_mm() [which is important even if the user-mm is NULL]. If 
> > the NULL mm dereference can really trigger then it should be avoided 
> > within mm_release().
> 
> Do you mean that the NULL check should be moved into mm_release()?

yes - we need to run deactivate_mm() for kernel threads.

	Ingo

Re: [PATCH] Fix check after use in kernel/exit.c

[WANG Cong]

From: Ingo Molnar <mingo@elte.hu>
Date: Sun, 9 Mar 2008 12:48:44 +0100

> 
> * WANG Cong <xiyou.wangcong@gmail.com> wrote:
> 
> > > actually, i unapplied it again because the patch is wrong: 
> > > mm_release() has side-effects for kernel threads such as the 
> > > deactivate_mm() [which is important even if the user-mm is NULL]. If 
> > > the NULL mm dereference can really trigger then it should be avoided 
> > > within mm_release().
> > 
> > Do you mean that the NULL check should be moved into mm_release()?
> 
> yes - we need to run deactivate_mm() for kernel threads.


Thank you for your kind hints.

Here is an updated version. Please check.

---->

From: WANG Cong <xiyou.wangcong@gmail.com>
Subject: [PATCH] Fix check after use in kernel/exit.c

As suggested by Ingo, the NULL deference check should be moved
into mm_release().

Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>

---
 kernel/exit.c |    2 --
 kernel/fork.c |    2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index 53872bf..b88244a 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -583,8 +583,6 @@ static void exit_mm(struct task_struct * tsk)
 	struct mm_struct *mm = tsk->mm;
 
 	mm_release(tsk, mm);
-	if (!mm)
-		return;
 	/*
 	 * Serialize with any possible pending coredump.
 	 * We must hold mmap_sem around checking core_waiters
diff --git a/kernel/fork.c b/kernel/fork.c
index dd249c3..7683c5f 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -464,6 +464,8 @@ void mm_release(struct task_struct *tsk, struct mm_struct *mm)
 {
 	struct completion *vfork_done = tsk->vfork_done;
 
+	if (!mm)
+		return;
 	/* Get rid of any cached register state */
 	deactivate_mm(tsk, mm);
 
-- 
1.5.2.4

Re: [PATCH] Fix check after use in kernel/exit.c

[Ingo Molnar]

* WANG Cong <xiyou.wangcong@gmail.com> wrote:

> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -583,8 +583,6 @@ static void exit_mm(struct task_struct * tsk)
>  	struct mm_struct *mm = tsk->mm;
>  
>  	mm_release(tsk, mm);
> -	if (!mm)
> -		return;

> @@ -464,6 +464,8 @@ void mm_release(struct task_struct *tsk, struct mm_struct *mm)
>  {
>  	struct completion *vfork_done = tsk->vfork_done;
>  
> +	if (!mm)
> +		return;
>  	/* Get rid of any cached register state */
>  	deactivate_mm(tsk, mm);

no, this is buggy in the same way - we wont do a deactivate_mm() for 
kernel threads. The check should be left alone in exit_mm(), we should 
at most add a check for NULL mm to this place:

        if (tsk->clear_child_tid
            && !(tsk->flags & PF_SIGNALED)
            && atomic_read(&mm->mm_users) > 1) {

but ... can mm in fact ever be NULL if tsk->clear_child_tid is set?

	Ingo