Skip to contentSkip to conversation

pppd service crash in linux-3.13.6

PATCH New Sree Harsha Totakura 4 participants 16 messages Mar 7, 2014 – Mar 17, 2014

Subsystems (3)
Networking Network drivers PPP protocol drivers and compressors
lore
Share & tools
lore

Sree Harsha Totakura

author
#0 lore raw

Hi,

Using linux-3.13.6, I observed the following output from the pppd kernel thread. This happened when I tried to suspend my computer and it *stops* the computer from suspending. Before going to suspend, I had used ppp to connect via my bluetooth modem and I later found that the connection was broken abruptly with a similar trace output.

Trace:

[22735.115313] PM: Syncing filesystems ... done.
[22735.665613] PM: Preparing system for mem sleep
[22735.665829] Freezing user space processes ...
[22755.659538] Freezing of tasks failed after 20.004 seconds (1 tasks
refusing to freeze, wq_
busy=0):
[22755.659555] pppd            D ffff8800376c9a58     0 16801      1
0x00000006
[22755.659557]  ffff8800376c9750 0000000000000046 0000000000012e80
0000000000012e80
[22755.659560]  ffff8802a1c1dfd8 ffff8800376c9750 0000000000000009
ffff8802a1c1dd78
[22755.659562]  0000000000000046 ffff8800376c9750 0000000000000028
ffff8800376c9750
[22755.659564] Call Trace:
[22755.659569]  [<ffffffff81048507>] ? do_exit+0x937/0xa50
[22755.659573]  [<ffffffff814bb6e1>] ? oops_end+0x91/0xd0
[22755.659575]  [<ffffffff814b1f4f>] ? no_context+0x1f3/0x1ff
[22755.659577]  [<ffffffff814bdb69>] ? __do_page_fault+0x89/0x500
[22755.659581]  [<ffffffff811017dc>] ? free_pcppages_bulk+0x17c/0x3b0
[22755.659584]  [<ffffffff81101cce>] ? free_hot_cold_page_list+0x3e/0x90
[22755.659586]  [<ffffffff814babf8>] ? page_fault+0x28/0x30
[22755.659591]  [<ffffffffa06fd5a3>] ? ppp_register_channel+0x13/0x20
[ppp_generic]
[22755.659594]  [<ffffffffa07062ab>] ? ppp_asynctty_open+0x12b/0x170
[ppp_async]
[22755.659596]  [<ffffffff812ec907>] ? tty_ldisc_open.isra.2+0x27/0x60
[22755.659598]  [<ffffffff812ed1d3>] ? tty_ldisc_hangup+0x1e3/0x220
[22755.659601]  [<ffffffff812e4614>] ? __tty_hangup+0x2c4/0x440
[22755.659603]  [<ffffffff812e56a1>] ? disassociate_ctty+0x61/0x270
[22755.659605]  [<ffffffff810483c2>] ? do_exit+0x7f2/0xa50
[22755.659607]  [<ffffffff81053ad2>] ? recalc_sigpending+0x12/0x50
[22755.659609]  [<ffffffff81054308>] ? __set_task_blocked+0x28/0x70
[22755.659611]  [<ffffffff81048684>] ? do_group_exit+0x34/0xa0
[22755.659613]  [<ffffffff810486fb>] ? SyS_exit_group+0xb/0x10
[22755.659615]  [<ffffffff814c1eb9>] ? system_call_fastpath+0x16/0x1b
[22755.659618]
[22755.659619] Restarting tasks ... done.

Regards,
Sree

author
#1 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Using linux-3.13.6, I am observing the following output from the pppd kernel thread. This happens when I try to suspend my computer and it *stops* the computer from suspending.

I am using ppp via a bluetooth modem.

Trace:

[22735.115313] PM: Syncing filesystems ... done.
[22735.665613] PM: Preparing system for mem sleep
[22735.665829] Freezing user space processes ...
[22755.659538] Freezing of tasks failed after 20.004 seconds (1 tasks
refusing to freeze, wq_
busy=0):
[22755.659555] pppd            D ffff8800376c9a58     0 16801      1
0x00000006
[22755.659557]  ffff8800376c9750 0000000000000046 0000000000012e80
0000000000012e80
[22755.659560]  ffff8802a1c1dfd8 ffff8800376c9750 0000000000000009
ffff8802a1c1dd78
[22755.659562]  0000000000000046 ffff8800376c9750 0000000000000028
ffff8800376c9750
[22755.659564] Call Trace:
[22755.659569]  [<ffffffff81048507>] ? do_exit+0x937/0xa50
[22755.659573]  [<ffffffff814bb6e1>] ? oops_end+0x91/0xd0
[22755.659575]  [<ffffffff814b1f4f>] ? no_context+0x1f3/0x1ff
[22755.659577]  [<ffffffff814bdb69>] ? __do_page_fault+0x89/0x500
[22755.659581]  [<ffffffff811017dc>] ? free_pcppages_bulk+0x17c/0x3b0
[22755.659584]  [<ffffffff81101cce>] ? free_hot_cold_page_list+0x3e/0x90
[22755.659586]  [<ffffffff814babf8>] ? page_fault+0x28/0x30
[22755.659591]  [<ffffffffa06fd5a3>] ? ppp_register_channel+0x13/0x20
[ppp_generic]
[22755.659594]  [<ffffffffa07062ab>] ? ppp_asynctty_open+0x12b/0x170
[ppp_async]
[22755.659596]  [<ffffffff812ec907>] ? tty_ldisc_open.isra.2+0x27/0x60
[22755.659598]  [<ffffffff812ed1d3>] ? tty_ldisc_hangup+0x1e3/0x220
[22755.659601]  [<ffffffff812e4614>] ? __tty_hangup+0x2c4/0x440
[22755.659603]  [<ffffffff812e56a1>] ? disassociate_ctty+0x61/0x270
[22755.659605]  [<ffffffff810483c2>] ? do_exit+0x7f2/0xa50
[22755.659607]  [<ffffffff81053ad2>] ? recalc_sigpending+0x12/0x50
[22755.659609]  [<ffffffff81054308>] ? __set_task_blocked+0x28/0x70
[22755.659611]  [<ffffffff81048684>] ? do_group_exit+0x34/0xa0
[22755.659613]  [<ffffffff810486fb>] ? SyS_exit_group+0xb/0x10
[22755.659615]  [<ffffffff814c1eb9>] ? system_call_fastpath+0x16/0x1b
[22755.659618]
[22755.659619] Restarting tasks ... done.

If you need any more info, I am happy to provide.

Regards,
Sree

#2 lore raw

[ +cc Oleg Nesterov ]

Quoted 51 lines · Sree Harsha Totakura

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Using linux-3.13.6, I am observing the following output from the pppd kernel thread. This happens when I try to suspend my computer and it *stops* the computer from suspending.

I am using ppp via a bluetooth modem.

Trace:

[22735.115313] PM: Syncing filesystems ... done.
[22735.665613] PM: Preparing system for mem sleep
[22735.665829] Freezing user space processes ...
[22755.659538] Freezing of tasks failed after 20.004 seconds (1 tasks
refusing to freeze, wq_
busy=0):
[22755.659555] pppd            D ffff8800376c9a58     0 16801      1
0x00000006
[22755.659557]  ffff8800376c9750 0000000000000046 0000000000012e80
0000000000012e80
[22755.659560]  ffff8802a1c1dfd8 ffff8800376c9750 0000000000000009
ffff8802a1c1dd78
[22755.659562]  0000000000000046 ffff8800376c9750 0000000000000028
ffff8800376c9750
[22755.659564] Call Trace:
[22755.659569]  [<ffffffff81048507>] ? do_exit+0x937/0xa50
[22755.659573]  [<ffffffff814bb6e1>] ? oops_end+0x91/0xd0
[22755.659575]  [<ffffffff814b1f4f>] ? no_context+0x1f3/0x1ff
[22755.659577]  [<ffffffff814bdb69>] ? __do_page_fault+0x89/0x500
[22755.659581]  [<ffffffff811017dc>] ? free_pcppages_bulk+0x17c/0x3b0
[22755.659584]  [<ffffffff81101cce>] ? free_hot_cold_page_list+0x3e/0x90
[22755.659586]  [<ffffffff814babf8>] ? page_fault+0x28/0x30
[22755.659591]  [<ffffffffa06fd5a3>] ? ppp_register_channel+0x13/0x20
[ppp_generic]
[22755.659594]  [<ffffffffa07062ab>] ? ppp_asynctty_open+0x12b/0x170
[ppp_async]
[22755.659596]  [<ffffffff812ec907>] ? tty_ldisc_open.isra.2+0x27/0x60
[22755.659598]  [<ffffffff812ed1d3>] ? tty_ldisc_hangup+0x1e3/0x220
[22755.659601]  [<ffffffff812e4614>] ? __tty_hangup+0x2c4/0x440
[22755.659603]  [<ffffffff812e56a1>] ? disassociate_ctty+0x61/0x270
[22755.659605]  [<ffffffff810483c2>] ? do_exit+0x7f2/0xa50
[22755.659607]  [<ffffffff81053ad2>] ? recalc_sigpending+0x12/0x50
[22755.659609]  [<ffffffff81054308>] ? __set_task_blocked+0x28/0x70
[22755.659611]  [<ffffffff81048684>] ? do_group_exit+0x34/0xa0
[22755.659613]  [<ffffffff810486fb>] ? SyS_exit_group+0xb/0x10
[22755.659615]  [<ffffffff814c1eb9>] ? system_call_fastpath+0x16/0x1b
[22755.659618]
[22755.659619] Restarting tasks ... done.
Quoted 1 line

If you need any more info, I am happy to provide.

The NULL ptr dereference is from following the current->nsproxy ptr in ppp_register_channel().

This was broken by

commit 8aac62706adaaf0fab02c4327761561c8bda9448

Author: Oleg Nesterov <[email protected]>
Date:   Fri Jun 14 21:09:49 2013 +0200

move exit_task_namespaces() outside of exit_notify()

which moved the exit_task_namespaces(tsk) before disassociate_ctty().

Regards,
Peter Hurley

#3 lore raw
Quoted 2 lines · Peter Hurley

[ +cc Oleg Nesterov ]

Thanks.

Quoted 5 lines

The NULL ptr dereference is from following the current->nsproxy ptr in ppp_register_channel().

This was broken by

Quoted 7 lines

commit 8aac62706adaaf0fab02c4327761561c8bda9448

Author: Oleg Nesterov <[email protected]>
Date:   Fri Jun 14 21:09:49 2013 +0200

move exit_task_namespaces() outside of exit_notify()

which moved the exit_task_namespaces(tsk) before disassociate_ctty().

Heh. OK, we can move it down after disassociate_ctty(), the original motivation for that commit was the problem which was also (hopefully) fixed by e7b2c406925273 "fput: task_work_add() can fail if the caller has passed exit_task_work()".

In fact I think that it makes sense to move it down after exit_task_work() anyway. But this is almost off-topic and I'd like to avoid this right now.

OTOH, why we should delay disassociate_ctty? IOW, do you see any potential problem with the trivial patch below?

And it seems that it makes sense to move (at least) check_stack_usage() down, but this is offtopic too.

Oleg.

exit.c/ renamed from kernel/exit.c +2 -4
@@ -784,6 +784,8 @@ void do_exit(long code)
 	exit_shm(tsk);
 	exit_files(tsk);
 	exit_fs(tsk);
+	if (group_dead)
+		disassociate_ctty(1);
 	exit_task_namespaces(tsk);
 	exit_task_work(tsk);
 	check_stack_usage();

@@ -799,13 +801,9 @@ void do_exit(long code)
 
 	cgroup_exit(tsk, 1);
 
-	if (group_dead)
-		disassociate_ctty(1);
-
 	module_put(task_thread_info(tsk)->exec_domain->module);
 
 	proc_exit_connector(tsk);
-
 	/*
 	 * FIXME: do that only when needed, using sched_exit tracepoint
 	 */
#4 lore raw

Hi Oleg,

Quoted 15 lines · Oleg Nesterov
Quoted 2 lines · Peter Hurley

[ +cc Oleg Nesterov ]

Thanks.

Quoted 9 lines

The NULL ptr dereference is from following the current->nsproxy ptr in ppp_register_channel().

This was broken by

commit 8aac62706adaaf0fab02c4327761561c8bda9448

Author: Oleg Nesterov <[email protected]>
Date:   Fri Jun 14 21:09:49 2013 +0200
Quoted 8 lines
Quoted 3 lines

move exit_task_namespaces() outside of exit_notify()

which moved the exit_task_namespaces(tsk) before disassociate_ctty().

Heh. OK, we can move it down after disassociate_ctty(), the original motivation for that commit was the problem which was also (hopefully) fixed by e7b2c406925273 "fput: task_work_add() can fail if the caller has passed exit_task_work()".

I didn't look into what motivated the change; I will now though.

Quoted 6 lines

In fact I think that it makes sense to move it down after exit_task_work() anyway. But this is almost off-topic and I'd like to avoid this right now.

OTOH, why we should delay disassociate_ctty? IOW, do you see any potential problem with the trivial patch below?

I have no idea what kind of dependencies might exist between task works, cgroup_exit() and all the teardown that disassociate_ctty() does. I'll look into though.

Quoted 2 lines

And it seems that it makes sense to move (at least) check_stack_usage() down, but this is offtopic too.

I agree that it makes sense to check the stack _after_ teardown code runs, but all the arch-dependent exit_thread() code would need to be audited first.

Quoted 17 lines

Oleg.

exit.c/ renamed from kernel/exit.c +2 -0
@@ -784,6 +784,8 @@ void do_exit(long code)
  	exit_shm(tsk);
  	exit_files(tsk);
  	exit_fs(tsk);
+	if (group_dead)
+		disassociate_ctty(1);
  	exit_task_namespaces(tsk);
  	exit_task_work(tsk);
  	check_stack_usage();

@@ -799,13 +801,9 @@ void do_exit(long code)
 
  	cgroup_exit(tsk, 1);

exit.c/ void do_exit(long code) · line 809

Quoted 10 lines
exit.c/ renamed from kernel/exit.c +0 -4
-	if (group_dead)
-		disassociate_ctty(1);
-
  	module_put(task_thread_info(tsk)->exec_domain->module);
 
  	proc_exit_connector(tsk);
-
  	/*
  	 * FIXME: do that only when needed, using sched_exit tracepoint
  	 */

Regards,
Peter Hurley

#5 lore raw

[ +cc Eric Biederman ]

Quoted 26 lines · Peter Hurley

Hi Oleg,

Quoted 23 lines · Oleg Nesterov
Quoted 2 lines · Peter Hurley

[ +cc Oleg Nesterov ]

Thanks.

Quoted 5 lines

The NULL ptr dereference is from following the current->nsproxy ptr in ppp_register_channel().

This was broken by

Quoted 7 lines

commit 8aac62706adaaf0fab02c4327761561c8bda9448

Author: Oleg Nesterov <[email protected]>
Date:   Fri Jun 14 21:09:49 2013 +0200

move exit_task_namespaces() outside of exit_notify()

which moved the exit_task_namespaces(tsk) before disassociate_ctty().

Heh. OK, we can move it down after disassociate_ctty(), the original motivation for that commit was the problem which was also (hopefully) fixed by e7b2c406925273 "fput: task_work_add() can fail if the caller has passed exit_task_work()".

Thanks for fixing that!
tty teardown (hangup from disassociate_ctty) requires fput() to work :)

Quoted 8 lines

I didn't look into what motivated the change; I will now though.

Quoted 6 lines

In fact I think that it makes sense to move it down after exit_task_work() anyway. But this is almost off-topic and I'd like to avoid this right now.

OTOH, why we should delay disassociate_ctty? IOW, do you see any potential problem with the trivial patch below?

Won't work.

Quoted 3 lines

I have no idea what kind of dependencies might exist between task works, cgroup_exit() and all the teardown that disassociate_ctty() does. I'll look into though.

cgroup_exit() can exec a userspace process (the notify_on_exit() facility) which requires both namespace and tty facilities.
Plus, proc_exit_connector() uses netlink which uses user_ns.

I think it's better to have task namespaces valid up to exit_notify().

Regards,
Peter Hurley

#6 lore raw
Quoted 1 line · Peter Hurley

Plus, proc_exit_connector() uses netlink which uses user_ns.

Actually, I think this can be safely ignored since if the netlink socket was tied to a user_ns which has just been freed in exit_task_namespace() then the socket could not be open in another process (otherwise the net_ns would still have an open reference).

#7 lore raw
In reply to Peter Hurley
Quoted 9 lines · Peter Hurley
Quoted 5 lines · Oleg Nesterov
Quoted 3 lines

OTOH, why we should delay disassociate_ctty? IOW, do you see any potential problem with the trivial patch below?

Won't work.

cgroup_exit() can exec a userspace process (the notify_on_exit() facility)

                                                  ^^^^^^^^^^^^^^^^

can't find anything named notify_on_exit, perhap you meant cgroup_release_agent? Although I guess this should not matter.

Quoted 1 line

which requires both namespace and tty facilities.

Hmm... why?

The exiting task obviously can't exec. The only way to spawn a userspace process is call_usermodehelper(), it should work just fine, no?

Oleg.

#8 lore raw
Quoted 7 lines · Oleg Nesterov
Quoted 6 lines · Peter Hurley
Quoted 5 lines · Oleg Nesterov
Quoted 3 lines

OTOH, why we should delay disassociate_ctty? IOW, do you see any potential problem with the trivial patch below?

Quoted 7 lines
Quoted 3 lines

Won't work.

cgroup_exit() can exec a userspace process (the notify_on_exit() facility)

                                                   ^^^^^^^^^^^^^^^^

can't find anything named notify_on_exit, perhap you meant cgroup_release_agent? Although I guess this should not matter.

Sorry, I meant the notify_on_release() facility as discussed in the function header comments of cgroup_exit().

Yes, cgroup_release_agent() is the work function that is scheduled.

Quoted 6 lines
Quoted 1 line

which requires both namespace and tty facilities.

Hmm... why?

The exiting task obviously can't exec. The only way to spawn a userspace process is call_usermodehelper(), it should work just fine, no?

You're correct, in the immediate sense that the user command exec'd will not inherit open file descriptors.

But what if it expects to be able to find the intact children of the foreground process group, and can't because the controlling tty has already been torn down and all the children already sent SIGHUP.

I know that's not what the user command is intended for, but userspace can be enterprising for establishing dependencies on kernel constructs.

Or what if the user command expects to find and join the user namespace of the dying process but now it's already been freed?

Regards,
Peter Hurley

#9 lore raw
Quoted 13 lines · Peter Hurley
Quoted 2 lines · Oleg Nesterov
Quoted 1 line · Peter Hurley

Yes, cgroup_release_agent() is the work function that is scheduled.

Quoted 6 lines
Quoted 1 line

which requires both namespace and tty facilities.

Hmm... why?

The exiting task obviously can't exec. The only way to spawn a userspace process is call_usermodehelper(), it should work just fine, no?

Quoted 6 lines

You're correct, in the immediate sense that the user command exec'd will not inherit open file descriptors.

But what if it expects to be able to find the intact children of the foreground process group, and can't because the controlling tty has already been torn down and all the children already sent SIGHUP.

Which group/tty ? call_usermodehelper() asks the workqueue thread to kthread_create/exec. See also below...

Quoted 2 lines

Or what if the user command expects to find and join the user namespace of the dying process but now it's already been freed?

But it can't even know who called call_usermodehelper(). Besides, cgroup_release_agent() uses UMH_WAIT_EXEC, so the caller can continue and disappear completely before the usermode process has any chance to do something.

Oleg.

#10 lore raw
Quoted 23 lines · Oleg Nesterov
Quoted 12 lines · Peter Hurley
Quoted 2 lines · Oleg Nesterov
Quoted 1 line · Peter Hurley

Yes, cgroup_release_agent() is the work function that is scheduled.

Quoted 6 lines
Quoted 1 line

which requires both namespace and tty facilities.

Hmm... why?

The exiting task obviously can't exec. The only way to spawn a userspace process is call_usermodehelper(), it should work just fine, no?

Quoted 6 lines

You're correct, in the immediate sense that the user command exec'd will not inherit open file descriptors.

But what if it expects to be able to find the intact children of the foreground process group, and can't because the controlling tty has already been torn down and all the children already sent SIGHUP.

Which group/tty ? call_usermodehelper() asks the workqueue thread to kthread_create/exec. See also below...

Quoted 7 lines
Quoted 2 lines

Or what if the user command expects to find and join the user namespace of the dying process but now it's already been freed?

But it can't even know who called call_usermodehelper(). Besides, cgroup_release_agent() uses UMH_WAIT_EXEC, so the caller can continue and disappear completely before the usermode process has any chance to do something.

I'm just hypothesizing potential breakage, since the order of teardown is sensitive to changes, and I didn't do a complete audit of all the possibilities.

If you feel strongly about moving disassociate_tty(), I won't object.

Regards,
Peter Hurley

#11 lore raw

cover (Was: pppd service crash in linux-3.13.6)

Quoted 11 lines · Peter Hurley
Quoted 5 lines · Oleg Nesterov

But it can't even know who called call_usermodehelper(). Besides, cgroup_release_agent() uses UMH_WAIT_EXEC, so the caller can continue and disappear completely before the usermode process has any chance to do something.

I'm just hypothesizing potential breakage, since the order of teardown is sensitive to changes, and I didn't do a complete audit of all the possibilities.

Yes, I understand your concerns. Still I do not see how cgroup_exit() can depend on tty/namespace.

Quoted 1 line

If you feel strongly about moving disassociate_tty(), I won't object.

It is not that I feel really strongly... just in looks better to me. If nothing else:

1. If we actually can not do disassociate_ctty() before, say, cgroup_exit(), then we should understand and document the reason.

2. task_work_add() can have more users in drivers/tty which can be triggered by disassociate_tty() paths. So I think it would be nice to call it before task_work_exit().

2/2 is offtopic and hopefully trivial.

Oleg.

#12 lore raw

PATCH 1/2 exit: call disassociate_ctty() before exit_task_namespaces()

8aac62706ada "move exit_task_namespaces() outside of exit_notify()" breaks pppd and the exiting service crashes the kernel:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
    IP: [<ffffffffa06985a3>] ppp_register_channel+0x13/0x20 [ppp_generic]
    ...
    Call Trace:
     [<ffffffffa06ab2ab>] ? ppp_asynctty_open+0x12b/0x170 [ppp_async]
     [<ffffffff812ec907>] ? tty_ldisc_open.isra.2+0x27/0x60
     [<ffffffff812ed1d3>] ? tty_ldisc_hangup+0x1e3/0x220
     [<ffffffff812e4614>] ? __tty_hangup+0x2c4/0x440
     [<ffffffff812e56a1>] ? disassociate_ctty+0x61/0x270
     [<ffffffff810483c2>] ? do_exit+0x7f2/0xa50

ppp_register_channel() needs ->net_ns and current->nsproxy == NULL.

Move disassociate_ctty() before exit_task_namespaces(), it doesn't make sense to delay it after perf_event_exit_task() or cgroup_exit().

This also allows to use task_work_add() inside the (nontrivial) code paths in disassociate_ctty().

Cc [email protected] # v3.10+
Reported-by Sree Harsha Totakura <[email protected]>
Investigated-by Peter Hurley <[email protected]>
Signed-off-by Oleg Nesterov <[email protected]>
---
 kernel/exit.c |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)
kernel/exit.c +2 -4
index 790b73c..5d5b472 100644
@@ -784,6 +784,8 @@ void do_exit(long code)
 	exit_shm(tsk);
 	exit_files(tsk);
 	exit_fs(tsk);
+	if (group_dead)
+		disassociate_ctty(1);
 	exit_task_namespaces(tsk);
 	exit_task_work(tsk);
 	check_stack_usage();

@@ -799,13 +801,9 @@ void do_exit(long code)
 
 	cgroup_exit(tsk, 1);
 
-	if (group_dead)
-		disassociate_ctty(1);
-
 	module_put(task_thread_info(tsk)->exec_domain->module);
 
 	proc_exit_connector(tsk);
-
 	/*
 	 * FIXME: do that only when needed, using sched_exit tracepoint
 	 */
Signature · 1 line
1.5.5.1
#13 lore raw

PATCH 2/2 exit: move check_stack_usage() to the end of do_exit()

In reply to Oleg Nesterov

It is not clear why check_stack_usage() is called so early and thus it never checks the stack usage in, say, exit_notify() or flush_ptrace_hw_breakpoint() or other functions which are only called by do_exit().

Move the callsite down to the last preempt_disable/schedule.

Signed-off-by Oleg Nesterov <[email protected]>
---
 kernel/exit.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
kernel/exit.c +1 -1
index 5d5b472..6d1f245 100644
@@ -788,7 +788,6 @@ void do_exit(long code)
 		disassociate_ctty(1);
 	exit_task_namespaces(tsk);
 	exit_task_work(tsk);
-	check_stack_usage();
 	exit_thread();
 
 	/*

@@ -842,6 +841,7 @@ void do_exit(long code)
 
 	validate_creds_for_do_exit(tsk);
 
+	check_stack_usage();
 	preempt_disable();
 	if (tsk->nr_dirtied)
 		__this_cpu_add(dirty_throttle_leaks, tsk->nr_dirtied);
Signature · 1 line
1.5.5.1
#14 lore raw
In reply to Sree Harsha Totakura
Quoted 21 lines · Sree Harsha Totakura

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Using linux-3.13.6, I am observing the following output from the pppd kernel thread. This happens when I try to suspend my computer and it *stops* the computer from suspending.

I am using ppp via a bluetooth modem.

Trace:

[22735.115313] PM: Syncing filesystems ... done.
[22735.665613] PM: Preparing system for mem sleep
[22735.665829] Freezing user space processes ...
[22755.659538] Freezing of tasks failed after 20.004 seconds (1 tasks
refusing to freeze, wq_
busy=0):
[22755.659555] pppd            D ffff8800376c9a58     0 16801      1
0x00000006
[22755.659557]  ffff8800376c9750 0000000000000046 0000000000012e80
Quoted 8 lines

0000000000012e80

[22755.659560]  ffff8802a1c1dfd8 ffff8800376c9750 0000000000000009
ffff8802a1c1dd78
[22755.659562]  0000000000000046 ffff8800376c9750 0000000000000028
ffff8800376c9750
[22755.659564] Call Trace:
[22755.659569]  [<ffffffff81048507>] ? do_exit+0x937/0xa50
[22755.659573]  [<ffffffff814bb6e1>] ? oops_end+0x91/0xd0

pppd can't be frozen because it crashed earlier in kernel mode.

[...]

Quoted 1 line

If you need any more info, I am happy to provide.

You should send the 'Oops' messages which should be further up the log file.

Ben.

Signature · 2 lines
Ben Hutchings
Computers are not intelligent.	They only think they are.
author
#15 lore raw
Quoted 2 lines · Ben Hutchings

You should send the 'Oops' messages which should be further up the log file.

Attached is a file containing the oops message.

Sree

Mar  8 18:46:32 iris kernel: [29267.060816] PPP BSD Compression module registered
Mar  8 18:46:32 iris kernel: [29267.062116] PPP Deflate Compression module registered
Mar  8 18:49:02 iris kernel: [29416.842802] Bluetooth: TIOCGSERIAL is not supported
Mar  8 18:49:03 iris kernel: [29417.671332] Bluetooth: TIOCGSERIAL is not supported
Mar  8 19:11:12 iris kernel: [30745.894294] Bluetooth: TIOCGSERIAL is not supported
Mar  8 19:11:55 iris kernel: [30788.761855] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
Mar  8 19:11:55 iris kernel: [30788.761914] IP: [<ffffffffa06985a3>] ppp_register_channel+0x13/0x20 [ppp_generic]
Mar  8 19:11:55 iris kernel: [30788.761963] PGD 0 
Mar  8 19:11:55 iris kernel: [30788.761976] Oops: 0000 [#1] SMP 
Mar  8 19:11:55 iris kernel: [30788.761990] Modules linked in: ppp_deflate bsd_comp nls_iso8859_1 nls_cp437 vfat fat snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_seq_midi_event snd_rawmidi hid_generic hid_logitech_dj ppp_async crc_ccitt ppp_generic slhc ctr ccm rfcomm bnep vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) binfmt_misc uinput ext2 snd_hda_codec_hdmi uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core joydev videodev iTCO_wdt iTCO_vendor_support media btusb bluetooth x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek i915 snd_hda_intel snd_hda_codec snd_hwdep pcspkr snd_pcm psmouse intel_rapl arc4 i2c_algo_bit drm_kms_helper snd_page_alloc serio_raw coretemp kvm_intel kvm iwlmvm mac80211 drm snd_seq thinkpad_acpi tpm_tis iwlwifi wmi tpm snd_timer evdev rtsx_pci_ms nvram i2c_i801 cfg80211 battery video ac snd_seq_device button mei_me i2c_core lpc_ich processor memstick snd mei soundcore rfkill fuse autofs4 ext4 crc16 jbd2 mbcache dm_crypt dm_mod rtsx_pci_sdmmc mmc_core crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd thermal thermal_sys ahci libahci e1000e libata ptp pps_core rtsx_pci mfd_core
Mar  8 19:11:55 iris kernel: [30788.762418] CPU: 2 PID: 25679 Comm: pppd Tainted: G        W  O 3.13.6+ #7
Mar  8 19:11:55 iris kernel: [30788.762438] Hardware name: LENOVO 20AQS00600/20AQS00600, BIOS GJET71WW (2.21 ) 02/10/2014
Mar  8 19:11:55 iris kernel: [30788.762462] task: ffff88030993e050 ti: ffff88030a5ee000 task.ti: ffff88030a5ee000
Mar  8 19:11:55 iris kernel: [30788.762484] RIP: 0010:[<ffffffffa06985a3>]  [<ffffffffa06985a3>] ppp_register_channel+0x13/0x20 [ppp_generic]
Mar  8 19:11:55 iris kernel: [30788.762515] RSP: 0018:ffff88030a5efe20  EFLAGS: 00010216
Mar  8 19:11:55 iris kernel: [30788.762530] RAX: 0000000000000000 RBX: ffff8800852e4000 RCX: 0000000000000000
Mar  8 19:11:55 iris kernel: [30788.762551] RDX: 0000000000000011 RSI: ffff8800852e40f0 RDI: ffff8800852e40f0
Mar  8 19:11:55 iris kernel: [30788.762571] RBP: ffff88030e954000 R08: 0000000000000001 R09: ffff8800852e4000
Mar  8 19:11:55 iris kernel: [30788.762591] R10: ffff88030993e6c0 R11: ffff88031f5fad80 R12: 0000000000000000
Mar  8 19:11:55 iris kernel: [30788.762612] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88030e954004
Mar  8 19:11:55 iris kernel: [30788.762632] FS:  0000000000000000(0000) GS:ffff88031f280000(0000) knlGS:0000000000000000
Mar  8 19:11:55 iris kernel: [30788.762655] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Mar  8 19:11:55 iris kernel: [30788.762672] CR2: 0000000000000028 CR3: 000000000180c000 CR4: 00000000001407e0
Mar  8 19:11:55 iris kernel: [30788.762693] Stack:
Mar  8 19:11:55 iris kernel: [30788.762700]  ffffffffa06ab2ab ffff88030e954000 0000000000000000 0000000000000000
Mar  8 19:11:55 iris kernel: [30788.762725]  ffffffff812ec907 ffff88030e954000 ffff88030923b940 ffffffff812ed1d3
Mar  8 19:11:55 iris kernel: [30788.762750]  ffff88030e954120 0000000000000000 ffff88030e954000 ffffffff812e4614
Mar  8 19:11:55 iris kernel: [30788.762774] Call Trace:
Mar  8 19:11:55 iris kernel: [30788.762785]  [<ffffffffa06ab2ab>] ? ppp_asynctty_open+0x12b/0x170 [ppp_async]
Mar  8 19:11:55 iris kernel: [30788.762807]  [<ffffffff812ec907>] ? tty_ldisc_open.isra.2+0x27/0x60
Mar  8 19:11:55 iris kernel: [30788.762826]  [<ffffffff812ed1d3>] ? tty_ldisc_hangup+0x1e3/0x220
Mar  8 19:11:55 iris kernel: [30788.762845]  [<ffffffff812e4614>] ? __tty_hangup+0x2c4/0x440
Mar  8 19:11:55 iris kernel: [30788.762863]  [<ffffffff812e56a1>] ? disassociate_ctty+0x61/0x270
Mar  8 19:11:55 iris kernel: [30788.762882]  [<ffffffff810483c2>] ? do_exit+0x7f2/0xa50
Mar  8 19:11:55 iris kernel: [30788.762898]  [<ffffffff81053ad2>] ? recalc_sigpending+0x12/0x50
Mar  8 19:11:55 iris kernel: [30788.762916]  [<ffffffff81054308>] ? __set_task_blocked+0x28/0x70
Mar  8 19:11:55 iris kernel: [30788.762934]  [<ffffffff81048684>] ? do_group_exit+0x34/0xa0
Mar  8 19:11:55 iris kernel: [30788.762951]  [<ffffffff810486fb>] ? SyS_exit_group+0xb/0x10
Mar  8 19:11:55 iris kernel: [30788.762969]  [<ffffffff814c1eb9>] ? system_call_fastpath+0x16/0x1b
Mar  8 19:11:55 iris kernel: [30788.762987] Code: 0b e8 ab 2d 00 00 e8 a8 2d 00 00 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 65 48 8b 04 25 80 b8 00 00 48 8b 80 90 04 00 00 48 89 fe <48> 8b 78 28 e9 64 fe ff ff 0f 1f 40 00 41 56 41 55 41 54 55 53 
Mar  8 19:11:55 iris kernel: [30788.763096] RIP  [<ffffffffa06985a3>] ppp_register_channel+0x13/0x20 [ppp_generic]
Mar  8 19:11:55 iris kernel: [30788.763120]  RSP <ffff88030a5efe20>
Mar  8 19:11:55 iris kernel: [30788.763130] CR2: 0000000000000028
Mar  8 19:11:55 iris kernel: [30788.770627] ---[ end trace 0eface82ef71428a ]---
Mar  8 19:11:55 iris kernel: [30788.770629] Fixing recursive fault but reboot is needed!
Mar  8 19:14:56 iris kernel: [30949.341168] PM: Syncing filesystems ... done.
Mar  8 19:14:56 iris kernel: [30950.107772] PM: Preparing system for mem sleep
Mar  8 19:14:56 iris kernel: [30950.107963] Freezing user space processes ... 
Mar  8 19:14:56 iris kernel: [30970.106401] Freezing of tasks failed after 20.009 seconds (1 tasks refusing to freeze, wq_busy=0):
Mar  8 19:14:56 iris kernel: [30970.106419] pppd            D ffff88030993e358     0 25679      1 0x00000006
Mar  8 19:14:56 iris kernel: [30970.106421]  ffff88030993e050 0000000000000046 0000000000012e80 0000000000012e80
Mar  8 19:14:56 iris kernel: [30970.106424]  ffff88030a5effd8 ffff88030993e050 0000000000000009 ffff88030a5efd78
Mar  8 19:14:56 iris kernel: [30970.106425]  0000000000000046 ffff88030993e050 0000000000000028 ffff88030993e050
Mar  8 19:14:56 iris kernel: [30970.106428] Call Trace:
Mar  8 19:14:56 iris kernel: [30970.106433]  [<ffffffff81048507>] ? do_exit+0x937/0xa50
Mar  8 19:14:56 iris kernel: [30970.106437]  [<ffffffff814bb6e1>] ? oops_end+0x91/0xd0
Mar  8 19:14:56 iris kernel: [30970.106439]  [<ffffffff814b1f4f>] ? no_context+0x1f3/0x1ff
Mar  8 19:14:56 iris kernel: [30970.106441]  [<ffffffff814bdb69>] ? __do_page_fault+0x89/0x500
Mar  8 19:14:56 iris kernel: [30970.106445]  [<ffffffff811017dc>] ? free_pcppages_bulk+0x17c/0x3b0
Mar  8 19:14:56 iris kernel: [30970.106448]  [<ffffffff81101cce>] ? free_hot_cold_page_list+0x3e/0x90
Mar  8 19:14:56 iris kernel: [30970.106450]  [<ffffffff814babf8>] ? page_fault+0x28/0x30
Mar  8 19:14:56 iris kernel: [30970.106455]  [<ffffffffa06985a3>] ? ppp_register_channel+0x13/0x20 [ppp_generic]
Mar  8 19:14:56 iris kernel: [30970.106458]  [<ffffffffa06ab2ab>] ? ppp_asynctty_open+0x12b/0x170 [ppp_async]
Mar  8 19:14:56 iris kernel: [30970.106460]  [<ffffffff812ec907>] ? tty_ldisc_open.isra.2+0x27/0x60
Mar  8 19:14:56 iris kernel: [30970.106462]  [<ffffffff812ed1d3>] ? tty_ldisc_hangup+0x1e3/0x220
Mar  8 19:14:56 iris kernel: [30970.106465]  [<ffffffff812e4614>] ? __tty_hangup+0x2c4/0x440
Mar  8 19:14:56 iris kernel: [30970.106467]  [<ffffffff812e56a1>] ? disassociate_ctty+0x61/0x270
Mar  8 19:14:56 iris kernel: [30970.106469]  [<ffffffff810483c2>] ? do_exit+0x7f2/0xa50
Mar  8 19:14:56 iris kernel: [30970.106472]  [<ffffffff81053ad2>] ? recalc_sigpending+0x12/0x50
Mar  8 19:14:56 iris kernel: [30970.106474]  [<ffffffff81054308>] ? __set_task_blocked+0x28/0x70
Mar  8 19:14:56 iris kernel: [30970.106475]  [<ffffffff81048684>] ? do_group_exit+0x34/0xa0
Mar  8 19:14:56 iris kernel: [30970.106477]  [<ffffffff810486fb>] ? SyS_exit_group+0xb/0x10
Mar  8 19:14:56 iris kernel: [30970.106479]  [<ffffffff814c1eb9>] ? system_call_fastpath+0x16/0x1b
Mar  8 19:14:56 iris kernel: [30970.106481] 
Mar  8 19:14:56 iris kernel: [30970.106482] Restarting tasks ... done.
Mar  8 19:14:56 iris kernel: [30970.113926] video LNXVIDEO:00: Restoring backlight state
Mar  8 19:15:17 iris kernel: [30970.113989] PM: Syncing filesystems ... done.
Mar  8 19:15:17 iris kernel: [30970.653991] PM: Preparing system for freeze sleep
Mar  8 19:15:17 iris kernel: [30970.654125] Freezing user space processes ... 
Mar  8 19:15:17 iris kernel: [30990.648617] Freezing of tasks failed after 20.005 seconds (1 tasks refusing to freeze, wq_busy=0):
Mar  8 19:15:17 iris kernel: [30990.648634] pppd            D ffff88030993e358     0 25679      1 0x00000006
Mar  8 19:15:17 iris kernel: [30990.648637]  ffff88030993e050 0000000000000046 0000000000012e80 0000000000012e80
Mar  8 19:15:17 iris kernel: [30990.648639]  ffff88030a5effd8 ffff88030993e050 0000000000000009 ffff88030a5efd78
Mar  8 19:15:17 iris kernel: [30990.648641]  0000000000000046 ffff88030993e050 0000000000000028 ffff88030993e050
Mar  8 19:15:17 iris kernel: [30990.648643] Call Trace:
Mar  8 19:15:17 iris kernel: [30990.648649]  [<ffffffff81048507>] ? do_exit+0x937/0xa50
Mar  8 19:15:17 iris kernel: [30990.648653]  [<ffffffff814bb6e1>] ? oops_end+0x91/0xd0
Mar  8 19:15:17 iris kernel: [30990.648655]  [<ffffffff814b1f4f>] ? no_context+0x1f3/0x1ff
Mar  8 19:15:17 iris kernel: [30990.648657]  [<ffffffff814bdb69>] ? __do_page_fault+0x89/0x500
Mar  8 19:15:17 iris kernel: [30990.648661]  [<ffffffff811017dc>] ? free_pcppages_bulk+0x17c/0x3b0
Mar  8 19:15:17 iris kernel: [30990.648663]  [<ffffffff81101cce>] ? free_hot_cold_page_list+0x3e/0x90
Mar  8 19:15:17 iris kernel: [30990.648665]  [<ffffffff814babf8>] ? page_fault+0x28/0x30
Mar  8 19:15:17 iris kernel: [30990.648671]  [<ffffffffa06985a3>] ? ppp_register_channel+0x13/0x20 [ppp_generic]
Mar  8 19:15:17 iris kernel: [30990.648673]  [<ffffffffa06ab2ab>] ? ppp_asynctty_open+0x12b/0x170 [ppp_async]
Mar  8 19:15:17 iris kernel: [30990.648676]  [<ffffffff812ec907>] ? tty_ldisc_open.isra.2+0x27/0x60
Mar  8 19:15:17 iris kernel: [30990.648677]  [<ffffffff812ed1d3>] ? tty_ldisc_hangup+0x1e3/0x220
Mar  8 19:15:17 iris kernel: [30990.648680]  [<ffffffff812e4614>] ? __tty_hangup+0x2c4/0x440
Mar  8 19:15:17 iris kernel: [30990.648683]  [<ffffffff812e56a1>] ? disassociate_ctty+0x61/0x270
Mar  8 19:15:17 iris kernel: [30990.648684]  [<ffffffff810483c2>] ? do_exit+0x7f2/0xa50
Mar  8 19:15:17 iris kernel: [30990.648687]  [<ffffffff81053ad2>] ? recalc_sigpending+0x12/0x50
Mar  8 19:15:17 iris kernel: [30990.648689]  [<ffffffff81054308>] ? __set_task_blocked+0x28/0x70
Mar  8 19:15:17 iris kernel: [30990.648691]  [<ffffffff81048684>] ? do_group_exit+0x34/0xa0
Mar  8 19:15:17 iris kernel: [30990.648692]  [<ffffffff810486fb>] ? SyS_exit_group+0xb/0x10
Mar  8 19:15:17 iris kernel: [30990.648695]  [<ffffffff814c1eb9>] ? system_call_fastpath+0x16/0x1b
Mar  8 19:15:17 iris kernel: [30990.648697] 
Mar  8 19:15:17 iris kernel: [30990.648697] Restarting tasks ... done.
Mar  8 19:15:17 iris kernel: [30990.653859] video LNXVIDEO:00: Restoring backlight state
Mar  8 20:43:52 iris kernel: [36301.729323] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Mar  8 20:43:52 iris kernel: [36301.729337] pci 0000:00:00.0: no hotplug settings from platform