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

DISCUSSION Li Zefan 6 participants 9 messages Apr 14, 2008 – Apr 15, 2008 Memory management

Share & tools

Li Zefan

author

2008-04-14 07:09 UTC #0 lore raw

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

KAMEZAWA Hiroyuki

2008-04-14 07:46 UTC #1 lore raw

Quoted 28 lines · On Mon, 14 Apr 2008 15:09:01 +0800 Li Zefan <[email protected]> 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 ]---

Quoted 8 lines

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

Balbir Singh

2008-04-14 08:04 UTC #2 lore raw

In reply to Li Zefan

Quoted 28 lines · 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 ]---

Quoted 8 lines

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.

Signature · 10 lines

	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

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

Li Zefan

author

2008-04-14 08:06 UTC #3 lore raw

Quoted 43 lines · Balbir Singh

Quoted 28 lines · 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 ]---
Quoted 8 lines
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

Quoted 10 lines

/* 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.

Li Zefan

author

2008-04-15 03:47 UTC #4 lore raw

Quoted 50 lines · Li Zefan

Quoted 49 lines · Balbir Singh
Quoted 28 lines · 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 ]---
Quoted 8 lines
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

Quoted 7 lines

Quoted 3 lines
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 ?

Oleg Nesterov

2008-04-15 06:17 UTC #5 lore raw

(cc Roland)

Quoted 39 lines · Li Zefan

Quoted 8 lines · Li Zefan

Quoted 7 lines · Balbir Singh
Quoted 6 lines · 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: 

I Added 2 printk()s:

static void __oom_kill_task(struct task_struct *p, int verbose) {

(quoted diff) +3 -0

+       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!

Quoted 8 lines

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.

Oleg Nesterov

2008-04-15 10:19 UTC #6 lore raw

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

Quoted 9 lines · Oleg Nesterov

	+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.

- renamed from linux/sched.h +1 -1

@@ -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 */

- renamed from power/process.c +1 -1

@@ -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));
 }
 
 /**

- renamed from aio.c +0 -6

@@ -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);

- renamed from fork.c +2 -2

@@ -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);

- renamed from kthread.c +1 -1

@@ -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);

- renamed from exec.c +1 -0

@@ -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 */

- renamed from exit.c +1 -1

@@ -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);

Jeff Dike

2008-04-15 17:10 UTC #7 lore raw

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

Quoted 14 lines · Oleg Nesterov

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

Signature · 7 lines

Work email - jdike at linux dot intel dot com

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

Roland McGrath

2008-04-15 20:58 UTC #8 lore raw

In reply to Oleg Nesterov

Quoted 2 lines

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