<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/net/hsr, branch linus/master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/net/hsr?h=linus%2Fmaster</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/net/hsr?h=linus%2Fmaster'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-03-12T07:17:24Z</updated>
<entry>
<title>net: add per-cpu storage and net-&gt;core_stats</title>
<updated>2022-03-12T07:17:24Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2022-03-11T05:14:20Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=625788b5844511cf4c30cffa7fa0bc3a69cebc82'/>
<id>urn:sha1:625788b5844511cf4c30cffa7fa0bc3a69cebc82</id>
<content type='text'>
Before adding yet another possibly contended atomic_long_t,
it is time to add per-cpu storage for existing ones:
 dev-&gt;tx_dropped, dev-&gt;rx_dropped, and dev-&gt;rx_nohandler

Because many devices do not have to increment such counters,
allocate the per-cpu storage on demand, so that dev_get_stats()
does not have to spend considerable time folding zero counters.

Note that some drivers have abused these counters which
were supposed to be only used by core networking stack.

v4: should use per_cpu_ptr() in dev_get_stats() (Jakub)
v3: added a READ_ONCE() in netdev_core_stats_alloc() (Paolo)
v2: add a missing include (reported by kernel test robot &lt;lkp@intel.com&gt;)
    Change in netdev_core_stats_alloc() (Jakub)

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: jeffreyji &lt;jeffreyji@google.com&gt;
Reviewed-by: Brian Vazquez &lt;brianvv@google.com&gt;
Reviewed-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Acked-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Link: https://lore.kernel.org/r/20220311051420.2608812-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>flow_dissector: Add support for HSR</title>
<updated>2022-03-03T06:44:49Z</updated>
<author>
<name>Kurt Kanzenbach</name>
<email>kurt@linutronix.de</email>
</author>
<published>2022-02-28T19:58:56Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=bf08824a0f4776fc0626b82b6924fa1a5643eacb'/>
<id>urn:sha1:bf08824a0f4776fc0626b82b6924fa1a5643eacb</id>
<content type='text'>
Network drivers such as igb or igc call eth_get_headlen() to determine the
header length for their to be constructed skbs in receive path.

When running HSR on top of these drivers, it results in triggering BUG_ON() in
skb_pull(). The reason is the skb headlen is not sufficient for HSR to work
correctly. skb_pull() notices that.

For instance, eth_get_headlen() returns 14 bytes for TCP traffic over HSR which
is not correct. The problem is, the flow dissection code does not take HSR into
account. Therefore, add support for it.

Reported-by: Anthony Harivel &lt;anthony.harivel@linutronix.de&gt;
Signed-off-by: Kurt Kanzenbach &lt;kurt@linutronix.de&gt;
Link: https://lore.kernel.org/r/20220228195856.88187-1-kurt@linutronix.de
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: hsr: fix hsr build error when lockdep is not enabled</title>
<updated>2022-02-22T04:43:10Z</updated>
<author>
<name>Juhee Kang</name>
<email>claudiajkang@gmail.com</email>
</author>
<published>2022-02-20T15:32:50Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=a0b92e0514bb3c5e57c33fd720724a629f67e042'/>
<id>urn:sha1:a0b92e0514bb3c5e57c33fd720724a629f67e042</id>
<content type='text'>
In hsr, lockdep_is_held() is needed for rcu_dereference_bh_check().
But if lockdep is not enabled, lockdep_is_held() causes a build error:

    ERROR: modpost: "lockdep_is_held" [net/hsr/hsr.ko] undefined!

Thus, this patch solved by adding lockdep_hsr_is_held(). This helper
function calls the lockdep_is_held() when lockdep is enabled, and returns 1
if not defined.

Fixes: e7f27420681f ("net: hsr: fix suspicious RCU usage warning in hsr_node_get_first()")
Reported-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: Juhee Kang &lt;claudiajkang@gmail.com&gt;
Link: https://lore.kernel.org/r/20220220153250.5285-1-claudiajkang@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: hsr: fix suspicious RCU usage warning in hsr_node_get_first()</title>
<updated>2022-02-19T16:39:45Z</updated>
<author>
<name>Juhee Kang</name>
<email>claudiajkang@gmail.com</email>
</author>
<published>2022-02-19T15:29:59Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=e7f27420681f23e7e0f28beed38144058752112e'/>
<id>urn:sha1:e7f27420681f23e7e0f28beed38144058752112e</id>
<content type='text'>
When hsr_create_self_node() calls hsr_node_get_first(), the suspicious
RCU usage warning is occurred. The reason why this warning is raised is
the callers of hsr_node_get_first() use rcu_read_lock_bh() and
other different synchronization mechanisms. Thus, this patch solved by
replacing rcu_dereference() with rcu_dereference_bh_check().

The kernel test robot reports:
    [   50.083470][ T3596] =============================
    [   50.088648][ T3596] WARNING: suspicious RCU usage
    [   50.093785][ T3596] 5.17.0-rc3-next-20220208-syzkaller #0 Not tainted
    [   50.100669][ T3596] -----------------------------
    [   50.105513][ T3596] net/hsr/hsr_framereg.c:34 suspicious rcu_dereference_check() usage!
    [   50.113799][ T3596]
    [   50.113799][ T3596] other info that might help us debug this:
    [   50.113799][ T3596]
    [   50.124257][ T3596]
    [   50.124257][ T3596] rcu_scheduler_active = 2, debug_locks = 1
    [   50.132368][ T3596] 2 locks held by syz-executor.0/3596:
    [   50.137863][ T3596]  #0: ffffffff8d3357e8 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x3be/0xb80
    [   50.147470][ T3596]  #1: ffff88807ec9d5f0 (&amp;hsr-&gt;list_lock){+...}-{2:2}, at: hsr_create_self_node+0x225/0x650
    [   50.157623][ T3596]
    [   50.157623][ T3596] stack backtrace:
    [   50.163510][ T3596] CPU: 1 PID: 3596 Comm: syz-executor.0 Not tainted 5.17.0-rc3-next-20220208-syzkaller #0
    [   50.173381][ T3596] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    [   50.183623][ T3596] Call Trace:
    [   50.186904][ T3596]  &lt;TASK&gt;
    [   50.189844][ T3596]  dump_stack_lvl+0xcd/0x134
    [   50.194640][ T3596]  hsr_node_get_first+0x9b/0xb0
    [   50.199499][ T3596]  hsr_create_self_node+0x22d/0x650
    [   50.204688][ T3596]  hsr_dev_finalize+0x2c1/0x7d0
    [   50.209669][ T3596]  hsr_newlink+0x315/0x730
    [   50.214113][ T3596]  ? hsr_dellink+0x130/0x130
    [   50.218789][ T3596]  ? rtnl_create_link+0x7e8/0xc00
    [   50.223803][ T3596]  ? hsr_dellink+0x130/0x130
    [   50.228397][ T3596]  __rtnl_newlink+0x107c/0x1760
    [   50.233249][ T3596]  ? rtnl_setlink+0x3c0/0x3c0
    [   50.238043][ T3596]  ? is_bpf_text_address+0x77/0x170
    [   50.243362][ T3596]  ? lock_downgrade+0x6e0/0x6e0
    [   50.248219][ T3596]  ? unwind_next_frame+0xee1/0x1ce0
    [   50.253605][ T3596]  ? entry_SYSCALL_64_after_hwframe+0x44/0xae
    [   50.259669][ T3596]  ? __sanitizer_cov_trace_cmp4+0x1c/0x70
    [   50.265423][ T3596]  ? is_bpf_text_address+0x99/0x170
    [   50.270819][ T3596]  ? kernel_text_address+0x39/0x80
    [   50.275950][ T3596]  ? __kernel_text_address+0x9/0x30
    [   50.281336][ T3596]  ? unwind_get_return_address+0x51/0x90
    [   50.286975][ T3596]  ? create_prof_cpu_mask+0x20/0x20
    [   50.292178][ T3596]  ? arch_stack_walk+0x93/0xe0
    [   50.297172][ T3596]  ? kmem_cache_alloc_trace+0x42/0x2c0
    [   50.302637][ T3596]  ? rcu_read_lock_sched_held+0x3a/0x70
    [   50.308194][ T3596]  rtnl_newlink+0x64/0xa0
    [   50.312524][ T3596]  ? __rtnl_newlink+0x1760/0x1760
    [   50.317545][ T3596]  rtnetlink_rcv_msg+0x413/0xb80
    [   50.322631][ T3596]  ? rtnl_newlink+0xa0/0xa0
    [   50.327159][ T3596]  netlink_rcv_skb+0x153/0x420
    [   50.331931][ T3596]  ? rtnl_newlink+0xa0/0xa0
    [   50.336436][ T3596]  ? netlink_ack+0xa80/0xa80
    [   50.341095][ T3596]  ? netlink_deliver_tap+0x1a2/0xc40
    [   50.346532][ T3596]  ? netlink_deliver_tap+0x1b1/0xc40
    [   50.351839][ T3596]  netlink_unicast+0x539/0x7e0
    [   50.356633][ T3596]  ? netlink_attachskb+0x880/0x880
    [   50.361750][ T3596]  ? __sanitizer_cov_trace_const_cmp8+0x1d/0x70
    [   50.368003][ T3596]  ? __sanitizer_cov_trace_const_cmp8+0x1d/0x70
    [   50.374707][ T3596]  ? __phys_addr_symbol+0x2c/0x70
    [   50.379753][ T3596]  ? __sanitizer_cov_trace_cmp8+0x1d/0x70
    [   50.385568][ T3596]  ? __check_object_size+0x16c/0x4f0
    [   50.390859][ T3596]  netlink_sendmsg+0x904/0xe00
    [   50.395715][ T3596]  ? netlink_unicast+0x7e0/0x7e0
    [   50.400722][ T3596]  ? __sanitizer_cov_trace_const_cmp4+0x1c/0x70
    [   50.407003][ T3596]  ? netlink_unicast+0x7e0/0x7e0
    [   50.412119][ T3596]  sock_sendmsg+0xcf/0x120
    [   50.416548][ T3596]  __sys_sendto+0x21c/0x320
    [   50.421052][ T3596]  ? __ia32_sys_getpeername+0xb0/0xb0
    [   50.426427][ T3596]  ? lockdep_hardirqs_on_prepare+0x400/0x400
    [   50.432721][ T3596]  ? __context_tracking_exit+0xb8/0xe0
    [   50.438188][ T3596]  ? lock_downgrade+0x6e0/0x6e0
    [   50.443041][ T3596]  ? lock_downgrade+0x6e0/0x6e0
    [   50.447902][ T3596]  __x64_sys_sendto+0xdd/0x1b0
    [   50.452759][ T3596]  ? lockdep_hardirqs_on+0x79/0x100
    [   50.457964][ T3596]  ? syscall_enter_from_user_mode+0x21/0x70
    [   50.464150][ T3596]  do_syscall_64+0x35/0xb0
    [   50.468565][ T3596]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    [   50.474452][ T3596] RIP: 0033:0x7f3148504e1c
    [   50.479052][ T3596] Code: fa fa ff ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 20 fb ff ff 48 8b
    [   50.498926][ T3596] RSP: 002b:00007ffeab5f2ab0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
    [   50.507342][ T3596] RAX: ffffffffffffffda RBX: 00007f314959d320 RCX: 00007f3148504e1c
    [   50.515393][ T3596] RDX: 0000000000000048 RSI: 00007f314959d370 RDI: 0000000000000003
    [   50.523444][ T3596] RBP: 0000000000000000 R08: 00007ffeab5f2b04 R09: 000000000000000c
    [   50.531492][ T3596] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
    [   50.539455][ T3596] R13: 00007f314959d370 R14: 0000000000000003 R15: 0000000000000000

Fixes: 4acc45db7115 ("net: hsr: use hlist_head instead of list_head for mac addresses")
Reported-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Reported-and-tested-by: syzbot+f0eb4f3876de066b128c@syzkaller.appspotmail.com
Signed-off-by: Juhee Kang &lt;claudiajkang@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: hsr: use hlist_head instead of list_head for mac addresses</title>
<updated>2022-02-06T10:55:52Z</updated>
<author>
<name>Juhee Kang</name>
<email>claudiajkang@gmail.com</email>
</author>
<published>2022-02-05T15:40:38Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=4acc45db711586dadb98e681ccb93f29372907a2'/>
<id>urn:sha1:4acc45db711586dadb98e681ccb93f29372907a2</id>
<content type='text'>
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.

    Condition: registered 10,000 known HSR nodes
    Before:
    # iperf3 -c 192.168.10.1 -i 1 -t 10
    Connecting to host 192.168.10.1, port 5201
    [  5] local 192.168.10.2 port 59442 connected to 192.168.10.1 port 5201
    [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
    [  5]   0.00-1.49   sec  3.75 MBytes  21.1 Mbits/sec    0    158 KBytes
    [  5]   1.49-2.05   sec  1.25 MBytes  18.7 Mbits/sec    0    166 KBytes
    [  5]   2.05-3.06   sec  2.44 MBytes  20.3 Mbits/sec   56   16.9 KBytes
    [  5]   3.06-4.08   sec  1.43 MBytes  11.7 Mbits/sec   11   38.0 KBytes
    [  5]   4.08-5.00   sec   951 KBytes  8.49 Mbits/sec    0   56.3 KBytes

    After:
    # iperf3 -c 192.168.10.1 -i 1 -t 10
    Connecting to host 192.168.10.1, port 5201
    [  5] local 192.168.10.2 port 36460 connected to 192.168.10.1 port 5201
    [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
    [  5]   0.00-1.00   sec  7.39 MBytes  62.0 Mbits/sec    3    130 KBytes
    [  5]   1.00-2.00   sec  5.06 MBytes  42.4 Mbits/sec   16    113 KBytes
    [  5]   2.00-3.00   sec  8.58 MBytes  72.0 Mbits/sec   42   94.3 KBytes
    [  5]   3.00-4.00   sec  7.44 MBytes  62.4 Mbits/sec    2    131 KBytes
    [  5]   4.00-5.07   sec  8.13 MBytes  63.5 Mbits/sec   38   92.9 KBytes

Signed-off-by: Juhee Kang &lt;claudiajkang@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>hsr: remove get_prp_lan_id()</title>
<updated>2022-01-27T13:53:27Z</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2022-01-26T19:11:01Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=0ab1e6d9a453459ce5104a3412e9c193608971bd'/>
<id>urn:sha1:0ab1e6d9a453459ce5104a3412e9c193608971bd</id>
<content type='text'>
get_prp_lan_id() has never been used.

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: Write lock dev_base_lock without disabling bottom halves.</title>
<updated>2021-11-29T12:12:36Z</updated>
<author>
<name>Sebastian Andrzej Siewior</name>
<email>bigeasy@linutronix.de</email>
</author>
<published>2021-11-26T16:15:29Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=fd888e85fe6b661e78044dddfec0be5271afa626'/>
<id>urn:sha1:fd888e85fe6b661e78044dddfec0be5271afa626</id>
<content type='text'>
The writer acquires dev_base_lock with disabled bottom halves.
The reader can acquire dev_base_lock without disabling bottom halves
because there is no writer in softirq context.

On PREEMPT_RT the softirqs are preemptible and local_bh_disable() acts
as a lock to ensure that resources, that are protected by disabling
bottom halves, remain protected.
This leads to a circular locking dependency if the lock acquired with
disabled bottom halves (as in write_lock_bh()) and somewhere else with
enabled bottom halves (as by read_lock() in netstat_show()) followed by
disabling bottom halves (cxgb_get_stats() -&gt; t4_wr_mbox_meat_timeout()
-&gt; spin_lock_bh()). This is the reverse locking order.

All read_lock() invocation are from sysfs callback which are not invoked
from softirq context. Therefore there is no need to disable bottom
halves while acquiring a write lock.

Acquire the write lock of dev_base_lock without disabling bottom halves.

Reported-by: Pei Zhang &lt;pezhang@redhat.com&gt;
Reported-by: Luis Claudio R. Goncalves &lt;lgoncalv@redhat.com&gt;
Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: hsr: Add support for redbox supervision frames</title>
<updated>2021-10-26T13:52:17Z</updated>
<author>
<name>Andreas Oetken</name>
<email>ennoerlangen@gmail.com</email>
</author>
<published>2021-10-25T18:56:18Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=eafaa88b3eb7f28aecb222281655473431d3ef2e'/>
<id>urn:sha1:eafaa88b3eb7f28aecb222281655473431d3ef2e</id>
<content type='text'>
added support for the redbox supervision frames
as defined in the IEC-62439-3:2018.

Signed-off-by: Andreas Oetken &lt;andreas.oetken@siemens-energy.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: hsr: get ready for const netdev-&gt;dev_addr</title>
<updated>2021-10-24T12:59:44Z</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2021-10-22T23:21:00Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=39c19fb9b4f9a7e1b29027fad9e1fa933dddf36d'/>
<id>urn:sha1:39c19fb9b4f9a7e1b29027fad9e1fa933dddf36d</id>
<content type='text'>
hsr_create_self_node() may get netdev-&gt;dev_addr
passed as argument, netdev-&gt;dev_addr will be
const soon.

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: use eth_hw_addr_set() instead of ether_addr_copy()</title>
<updated>2021-10-02T13:18:25Z</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2021-10-01T21:32:22Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=e35b8d7dbb094c79daf920797c372911edc2d525'/>
<id>urn:sha1:e35b8d7dbb094c79daf920797c372911edc2d525</id>
<content type='text'>
Convert from ether_addr_copy() to eth_hw_addr_set():

  @@
  expression dev, np;
  @@
  - ether_addr_copy(dev-&gt;dev_addr, np)
  + eth_hw_addr_set(dev, np)

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
