pppd service crash in linux-3.13.6

pppd service crash in linux-3.13.6

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

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

Regards,
Sree

Re: pppd service crash in linux-3.13.6

[Peter Hurley]

[ +cc Oleg Nesterov ]

On 03/10/2014 12:56 PM, Sree Harsha Totakura wrote:
> -----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.

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

This was broken by

commit 8aac62706adaaf0fab02c4327761561c8bda9448
Author: Oleg Nesterov <oleg@redhat.com>
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

Re: pppd service crash in linux-3.13.6

[Oleg Nesterov]

On 03/10, Peter Hurley wrote:
>
> [ +cc Oleg Nesterov ]

Thanks.

> The NULL ptr dereference is from following the current->nsproxy ptr
> in ppp_register_channel().
>
> This was broken by
>
> commit 8aac62706adaaf0fab02c4327761561c8bda9448
> Author: Oleg Nesterov <oleg@redhat.com>
> 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.

--- x/kernel/exit.c
+++ kernel/exit.c/
@@ -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
 	 */

Re: pppd service crash in linux-3.13.6

[Peter Hurley]

Hi Oleg,

On 03/13/2014 01:06 PM, Oleg Nesterov wrote:
> On 03/10, Peter Hurley wrote:
>>
>> [ +cc Oleg Nesterov ]
>
> Thanks.
>
>> The NULL ptr dereference is from following the current->nsproxy ptr
>> in ppp_register_channel().
>>
>> This was broken by
>>
>> commit 8aac62706adaaf0fab02c4327761561c8bda9448
>> Author: Oleg Nesterov <oleg@redhat.com>
>> 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()".

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

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

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

> Oleg.
>
> --- x/kernel/exit.c
> +++ kernel/exit.c/
> @@ -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
>   	 */

Regards,
Peter Hurley

Re: pppd service crash in linux-3.13.6

[Peter Hurley]

[ +cc Eric Biederman ]

On 03/13/2014 01:55 PM, Peter Hurley wrote:
> Hi Oleg,
>
> On 03/13/2014 01:06 PM, Oleg Nesterov wrote:
>> On 03/10, Peter Hurley wrote:
>>>
>>> [ +cc Oleg Nesterov ]
>>
>> Thanks.
>>
>>> The NULL ptr dereference is from following the current->nsproxy ptr
>>> in ppp_register_channel().
>>>
>>> This was broken by
>>>
>>> commit 8aac62706adaaf0fab02c4327761561c8bda9448
>>> Author: Oleg Nesterov <oleg@redhat.com>
>>> 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 :)

> I didn't look into what motivated the change; I will now though.
>
>> 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.

> 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

Re: pppd service crash in linux-3.13.6

[Peter Hurley]

On 03/14/2014 10:19 AM, Peter Hurley wrote:
> 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).

Re: pppd service crash in linux-3.13.6

[Oleg Nesterov]

On 03/14, Peter Hurley wrote:
>
>> On 03/13/2014 01:06 PM, Oleg Nesterov wrote:
>>>
>>> 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.

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

Re: pppd service crash in linux-3.13.6

[Peter Hurley]

On 03/14/2014 03:23 PM, Oleg Nesterov wrote:
> On 03/14, Peter Hurley wrote:
>>
>>> On 03/13/2014 01:06 PM, Oleg Nesterov wrote:
>>>>
>>>> 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.

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.

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

Re: pppd service crash in linux-3.13.6

[Oleg Nesterov]

On 03/14, Peter Hurley wrote:
>
> On 03/14/2014 03:23 PM, Oleg Nesterov wrote:
>> On 03/14, Peter Hurley wrote:
>>>
> Yes, cgroup_release_agent() is the work function that is scheduled.
>
>>> 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.

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

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

Re: pppd service crash in linux-3.13.6

[Peter Hurley]

On 03/14/2014 05:04 PM, Oleg Nesterov wrote:
> On 03/14, Peter Hurley wrote:
>> On 03/14/2014 03:23 PM, Oleg Nesterov wrote:
>>> On 03/14, Peter Hurley wrote:
>>>>
>> Yes, cgroup_release_agent() is the work function that is scheduled.
>>
>>>> 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.
>
> Which group/tty ? call_usermodehelper() asks the workqueue thread
> to kthread_create/exec. See also below...
>
>> 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

[PATCH 0/2] (Was: pppd service crash in linux-3.13.6)

[Oleg Nesterov]

On 03/15, Peter Hurley wrote:
>
> On 03/14/2014 05:04 PM, Oleg Nesterov wrote:
>>
>> 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.

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

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

[Oleg Nesterov]

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: stable@vger.kernel.org # v3.10+
Reported-by: Sree Harsha Totakura <sreeharsha@totakura.in>
Investigated-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
 kernel/exit.c |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index 790b73c..5d5b472 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -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
 	 */
-- 
1.5.5.1

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

[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 <oleg@redhat.com>
---
 kernel/exit.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index 5d5b472..6d1f245 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -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);
-- 
1.5.5.1

Re: pppd service crash in linux-3.13.6

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

On Mon, 2014-03-10 at 17:56 +0100, Sree Harsha Totakura wrote:
> -----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

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

[...]
> 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.

-- 
Ben Hutchings
Computers are not intelligent.	They only think they are.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: pppd service crash in linux-3.13.6

[Sree Harsha Totakura]

[-- Attachment #1.1: Type: text/plain, Size: 188 bytes --]

On 03/10/2014 08:54 PM, Ben Hutchings wrote:
> You should send the 'Oops' messages which should be further up the
> log file.

Attached is a file containing the oops message.

Sree

[-- Attachment #1.2: oops.txt --]
[-- Type: text/plain, Size: 11612 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 534 bytes --]