2017 21:06
To: Elad Nachman
Cc: netdev@vger.kernel.org
Subject: Re: Kernel 4.6.7-rt14 kernel workqueue lockup - rtnl deadlock plus
syscall endless loop
From: Elad Nachman
Date: Tue, 17 Jan 2017 18:15:19 +
> Any thought about limiting the amount of busy polling? Say if more
> than X
From: Elad Nachman
Date: Tue, 17 Jan 2017 18:15:19 +
> Any thought about limiting the amount of busy polling? Say if more
> than X polls are done within a jiffy, then at least for preemptable
> kernels you can sleep for a jiffy inside the syscall to yield the
> CPU for a while?
We cannot yi
...@davemloft.net]
Sent: יום ג 17 ינואר 2017 19:58
To: Elad Nachman
Cc: netdev@vger.kernel.org
Subject: Re: Kernel 4.6.7-rt14 kernel workqueue lockup - rtnl deadlock plus
syscall endless loop
From: Elad Nachman
Date: Tue, 17 Jan 2017 17:39:03 +
> What's more odd about this is that i
On Tue, 17 Jan 2017 17:39:03 +
Elad Nachman wrote:
> Hi,
>
> I am experiencing sporadic work queue lockups on kernel 4.6.7-rt14
> (mach-socfpga).
>
> Using a HW debugger I got the following information:
>
> A process containing a network namespace is terminating itself (SIGKILL),
> which
From: Elad Nachman
Date: Tue, 17 Jan 2017 17:39:03 +
> What's more odd about this is that it's very unusual and strange for
> a kernel function to invoke the restart mechanism because a lock is
> being held - the point of the restart mechanism is to allow userspace
> signal handlers to run, s
Hi,
I am experiencing sporadic work queue lockups on kernel 4.6.7-rt14
(mach-socfpga).
Using a HW debugger I got the following information:
A process containing a network namespace is terminating itself (SIGKILL), which
causes cleanup_net() to be scheduled to kworker/u4:2 to clean up the netwo
