[lkml]   [2018]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: INFO: task hung in ip6gre_exit_batch_net
On 05.06.2018 12:36, Dmitry Vyukov wrote:
> On Tue, Jun 5, 2018 at 11:03 AM, Kirill Tkhai <> wrote:
>> Hi, Dmirty!
>> On 04.06.2018 18:22, Dmitry Vyukov wrote:
>>> On Mon, Jun 4, 2018 at 5:03 PM, syzbot
>>> <> wrote:
>>>> Hello,
>>>> syzbot found the following crash on:
>>>> HEAD commit: bc2dbc5420e8 Merge branch 'akpm' (patches from Andrew)
>>>> git tree: upstream
>>>> console output:
>>>> kernel config:
>>>> dashboard link:
>>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>>> Unfortunately, I don't have any reproducer for this crash yet.
>>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>>> Reported-by:
>>> Another hang on rtnl lock:
>>> #syz dup: INFO: task hung in netdev_run_todo
>>> May be related to "unregister_netdevice: waiting for DEV to become free":
> netdev_wait_allrefs does not hold rtnl lock during waiting, so it must
> be something different.
>>> Any other explanations for massive hangs on rtnl lock for minutes?
>> To exclude the situation, when a task exists with rtnl_mutex held:
>> would the pr_warn() from print_held_locks_bug() be included in the console output
>> if they appear?
> Yes, everything containing "WARNING:" is detected as bug.

OK, then dead task not releasing the lock is excluded.

One more assumption: someone corrupted memory around rtnl_mutex and it looks like locked.
(I track lockdep "(rtnl_mutex){+.+.}" prints in initial message as "nobody owns rtnl_mutex").
There may help a crash dump of the VM.

Also, there may be a locking code BUG, but this seems the least probable for me.


 \ /
  Last update: 2018-06-05 15:57    [W:0.050 / U:1.828 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site