kernel warning: tried to kill an mm-less task!

kernel warning: tried to kill an mm-less task!

[Li Zefan]

When I ran the same test program I described in a previous patch,
I got the following warning:

WARNING: at mm/oom_kill.c:320 __oom_kill_task+0x6d/0x101()
Modules linked in: 

Pid: 3856, comm: a.out Not tainted 2.6.25-rc8-mm2 #37
 [<ffffffff80243941>] warn_on_slowpath+0x64/0xa2
 [<ffffffff80244e16>] printk+0x5e/0x7b
 [<ffffffff8022b096>] page_count+0x25/0x49
 [<ffffffff8022b2cd>] show_mem+0x125/0x15a
 [<ffffffff8028f00f>] __oom_kill_task+0x6d/0x101
 [<ffffffff8028f319>] oom_kill_process+0x16c/0x22e
 [<ffffffff8028f72c>] select_bad_process+0xb0/0x122
 [<ffffffff8028f8d3>] mem_cgroup_out_of_memory+0x65/0x8a
 [<ffffffff802bee84>] mem_cgroup_charge_common+0xf8/0x215
 [<ffffffff802a14ac>] handle_mm_fault+0x216/0x6c8
 [<ffffffff8029ebca>] follow_page+0x191/0x27d
 [<ffffffff80234155>] need_resched+0x31/0x4f
 [<ffffffff802a1c53>] get_user_pages+0x2f5/0x3eb
 [<ffffffff802a1f64>] make_pages_present+0x9e/0xca
 [<ffffffff802a51fc>] mmap_region+0x38c/0x452
 [<ffffffff802119c4>] arch_get_unmapped_area_topdown+0x1bf/0x2a7
 [<ffffffff802a5971>] do_mmap_pgoff+0x321/0x39b
 [<ffffffff805037ee>] _cond_resched+0x1c/0x5f
 [<ffffffff80211715>] sys_mmap+0xf5/0x138
 [<ffffffff8020c6d2>] tracesys+0xd5/0xda
---[ end trace fe959fb2f0473e7c ]---
tried to kill an mm-less task!

This showed up several times in some seconds, but then didn't appear
any more. And it's reproducable in a x86_64 box, but doesn't happen
in a x86_32 one.

And this happens both with and without the oops fixing.

Regards,
Li Zefan

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: kernel warning: tried to kill an mm-less task!

[KAMEZAWA Hiroyuki]

On Mon, 14 Apr 2008 15:09:01 +0800
Li Zefan <lizf@cn.fujitsu.com> wrote:

> When I ran the same test program I described in a previous patch,
> I got the following warning:
> 
> WARNING: at mm/oom_kill.c:320 __oom_kill_task+0x6d/0x101()
> Modules linked in: 
> 
> Pid: 3856, comm: a.out Not tainted 2.6.25-rc8-mm2 #37
>  [<ffffffff80243941>] warn_on_slowpath+0x64/0xa2
>  [<ffffffff80244e16>] printk+0x5e/0x7b
>  [<ffffffff8022b096>] page_count+0x25/0x49
>  [<ffffffff8022b2cd>] show_mem+0x125/0x15a
>  [<ffffffff8028f00f>] __oom_kill_task+0x6d/0x101
>  [<ffffffff8028f319>] oom_kill_process+0x16c/0x22e
>  [<ffffffff8028f72c>] select_bad_process+0xb0/0x122
>  [<ffffffff8028f8d3>] mem_cgroup_out_of_memory+0x65/0x8a
>  [<ffffffff802bee84>] mem_cgroup_charge_common+0xf8/0x215
>  [<ffffffff802a14ac>] handle_mm_fault+0x216/0x6c8
>  [<ffffffff8029ebca>] follow_page+0x191/0x27d
>  [<ffffffff80234155>] need_resched+0x31/0x4f
>  [<ffffffff802a1c53>] get_user_pages+0x2f5/0x3eb
>  [<ffffffff802a1f64>] make_pages_present+0x9e/0xca
>  [<ffffffff802a51fc>] mmap_region+0x38c/0x452
>  [<ffffffff802119c4>] arch_get_unmapped_area_topdown+0x1bf/0x2a7
>  [<ffffffff802a5971>] do_mmap_pgoff+0x321/0x39b
>  [<ffffffff805037ee>] _cond_resched+0x1c/0x5f
>  [<ffffffff80211715>] sys_mmap+0xf5/0x138
>  [<ffffffff8020c6d2>] tracesys+0xd5/0xda
> ---[ end trace fe959fb2f0473e7c ]---
> tried to kill an mm-less task!
> 
> This showed up several times in some seconds, but then didn't appear
> any more. And it's reproducable in a x86_64 box, but doesn't happen
> in a x86_32 one.
> 
> And this happens both with and without the oops fixing.
> 

It seems this warning itself is not necessary....

-Kame



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: kernel warning: tried to kill an mm-less task!

[Balbir Singh]

Li Zefan wrote:
> When I ran the same test program I described in a previous patch,
> I got the following warning:
> 
> WARNING: at mm/oom_kill.c:320 __oom_kill_task+0x6d/0x101()
> Modules linked in: 
> 
> Pid: 3856, comm: a.out Not tainted 2.6.25-rc8-mm2 #37
>  [<ffffffff80243941>] warn_on_slowpath+0x64/0xa2
>  [<ffffffff80244e16>] printk+0x5e/0x7b
>  [<ffffffff8022b096>] page_count+0x25/0x49
>  [<ffffffff8022b2cd>] show_mem+0x125/0x15a
>  [<ffffffff8028f00f>] __oom_kill_task+0x6d/0x101
>  [<ffffffff8028f319>] oom_kill_process+0x16c/0x22e
>  [<ffffffff8028f72c>] select_bad_process+0xb0/0x122
>  [<ffffffff8028f8d3>] mem_cgroup_out_of_memory+0x65/0x8a
>  [<ffffffff802bee84>] mem_cgroup_charge_common+0xf8/0x215
>  [<ffffffff802a14ac>] handle_mm_fault+0x216/0x6c8
>  [<ffffffff8029ebca>] follow_page+0x191/0x27d
>  [<ffffffff80234155>] need_resched+0x31/0x4f
>  [<ffffffff802a1c53>] get_user_pages+0x2f5/0x3eb
>  [<ffffffff802a1f64>] make_pages_present+0x9e/0xca
>  [<ffffffff802a51fc>] mmap_region+0x38c/0x452
>  [<ffffffff802119c4>] arch_get_unmapped_area_topdown+0x1bf/0x2a7
>  [<ffffffff802a5971>] do_mmap_pgoff+0x321/0x39b
>  [<ffffffff805037ee>] _cond_resched+0x1c/0x5f
>  [<ffffffff80211715>] sys_mmap+0xf5/0x138
>  [<ffffffff8020c6d2>] tracesys+0xd5/0xda
> ---[ end trace fe959fb2f0473e7c ]---
> tried to kill an mm-less task!
> 
> This showed up several times in some seconds, but then didn't appear
> any more. And it's reproducable in a x86_64 box, but doesn't happen
> in a x86_32 one.
> 
> And this happens both with and without the oops fixing.
> 

Could we get some more details on which task was chosen to be killed? It will be
nice to see the task flags as well to see if PF_EXITING is set.

oom_kill_task() has a big WARNING in the comment

        /* WARNING: mm may not be dereferenced since we did not obtain its
         * value from get_task_mm(p).  This is OK since all we need to do is
         * compare mm to q->mm below.


I want to see the flags to see if

PF_BORROWED_MM or PF_EXIT* is set.


-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: kernel warning: tried to kill an mm-less task!

[Li Zefan]

Balbir Singh wrote:
> Li Zefan wrote:
>> When I ran the same test program I described in a previous patch,
>> I got the following warning:
>>
>> WARNING: at mm/oom_kill.c:320 __oom_kill_task+0x6d/0x101()
>> Modules linked in: 
>>
>> Pid: 3856, comm: a.out Not tainted 2.6.25-rc8-mm2 #37
>>  [<ffffffff80243941>] warn_on_slowpath+0x64/0xa2
>>  [<ffffffff80244e16>] printk+0x5e/0x7b
>>  [<ffffffff8022b096>] page_count+0x25/0x49
>>  [<ffffffff8022b2cd>] show_mem+0x125/0x15a
>>  [<ffffffff8028f00f>] __oom_kill_task+0x6d/0x101
>>  [<ffffffff8028f319>] oom_kill_process+0x16c/0x22e
>>  [<ffffffff8028f72c>] select_bad_process+0xb0/0x122
>>  [<ffffffff8028f8d3>] mem_cgroup_out_of_memory+0x65/0x8a
>>  [<ffffffff802bee84>] mem_cgroup_charge_common+0xf8/0x215
>>  [<ffffffff802a14ac>] handle_mm_fault+0x216/0x6c8
>>  [<ffffffff8029ebca>] follow_page+0x191/0x27d
>>  [<ffffffff80234155>] need_resched+0x31/0x4f
>>  [<ffffffff802a1c53>] get_user_pages+0x2f5/0x3eb
>>  [<ffffffff802a1f64>] make_pages_present+0x9e/0xca
>>  [<ffffffff802a51fc>] mmap_region+0x38c/0x452
>>  [<ffffffff802119c4>] arch_get_unmapped_area_topdown+0x1bf/0x2a7
>>  [<ffffffff802a5971>] do_mmap_pgoff+0x321/0x39b
>>  [<ffffffff805037ee>] _cond_resched+0x1c/0x5f
>>  [<ffffffff80211715>] sys_mmap+0xf5/0x138
>>  [<ffffffff8020c6d2>] tracesys+0xd5/0xda
>> ---[ end trace fe959fb2f0473e7c ]---
>> tried to kill an mm-less task!
>>
>> This showed up several times in some seconds, but then didn't appear
>> any more. And it's reproducable in a x86_64 box, but doesn't happen
>> in a x86_32 one.
>>
>> And this happens both with and without the oops fixing.
>>
> 
> Could we get some more details on which task was chosen to be killed? It will be
> nice to see the task flags as well to see if PF_EXITING is set.
> 
> oom_kill_task() has a big WARNING in the comment
> 
>         /* WARNING: mm may not be dereferenced since we did not obtain its
>          * value from get_task_mm(p).  This is OK since all we need to do is
>          * compare mm to q->mm below.
> 
> 
> I want to see the flags to see if
> 
> PF_BORROWED_MM or PF_EXIT* is set.
> 
> 

OK, I'll try.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: kernel warning: tried to kill an mm-less task!

[Li Zefan]

Li Zefan wrote:
> Balbir Singh wrote:
>> Li Zefan wrote:
>>> When I ran the same test program I described in a previous patch,
>>> I got the following warning:
>>>
>>> WARNING: at mm/oom_kill.c:320 __oom_kill_task+0x6d/0x101()
>>> Modules linked in: 
>>>
>>> Pid: 3856, comm: a.out Not tainted 2.6.25-rc8-mm2 #37
>>>  [<ffffffff80243941>] warn_on_slowpath+0x64/0xa2
>>>  [<ffffffff80244e16>] printk+0x5e/0x7b
>>>  [<ffffffff8022b096>] page_count+0x25/0x49
>>>  [<ffffffff8022b2cd>] show_mem+0x125/0x15a
>>>  [<ffffffff8028f00f>] __oom_kill_task+0x6d/0x101
>>>  [<ffffffff8028f319>] oom_kill_process+0x16c/0x22e
>>>  [<ffffffff8028f72c>] select_bad_process+0xb0/0x122
>>>  [<ffffffff8028f8d3>] mem_cgroup_out_of_memory+0x65/0x8a
>>>  [<ffffffff802bee84>] mem_cgroup_charge_common+0xf8/0x215
>>>  [<ffffffff802a14ac>] handle_mm_fault+0x216/0x6c8
>>>  [<ffffffff8029ebca>] follow_page+0x191/0x27d
>>>  [<ffffffff80234155>] need_resched+0x31/0x4f
>>>  [<ffffffff802a1c53>] get_user_pages+0x2f5/0x3eb
>>>  [<ffffffff802a1f64>] make_pages_present+0x9e/0xca
>>>  [<ffffffff802a51fc>] mmap_region+0x38c/0x452
>>>  [<ffffffff802119c4>] arch_get_unmapped_area_topdown+0x1bf/0x2a7
>>>  [<ffffffff802a5971>] do_mmap_pgoff+0x321/0x39b
>>>  [<ffffffff805037ee>] _cond_resched+0x1c/0x5f
>>>  [<ffffffff80211715>] sys_mmap+0xf5/0x138
>>>  [<ffffffff8020c6d2>] tracesys+0xd5/0xda
>>> ---[ end trace fe959fb2f0473e7c ]---
>>> tried to kill an mm-less task!
>>>
>>> This showed up several times in some seconds, but then didn't appear
>>> any more. And it's reproducable in a x86_64 box, but doesn't happen
>>> in a x86_32 one.
>>>
>>> And this happens both with and without the oops fixing.
>>>
>> Could we get some more details on which task was chosen to be killed? It will be
>> nice to see the task flags as well to see if PF_EXITING is set.
>>
>> oom_kill_task() has a big WARNING in the comment
>>
>>         /* WARNING: mm may not be dereferenced since we did not obtain its
>>          * value from get_task_mm(p).  This is OK since all we need to do is
>>          * compare mm to q->mm below.
>>
>>
>> I want to see the flags to see if
>>
>> PF_BORROWED_MM or PF_EXIT* is set.
>>
>>
> 
> OK, I'll try.
> 
> --

I Added 2 printk()s:

 static void __oom_kill_task(struct task_struct *p, int verbose)
 {
+       printk(KERN_WARNING "pid = %d, flags = %x\n", p->pid, p->flags);
+
        if (is_global_init(p)) {
                WARN_ON(1);
                printk(KERN_WARNING "tried to kill init!\n");
@@ -319,6 +320,7 @@ static void __oom_kill_task(struct task_struct *p, int verbo

        if (!p->mm) {
                WARN_ON(1);
+               printk(KERN_WARNING "pid = %d, flags = %x\n", p->pid, p->flags);
                printk(KERN_WARNING "tried to kill an mm-less task!\n");
                return;
        }

got this:

pid = 3817, flags = 400140
------------[ cut here ]------------
WARNING: at mm/oom_kill.c:322 __oom_kill_task+0x74/0xf1()
...
---[ end trace bb92f2fd8fe6c7c5 ]---
pid = 3817, flags = 400144
tried to kill an mm-less task!

So PF_EXITING may be set during the call of oom_kill_task(), and I notice
the comment in oom_kill_task():

	 * Furthermore, even if mm contains a non-NULL value, p->mm may
	 * change to NULL at any time since we do not hold task_lock(p).
	 * However, this is of no concern to us.

Is this warning just harmless so that we can just ignore it ?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: kernel warning: tried to kill an mm-less task!

[Oleg Nesterov]

(cc Roland)

On 04/15, Li Zefan wrote:
>
> Li Zefan wrote:
> > Balbir Singh wrote:
> >> Li Zefan wrote:
> >>> When I ran the same test program I described in a previous patch,
> >>> I got the following warning:
> >>>
> >>> WARNING: at mm/oom_kill.c:320 __oom_kill_task+0x6d/0x101()
> >>> Modules linked in: 
> >>>
> 
> I Added 2 printk()s:
> 
>  static void __oom_kill_task(struct task_struct *p, int verbose)
>  {
> +       printk(KERN_WARNING "pid = %d, flags = %x\n", p->pid, p->flags);
> +
>         if (is_global_init(p)) {
>                 WARN_ON(1);
>                 printk(KERN_WARNING "tried to kill init!\n");
> @@ -319,6 +320,7 @@ static void __oom_kill_task(struct task_struct *p, int verbo
> 
>         if (!p->mm) {
>                 WARN_ON(1);
> +               printk(KERN_WARNING "pid = %d, flags = %x\n", p->pid, p->flags);
>                 printk(KERN_WARNING "tried to kill an mm-less task!\n");
>                 return;
>         }
> 
> got this:
> 
> pid = 3817, flags = 400140
> ------------[ cut here ]------------
> WARNING: at mm/oom_kill.c:322 __oom_kill_task+0x74/0xf1()
> ...
> ---[ end trace bb92f2fd8fe6c7c5 ]---
> pid = 3817, flags = 400144
> tried to kill an mm-less task!
> 
> So PF_EXITING may be set during the call of oom_kill_task(), and I notice
> the comment in oom_kill_task():
> 
> 	 * Furthermore, even if mm contains a non-NULL value, p->mm may
> 	 * change to NULL at any time since we do not hold task_lock(p).
> 	 * However, this is of no concern to us.
> 
> Is this warning just harmless so that we can just ignore it ?

Yes sure, tasklist_lock can't prevent the task exiting, it only protects
from release_task(). And task->mm == NULL after do_exit()->exit_mm().
Perhaps we can check "!p->mm && !PF_EXITING".

I don't think we should check PF_BORROWED_MM in __oom_kill_task(), it is
too late.

Perhaps,

	--- fs/aio.c	2008-02-17 23:40:07.000000000 +0300
	+++ fs/aio.c	2008-04-15 09:31:23.841202187 +0400
	@@ -579,6 +579,7 @@ static void use_mm(struct mm_struct *mm)
	 
		task_lock(tsk);
		tsk->flags |= PF_BORROWED_MM;
	+	smp_wmb();
		active_mm = tsk->active_mm;
		atomic_inc(&mm->mm_count);
		tsk->mm = mm;
	@@ -606,13 +607,23 @@ static void unuse_mm(struct mm_struct *m
		struct task_struct *tsk = current;
	 
		task_lock(tsk);
	-	tsk->flags &= ~PF_BORROWED_MM;
		tsk->mm = NULL;
	+	smp_wmb();
	+	tsk->flags &= ~PF_BORROWED_MM;
		/* active_mm is still 'mm' */
		enter_lazy_tlb(mm, tsk);
		task_unlock(tsk);
	 }
	 
	+struct mm_struct *__get_task_mm(struct task_struct *tsk)
	+{
	+	struct mm_struct *mm = tsk->mm;
	+	smp_rmb();
	+	if (tsk->flags & PF_BORROWED_MM)
	+		mm = NULL;
	+	return mm;
	+}
	+
	 /*
	  * Queue up a kiocb to be retried. Assumes that the kiocb
	  * has already been marked as kicked, and places it on

Now oom_kill_task/select_bad_process/etc can use __get_task_mm() to avoid
killing the kernel thread.

Off-topic: why ->oomkilladj is per thread, not per process? All threads share
the same ->mm. Note oom_kill_process(), it shouldn't use do_each_thread(),
it actually needs for_each_process().


Roland, what do you think about the coredump? Looks like we have the ancient
bug, zap_threads() can hit the kernel thread.

How about

	--- fs/exec.c	2008-02-17 23:40:07.000000000 +0300
	+++ fs/exec.c	2008-04-15 10:07:08.998518272 +0400
	@@ -1547,7 +1547,7 @@ static inline int zap_threads(struct tas
			p = g;
			do {
				if (p->mm) {
	-				if (p->mm == mm) {
	+				if (__get_task_mm(p) == mm) {
						/*
						 * p->sighand can't disappear, but
						 * may be changed by de_thread()

?

Oleg.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

s/PF_BORROWED_MM/PF_KTHREAD/ (was: kernel warning: tried to kill an mm-less task!)

[Oleg Nesterov]

On 04/15, Oleg Nesterov wrote:
>
> 	+struct mm_struct *__get_task_mm(struct task_struct *tsk)
> 	+{
> 	+	struct mm_struct *mm = tsk->mm;
> 	+	smp_rmb();
> 	+	if (tsk->flags & PF_BORROWED_MM)
> 	+		mm = NULL;
> 	+	return mm;
> 	+}

No, this is racy wrt unuse_mm(), we still need task_lock().

Actually, I think PF_BORROWED_MM should die, and PF_I_AM_A_KERNEL_THREAD
is better, see the "patch" below.

First, include/asm-um/mmu_context.h:activate_mm() doesn't look right to me,
use_mm() does switch_mm(), not activate_mm(), so I think we can do

	--- include/asm-um/mmu_context.h	2008-02-17 23:40:08.000000000 +0300
	+++ -	2008-04-15 13:35:34.089295980 +0400
	@@ -29,7 +29,7 @@ static inline void activate_mm(struct mm
		 * host. Since they're very expensive, we want to avoid that as far as
		 * possible.
		 */
	-	if (old != new && (current->flags & PF_BORROWED_MM))
	+	if (old != new)
			__switch_mm(&new->context.id);
	 
		arch_dup_mmap(old, new);

With this + patch below, we can make a simple helper,

	/* The result must not be dereferenced !!! */
	struct mm_struct *__get_task_mm(struct task_struct *tsk)
	{
		if (tsk->flags & PF_KTHREAD)
			return NULL;
		return tsk->mm;
	}

it could ve used by oom_kill/coredump/ptrace_attach instead of "->mm != NULL"
which doesn't really work. Note also that ecard_task() runs with mm != NULL,
but it is the kernel thread without PF_BORROWED_MM.

daemonize() is racy, but it is hopeless anyway.

Oleg.

--- include/linux/sched.h	2008-02-17 23:40:09.000000000 +0300
+++ -	2008-04-15 11:38:46.892847693 +0400
@@ -1458,7 +1458,7 @@ static inline void put_task_struct(struc
 #define PF_KSWAPD	0x00040000	/* I am kswapd */
 #define PF_SWAPOFF	0x00080000	/* I am in swapoff */
 #define PF_LESS_THROTTLE 0x00100000	/* Throttle me less: I clean memory */
-#define PF_BORROWED_MM	0x00200000	/* I am a kthread doing use_mm */
+#define PF_KTHREAD	0x00200000	/* I am a kernel thread */
 #define PF_RANDOMIZE	0x00400000	/* randomize virtual address space */
 #define PF_SWAPWRITE	0x00800000	/* Allowed to write to swap */
 #define PF_SPREAD_PAGE	0x01000000	/* Spread page cache over cpuset */
--- kernel/power/process.c	2008-02-17 23:40:09.000000000 +0300
+++ -	2008-04-15 11:41:13.044031366 +0400
@@ -93,7 +93,7 @@ static void send_fake_signal(struct task
 
 static int has_mm(struct task_struct *p)
 {
-	return (p->mm && !(p->flags & PF_BORROWED_MM));
+	return (p->mm && !(p->flags & PF_KTHREAD));
 }
 
 /**
--- fs/aio.c	2008-02-17 23:40:07.000000000 +0300
+++ -	2008-04-15 11:44:11.100698248 +0400
@@ -578,15 +578,10 @@ static void use_mm(struct mm_struct *mm)
 	struct task_struct *tsk = current;
 
 	task_lock(tsk);
-	tsk->flags |= PF_BORROWED_MM;
 	active_mm = tsk->active_mm;
 	atomic_inc(&mm->mm_count);
 	tsk->mm = mm;
 	tsk->active_mm = mm;
-	/*
-	 * Note that on UML this *requires* PF_BORROWED_MM to be set, otherwise
-	 * it won't work. Update it accordingly if you change it here
-	 */
 	switch_mm(active_mm, mm, tsk);
 	task_unlock(tsk);
 
@@ -606,7 +601,6 @@ static void unuse_mm(struct mm_struct *m
 	struct task_struct *tsk = current;
 
 	task_lock(tsk);
-	tsk->flags &= ~PF_BORROWED_MM;
 	tsk->mm = NULL;
 	/* active_mm is still 'mm' */
 	enter_lazy_tlb(mm, tsk);
--- kernel/fork.c	2008-02-17 23:40:09.000000000 +0300
+++ -	2008-04-15 11:48:24.539070614 +0400
@@ -424,7 +424,7 @@ EXPORT_SYMBOL_GPL(mmput);
 /**
  * get_task_mm - acquire a reference to the task's mm
  *
- * Returns %NULL if the task has no mm.  Checks PF_BORROWED_MM (meaning
+ * Returns %NULL if the task has no mm.  Checks PF_KTHREAD (meaning
  * this kernel workthread has transiently adopted a user mm with use_mm,
  * to do its AIO) is not set and if so returns a reference to it, after
  * bumping up the use count.  User must release the mm via mmput()
@@ -437,7 +437,7 @@ struct mm_struct *get_task_mm(struct tas
 	task_lock(task);
 	mm = task->mm;
 	if (mm) {
-		if (task->flags & PF_BORROWED_MM)
+		if (task->flags & PF_KTHREAD)
 			mm = NULL;
 		else
 			atomic_inc(&mm->mm_users);
--- kernel/kthread.c	2008-02-17 23:40:09.000000000 +0300
+++ -	2008-04-15 11:51:06.014085477 +0400
@@ -234,7 +234,7 @@ int kthreadd(void *unused)
 	set_user_nice(tsk, KTHREAD_NICE_LEVEL);
 	set_cpus_allowed(tsk, CPU_MASK_ALL);
 
-	current->flags |= PF_NOFREEZE;
+	current->flags |= (PF_NOFREEZE | PF_KTHREAD);
 
 	for (;;) {
 		set_current_state(TASK_INTERRUPTIBLE);
--- fs/exec.c	2008-02-17 23:40:07.000000000 +0300
+++ -	2008-04-15 12:33:10.854945536 +0400
@@ -1328,6 +1328,7 @@ int do_execve(char * filename,
 		goto out;
 	bprm->argv_len = env_p - bprm->p;
 
+	current->flags &= ~PF_KTHREAD;
 	retval = search_binary_handler(bprm,regs);
 	if (retval >= 0) {
 		/* execve success */
--- kernel/exit.c	2008-02-17 23:40:09.000000000 +0300
+++ -	2008-04-15 13:49:30.916850385 +0400
@@ -382,7 +382,7 @@ void daemonize(const char *name, ...)
 	 * We don't want to have TIF_FREEZE set if the system-wide hibernation
 	 * or suspend transition begins right now.
 	 */
-	current->flags |= PF_NOFREEZE;
+	current->flags |= (PF_NOFREEZE | PF_KTHREAD);
 
 	if (current->nsproxy != &init_nsproxy) {
 		get_nsproxy(&init_nsproxy);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: s/PF_BORROWED_MM/PF_KTHREAD/ (was: kernel warning: tried to kill an mm-less task!)

[Jeff Dike]

On Tue, Apr 15, 2008 at 02:19:05PM +0400, Oleg Nesterov wrote:
> First, include/asm-um/mmu_context.h:activate_mm() doesn't look right to me,
> use_mm() does switch_mm(), not activate_mm(), so I think we can do
> 
> 	--- include/asm-um/mmu_context.h	2008-02-17 23:40:08.000000000 +0300
> 	+++ -	2008-04-15 13:35:34.089295980 +0400
> 	@@ -29,7 +29,7 @@ static inline void activate_mm(struct mm
> 		 * host. Since they're very expensive, we want to avoid that as far as
> 		 * possible.
> 		 */
> 	-	if (old != new && (current->flags & PF_BORROWED_MM))
> 	+	if (old != new)
> 			__switch_mm(&new->context.id);
> 	 
> 		arch_dup_mmap(old, new);

I'm thinking I can just change this to call switch_mm, getting rid of
the old != new test too.

Plus, you can get rid of the comment in use_mm about UML needing
PF_BORROWED_MM.

I'll test this to make sure.

			Jeff

-- 
Work email - jdike at linux dot intel dot com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: kernel warning: tried to kill an mm-less task!

[Roland McGrath]

> Roland, what do you think about the coredump? Looks like we have the ancient
> bug, zap_threads() can hit the kernel thread.

I think you're right.  But I've never known much about the ->mm maintenance
code or the aio use_mm logic.  So I'm just going from a quick glance.
(That part of the zap_threads() logic predates you or I fiddling with it.)


Thanks,
Roland

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>