netdev - Re: [PATCH v4 net-next] net: hsr: use hlist_head instead of list

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:   Tue, 8 Feb 2022 14:42:47 +0900
From:   Juhee Kang <claudiajkang@...il.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     davem@...emloft.net, Jakub Kicinski <kuba@...nel.org>,
        Networking <netdev@...r.kernel.org>, ennoerlangen@...il.com,
        george.mccollister@...il.com, olteanv@...il.com,
        marco.wenzel@...berle.de, xiong.zhenwu@....com.cn
Subject: Re: [PATCH v4 net-next] net: hsr: use hlist_head instead of list_head
 for mac addresses

On Tue, Feb 8, 2022 at 2:23 PM Eric Dumazet <eric.dumazet@...il.com> wrote:
>
>
> On 2/6/22 03:10, patchwork-bot+netdevbpf@...nel.org wrote:
> > Hello:
> >
> > This patch was applied to netdev/net-next.git (master)
> > by David S. Miller <davem@...emloft.net>:
> >
> > On Sat,  5 Feb 2022 15:40:38 +0000 you wrote:
> >> Currently, HSR manages mac addresses of known HSR nodes by using list_head.
> >> It takes a lot of time when there are a lot of registered nodes due to
> >> finding specific mac address nodes by using linear search. We can be
> >> reducing the time by using hlist. Thus, this patch moves list_head to
> >> hlist_head for mac addresses and this allows for further improvement of
> >> network performance.
> >>
> >> [...]
> > Here is the summary with links:
> >    - [v4,net-next] net: hsr: use hlist_head instead of list_head for mac addresses
> >      https://git.kernel.org/netdev/net-next/c/4acc45db7115
> >
> > You are awesome, thank you!
>
>
> I think this patch has not been tested with CONFIG_PROVE_RCU=y
>
>
> WARNING: suspicious RCU usage
> 5.17.0-rc3-next-20220207-syzkaller #0 Not tainted
> -----------------------------
> net/hsr/hsr_framereg.c:34 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 2, debug_locks = 1
> 2 locks held by syz-executor.0/3603:
>   #0: ffffffff8d3353a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock
> net/core/rtnetlink.c:72 [inline]
>   #0: ffffffff8d3353a8 (rtnl_mutex){+.+.}-{3:3}, at:
> rtnetlink_rcv_msg+0x3be/0xb80 net/core/rtnetlink.c:5591
>   #1: ffff88806e13d5f0 (&hsr->list_lock){+...}-{2:2}, at: spin_lock_bh
> include/linux/spinlock.h:359 [inline]
>   #1: ffff88806e13d5f0 (&hsr->list_lock){+...}-{2:2}, at:
> hsr_create_self_node+0x225/0x650 net/hsr/hsr_framereg.c:108
>
> stack backtrace:
> CPU: 0 PID: 3603 Comm: syz-executor.0 Not tainted
> 5.17.0-rc3-next-20220207-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>   <TASK>
>   __dump_stack lib/dump_stack.c:88 [inline]
>   dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
>   hsr_node_get_first+0x9b/0xb0 net/hsr/hsr_framereg.c:34
>   hsr_create_self_node+0x22d/0x650 net/hsr/hsr_framereg.c:109
>   hsr_dev_finalize+0x2c1/0x7d0 net/hsr/hsr_device.c:514
>   hsr_newlink+0x315/0x730 net/hsr/hsr_netlink.c:102
>   __rtnl_newlink+0x107c/0x1760 net/core/rtnetlink.c:3481
>   rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3529
>   rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5594
>   netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494
>   netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
>   netlink_unicast+0x539/0x7e0 net/netlink/af_netlink.c:1343
>   netlink_sendmsg+0x904/0xe00 net/netlink/af_netlink.c:1919
>   sock_sendmsg_nosec net/socket.c:705 [inline]
>   sock_sendmsg+0xcf/0x120 net/socket.c:725
>   __sys_sendto+0x21c/0x320 net/socket.c:2040
>   __do_sys_sendto net/socket.c:2052 [inline]
>   __se_sys_sendto net/socket.c:2048 [inline]
>   __x64_sys_sendto+0xdd/0x1b0 net/socket.c:2048
>   do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>   do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
>   entry_SYSCALL_64_after_hwframe+0x44/0xae
>
>


-- 

Hi Eric,
Thank you so much for catching it.

I will send a new patch after fixing this problem and some tests.

Best regards,
Juhee Kang