netdev - Re: Dead lock condition occured ipanic during register_netdevice

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 31 May 2018 14:56:21 +0530
From:   "Bharadiya,Pankaj" <pankaj.laxminarayan.bharadiya@...el.com>
To:     Kirill Tkhai <ktkhai@...tuozzo.com>
Cc:     "Mansoor, Illyas" <illyas.mansoor@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Feng, Fleming" <fleming.feng@...el.com>,
        "Li, Lili" <lili.li@...el.com>,
        "Zhang, Baoli" <baoli.zhang@...el.com>,
        "Pan, Kris" <kris.pan@...el.com>, "Xia, Hui" <hui.xia@...el.com>,
        "Mei, Paul" <paul.mei@...el.com>
Subject: Re: Dead lock condition occured ipanic during
 register_netdevice_notifier call in 4.9.102 <Draft>

On Thu, May 31, 2018 at 12:21:31PM +0300, Kirill Tkhai wrote:
> Hi, Illyas,
> 
> On 31.05.2018 11:43, Mansoor, Illyas wrote:
> > We are facing mutex dead lock condition that we think might be related to a fix that you have provided in:
> > Merge branch 'Close-race-between-un-register_netdevice_notifier-and-pernet_operations' commit b9a12601541eb55d07e00261a5112a4bc36fe7be
> > 
> > We tried to backport the patch series, but got stuck due to dependencies not met in 4.9.102 kernel for these patch series.
> > Could you please provide some pointers, so that we can fix in 4.9.y kernel.
> > 
> > Appreciate any help or pointers on this one.
> > 
> > Ipanic logs pasted below:
> > 
> > <3>[ 6513.681473] INFO: task sensors@...-ser:2744 blocked for more than 120 seconds.
> > <3>[ 6513.689723]       Tainted: P     U  W  O    4.9.102-quilt-2e5dc0ac-07850-g222b9655589b #1
> > <3>[ 6513.699108] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > <6>[ 6513.707997] sensors@...-ser D    0  2744      1 0x00000000
> > <4>[ 6513.708007]  ffff880223f38040 ffff88027fc980c0 0000000000000000 ffff880271987000
> > <4>[ 6513.708024]  ffff88026f9ae040 ffffc90000d57d40 ffffffff81b363d1 ffffffff81396e0b
> > <4>[ 6513.708032]  00ffc90000d57d20 ffff88027fc980c0 ffffc90000d57d90 ffff88026f9ae040
> > <4>[ 6513.708040] Call Trace:
> > <4>[ 6513.708056]  [<ffffffff81b363d1>] ? __schedule+0x221/0x6e0
> > <4>[ 6513.708063]  [<ffffffff81396e0b>] ? sidtab_context_to_sid+0x39b/0x410
> > <4>[ 6513.708068]  [<ffffffff81b368c6>] schedule+0x36/0x90
> > <4>[ 6513.708072]  [<ffffffff81b36d18>] schedule_preempt_disabled+0x18/0x30
> > <4>[ 6513.708078]  [<ffffffff81b39a25>] __mutex_lock_slowpath+0x185/0x3f0
> > <4>[ 6513.708083]  [<ffffffff81b39cb5>] mutex_lock+0x25/0x30
> > <4>[ 6513.708089]  [<ffffffff81993fa5>] rtnl_lock+0x15/0x20
> > <4>[ 6513.708095]  [<ffffffff8197d29d>] register_netdevice_notifier+0x2d/0x200
> > <4>[ 6513.708107]  [<ffffffff81ad64db>] raw_init+0x8b/0x90
> > <4>[ 6513.708118]  [<ffffffff81ad52e1>] can_create+0xe1/0x1c0
> > <4>[ 6513.708129]  [<ffffffff819645fe>] __sock_create+0x12e/0x210
> > <4>[ 6513.708141]  [<ffffffff81965fe5>] SyS_socket+0x55/0xb0
> > <4>[ 6513.708156]  [<ffffffff81001fca>] do_syscall_64+0x6a/0xe0
> > <4>[ 6513.708166]  [<ffffffff81b3dd20>] entry_SYSCALL_64_after_swapgs+0x5d/0xd7
> > <4>[ 6513.708171] NMI backtrace for cpu 2
> > <4>[ 6513.708178] CPU: 2 PID: 482 Comm: khungtaskd Tainted: P     U  W  O    4.9.102-quilt-2e5dc0ac-07850-g222b9655589b #1
> > <4>[ 6513.708180]  ffffc90000eafdd0 ffffffff813f56bc 0000000000000000 0000000000000000
> > <4>[ 6513.708188]  ffffc90000eafe00 ffffffff813f9fe1 0000000000000002 0000000000000000
> > <4>[ 6513.708195]  ffffffff81042d80 ffffffff826120f8 ffffc90000eafe30 ffffffff813fa0a3
> 
> 1)I'm not sure commit b9a12601541eb55d07e00261a5112a4bc36fe7be will help here, because this
> stack looks for me like just someone does not release the mutex. It's possible firstly
> try to analyze who actually owns it.
> 
> 2)Also, note that rtnl_is_locked() is used in wrong way in one driver there
> (see WILC_WFI_deinit_mon_interface()), so it also may introduce an imbalance
> (if you use the driver).
>

Thank you for your quick response. We will look into your suggestions and get back.

Thanks,
Pankaj
 
> Kirill