- 14 Jan, 2022 1 commit
-
-
Sergey Shtylyov authored
The driver neglects to check the result of platform_get_irq_optional()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL. Stop calling devm_request_irq() with the invalid IRQ #s. Fixes: 8562056f ("net: bcmgenet: request Wake-on-LAN interrupt") Signed-off-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 13 Jan, 2022 12 commits
-
-
Kevin Bracey authored
commit 56b765b7 ("htb: improved accuracy at high rates") broke "overhead X", "linklayer atm" and "mpu X" attributes. "overhead X" and "linklayer atm" have already been fixed. This restores the "mpu X" handling, as might be used by DOCSIS or Ethernet shaping: tc class add ... htb rate X overhead 4 mpu 64 The code being fixed is used by htb, tbf and act_police. Cake has its own mpu handling. qdisc_calculate_pkt_len still uses the size table containing values adjusted for mpu by user space. iproute2 tc has always passed mpu into the kernel via a tc_ratespec structure, but the kernel never directly acted on it, merely stored it so that it could be read back by `tc class show`. Rather, tc would generate length-to-time tables that included the mpu (and linklayer) in their construction, and the kernel used those tables. Since v3.7, the tables were no longer used. Along with "mpu", this also broke "overhead" and "linklayer" which were fixed in 01cb71d2 ("net_sched: restore "overhead xxx" handling", v3.10) and 8a8e3d84 ("net_sched: restore "linklayer atm" handling", v3.11). "overhead" was fixed by simply restoring use of tc_ratespec::overhead - this had originally been used by the kernel but was initially omitted from the new non-table-based calculations. "linklayer" had been handled in the table like "mpu", but the mode was not originally passed in tc_ratespec. The new implementation was made to handle it by getting new versions of tc to pass the mode in an extended tc_ratespec, and for older versions of tc the table contents were analysed at load time to deduce linklayer. As "mpu" has always been given to the kernel in tc_ratespec, accompanying the mpu-based table, we can restore system functionality with no userspace change by making the kernel act on the tc_ratespec value. Fixes: 56b765b7 ("htb: improved accuracy at high rates") Signed-off-by:
Kevin Bracey <kevin@bracey.fi> Cc: Eric Dumazet <edumazet@google.com> Cc: Jiri Pirko <jiri@resnulli.us> Cc: Vimalkumar <j.vimal@gmail.com> Link: https://lore.kernel.org/r/20220112170210.1014351-1-kevin@bracey.fiSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Kyoungkyu Park authored
The Hucom Wireless HM-211S/K is an LTE module based on Qualcomm MDM9207. This module supports LTE Band 1, 3, 5, 7, 8 and WCDMA Band 1. Manual testing showed that only interface number two replies to QMI messages. T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=22de ProdID=9051 Rev= 3.18 S: Manufacturer=Android S: Product=Android S: SerialNumber=0123456789ABCDEF C:* #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=85(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by:
Kyoungkyu Park <choryu.park@choryu.space> Acked-by:
Bjørn Mork <bjorn@mork.no> Link: https://lore.kernel.org/r/Yd+nxAA6KorDpQFv@choryu-tfx5470hSigned-off-by:
-
Wen Gu authored
We encountered some crashes caused by the race between SMC-R link access and link clear that triggered by abnormal link group termination, such as port error. Here is an example of this kind of crashes: BUG: kernel NULL pointer dereference, address: 0000000000000000 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_llc_flow_initiate+0x44/0x190 [smc] Call Trace: <TASK> ? __smc_buf_create+0x75a/0x950 [smc] smcr_lgr_reg_rmbs+0x2a/0xbf [smc] smc_listen_work+0xf72/0x1230 [smc] ? process_one_work+0x25c/0x600 process_one_work+0x25c/0x600 worker_thread+0x4f/0x3a0 ? process_one_work+0x600/0x600 kthread+0x15d/0x1a0 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x1f/0x30 </TASK> smc_listen_work() __smc_lgr_terminate() --------------------------------------------------------------- | smc_lgr_free() | |- smcr_link_clear() | |- memset(lnk, 0) smc_listen_rdma_reg() | |- smcr_lgr_reg_rmbs() | |- smc_llc_flow_initiate() | |- access lnk->lgr (panic) | These crashes are similarly caused by clearing SMC-R link resources when some functions is still accessing to them. This patch tries to fix the issue by introducing reference count of SMC-R links and ensuring that the sensitive resources of links won't be cleared until reference count reaches zero. The operation to the SMC-R link reference count can be concluded as follows: object [hold or initialized as 1] [put] -------------------------------------------------------------------- links smcr_link_init() smcr_link_clear() connections smc_conn_create() smc_conn_free() Through this way, the clear of SMC-R links is later than the free of all the smc connections above it, thus avoiding the unsafe reference to SMC-R links. Signed-off-by:Wen Gu <guwen@linux.alibaba.com> Signed-off-by:
-
Wen Gu authored
It is no longer suitable to identify whether a smc connection is registered in a link group through checking if conn->lgr is NULL, because conn->lgr won't be reset even the connection is unregistered from a link group. So this patch introduces a new helper smc_conn_lgr_valid() and replaces all the check of conn->lgr in original implementation with the new helper to judge if conn->lgr is valid to use. Signed-off-by:
-
Eric Dumazet authored
Both fields can be read/written without synchronization, add proper accessors and documentation. Fixes: d5dd8879 ("inet: fix various use-after-free in defrags units") Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
David S. Miller authored
Wen Gu says: ==================== net/smc: Fixes for race in smc link group termination We encountered some crashes recently and they are caused by the race between the access and free of link/link group in abnormal smc link group termination. The crashes can be reproduced in frequent abnormal link group termination, like setting RNICs up/down. This set of patches tries to fix this by extending the life cycle of link/link group to ensure that they won't be referred to after cleared or freed. v1 -> v2: - Improve some comments. - Move codes of waking up lgrs_deleted wait queue from smc_lgr_free() to __smc_lgr_free(). - Move codes of waking up links_deleted wait queue from smcr_link_clear() to __smcr_link_clear(). - Move codes of smc_ibdev_cnt_dec() and put_device() from smcr_link_clear() to __smcr_link_clear() - Move smc_lgr_put() to the end of __smcr_link_clear(). - Call smc_lgr_put() after 'out' tag in smcr_link_init() when link initialization fails. - Modify the location where smc connection holds the lgr or link. before: * hold lgr in smc_lgr_register_conn(). * hold link in smcr_lgr_conn_assign_link(). after: * hold both lgr and link in smc_conn_create(). Modify the location to symmetrical with the place where smc connections put the lgr or link, which is smc_conn_free(). - Initialize conn->freed as zero in smc_conn_create(). ==================== Signed-off-by: -
Wen Gu authored
We encountered some crashes caused by the race between the access and the termination of link groups. Here are some of panic stacks we met: 1) Race between smc_clc_wait_msg() and __smc_lgr_terminate() BUG: kernel NULL pointer dereference, address: 00000000000002f0 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_clc_wait_msg+0x3eb/0x5c0 [smc] Call Trace: <TASK> ? smc_clc_send_accept+0x45/0xa0 [smc] ? smc_clc_send_accept+0x45/0xa0 [smc] smc_listen_work+0x783/0x1220 [smc] ? finish_task_switch+0xc4/0x2e0 ? process_one_work+0x1ad/0x3c0 process_one_work+0x1ad/0x3c0 worker_thread+0x4c/0x390 ? rescuer_thread+0x320/0x320 kthread+0x149/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x1f/0x30 </TASK> smc_listen_work() abnormal case like port error --------------------------------------------------------------- | __smc_lgr_terminate() | |- smc_conn_kill() | |- smc_lgr_unregister_conn() | |- set conn->lgr = NULL smc_clc_wait_msg() | |- access conn->lgr (panic) | 2) Race between smc_setsockopt() and __smc_lgr_terminate() BUG: kernel NULL pointer dereference, address: 00000000000002e8 RIP: 0010:smc_setsockopt+0x17a/0x280 [smc] Call Trace: <TASK> __sys_setsockopt+0xfc/0x190 __x64_sys_setsockopt+0x20/0x30 do_syscall_64+0x34/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> smc_setsockopt() abnormal case like port error -------------------------------------------------------------- | __smc_lgr_terminate() | |- smc_conn_kill() | |- smc_lgr_unregister_conn() | |- set conn->lgr = NULL mod_delayed_work() | |- access conn->lgr (panic) | There are some other panic places and they are caused by the similar reason as described above, which is accessing link group after termination, thus getting a NULL pointer or invalid resource. Currently, there seems to be no synchronization between the link group access and a sudden termination of it. This patch tries to fix this by introducing reference count of link group and not freeing link group until reference count is zero. Link group might be referred to by links or smc connections. So the operation to the link group reference count can be concluded as follows: object [hold or initialized as 1] [put] ------------------------------------------------------------------- link group smc_lgr_create() smc_lgr_free() connections smc_conn_create() smc_conn_free() links smcr_link_init() smcr_link_clear() Througth this way, we extend the life cycle of link group and ensure it is longer than the life cycle of connections and links above it, so that avoid invalid access to link group after its termination. Signed-off-by: -
Li Zhijian authored
timeout in settings is used by each case under the same directory, so it should adapt to the maximum runtime. A normally running net/fib_nexthops.sh may be killed by this unsuitable timeout. Furthermore, since the defect[1] of kselftests framework, net/fib_nexthops.sh which might take at least (300 * 4) seconds would block the whole kselftests framework previously. $ git grep -w 'sleep 300' tools/testing/selftests/net tools/testing/selftests/net/fib_nexthops.sh: sleep 300 tools/testing/selftests/net/fib_nexthops.sh: sleep 300 tools/testing/selftests/net/fib_nexthops.sh: sleep 300 tools/testing/selftests/net/fib_nexthops.sh: sleep 300 Enlarge the timeout by plus 300 based on the obvious largest runtime to avoid the blocking. [1]: https://www.spinics.net/lists/kernel/msg4185370.htmlSigned-off-by:
Zhou Jie <zhoujie2011@fujitsu.com> Signed-off-by:
Li Zhijian <lizhijian@fujitsu.com> Signed-off-by:
-
Vladimir Oltean authored
Since commit b3964807 ("net: mscc: ocelot: disable flow control on NPI interface"), flow control should be disabled on the DSA CPU port when used in NPI mode. However, the commit blamed in the Fixes: tag below broke this, because it allowed felix_phylink_mac_link_up() to overwrite SYS_PAUSE_CFG_PAUSE_ENA for the DSA CPU port. This issue became noticeable since the device tree update from commit 8fcea7be ("arm64: dts: ls1028a: mark internal links between Felix and ENETC as capable of flow control"). The solution is to check whether this is the currently configured NPI port from ocelot_phylink_mac_link_up(), and to not modify the statically disabled PAUSE frame transmission if it is. When the port is configured for lossless mode as opposed to tail drop mode, but the link partner (DSA master) doesn't observe the transmitted PAUSE frames, the switch termination throughput is much worse, as can be seen below. Before: root@debian:~# iperf3 -c 192.168.100.2 Connecting to host 192.168.100.2, port 5201 [ 5] local 192.168.100.1 port 37504 connected to 192.168.100.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 28.4 MBytes 238 Mbits/sec 357 22.6 KBytes [ 5] 1.00-2.00 sec 33.6 MBytes 282 Mbits/sec 426 19.8 KBytes [ 5] 2.00-3.00 sec 34.0 MBytes 285 Mbits/sec 343 21.2 KBytes [ 5] 3.00-4.00 sec 32.9 MBytes 276 Mbits/sec 354 22.6 KBytes [ 5] 4.00-5.00 sec 32.3 MBytes 271 Mbits/sec 297 18.4 KBytes ^C[ 5] 5.00-5.06 sec 2.05 MBytes 270 Mbits/sec 45 19.8 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-5.06 sec 163 MBytes 271 Mbits/sec 1822 sender [ 5] 0.00-5.06 sec 0.00 Bytes 0.00 bits/sec receiver After: root@debian:~# iperf3 -c 192.168.100.2 Connecting to host 192.168.100.2, port 5201 [ 5] local 192.168.100.1 port 49470 connected to 192.168.100.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 112 MBytes 941 Mbits/sec 259 143 KBytes [ 5] 1.00-2.00 sec 110 MBytes 920 Mbits/sec 329 144 KBytes [ 5] 2.00-3.00 sec 112 MBytes 936 Mbits/sec 255 144 KBytes [ 5] 3.00-4.00 sec 110 MBytes 927 Mbits/sec 355 105 KBytes [ 5] 4.00-5.00 sec 110 MBytes 926 Mbits/sec 350 156 KBytes [ 5] 5.00-6.00 sec 110 MBytes 925 Mbits/sec 305 148 KBytes [ 5] 6.00-7.00 sec 110 MBytes 924 Mbits/sec 320 143 KBytes [ 5] 7.00-8.00 sec 110 MBytes 925 Mbits/sec 273 97.6 KBytes [ 5] 8.00-9.00 sec 109 MBytes 913 Mbits/sec 299 141 KBytes [ 5] 9.00-10.00 sec 110 MBytes 922 Mbits/sec 287 146 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.08 GBytes 926 Mbits/sec 3032 sender [ 5] 0.00-10.00 sec 1.08 GBytes 925 Mbits/sec receiver Fixes: de274be3 ("net: dsa: felix: set TX flow control according to the phylink_mac_link_up resolution") Reported-by:
Xiaoliang Yang <xiaoliang.yang_1@nxp.com> Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
-
Colin Ian King authored
The pointer skb is redundant, it is assigned a value that is never read and hence can be removed. Cleans up clang scan warning: drivers/atm/iphase.c:205:18: warning: Although the value stored to 'skb' is used in the enclosing expression, the value is never actually read from 'skb' [deadcode.DeadStores] Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Maxim Mikityanskiy authored
The attach callback of struct Qdisc_ops is used by only a few qdiscs: mq, mqprio and htb. qdisc_graft() contains the following logic (pseudocode): if (!qdisc->ops->attach) { if (ingress) do ingress stuff; else do egress stuff; } if (!ingress) { ... if (qdisc->ops->attach) qdisc->ops->attach(qdisc); } else { ... } As we see, the attach callback is not called if the qdisc is being attached to ingress (TC_H_INGRESS). That wasn't a problem for mq and mqprio, since they contain a check that they are attached to TC_H_ROOT, and they can't be attached to TC_H_INGRESS anyway. However, the commit cited below added the attach callback to htb. It is needed for the hardware offload, but in the non-offload mode it simulates the "do egress stuff" part of the pseudocode above. The problem is that when htb is attached to ingress, neither "do ingress stuff" nor attach() is called. It results in an inconsistency, and the following message is printed to dmesg: unregister_netdevice: waiting for lo to become free. Usage count = 2 This commit addresses the issue by running "do ingress stuff" in the ingress flow even in the attach callback is present, which is fine, because attach isn't going to be called afterwards. The bug was found by syzbot and reported by Eric. Fixes: d03b195b ("sch_htb: Hierarchical QoS hardware offload") Signed-off-by:Maxim Mikityanskiy <maximmi@nvidia.com> Reported-by:
-
Pawel Dembicki authored
Modem from ZTE MF286D is an Qualcomm MDM9250 based 3G/4G modem. T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=5000 MxCh= 0 D: Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=19d2 ProdID=1485 Rev=52.87 S: Manufacturer=ZTE,Incorporated S: Product=ZTE Technologies MSM S: SerialNumber=MF286DZTED000000 C:* #Ifs= 7 Cfg#= 1 Atr=80 MxPwr=896mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=06 Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=ff Driver=rndis_host E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs E: Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms Signed-off-by:
Pawel Dembicki <paweldembicki@gmail.com> Acked-by:
-
- 12 Jan, 2022 27 commits
-
-
Ignat Korchagin authored
While experimenting with FOU encapsulation Amir noticed that encapsulated IPv6 traffic fails to be delivered, if the peer IP address is configured locally. It can be easily verified by creating a sit interface like below: $ sudo ip link add name fou_test type sit remote 127.0.0.1 encap fou encap-sport auto encap-dport 1111 $ sudo ip link set fou_test up and sending some IPv4 and IPv6 traffic to it $ ping -I fou_test -c 1 1.1.1.1 $ ping6 -I fou_test -c 1 fe80::d0b0:dfff:fe4c:fcbc "tcpdump -i any udp dst port 1111" will confirm that only the first IPv4 ping was encapsulated and attempted to be delivered. This seems like a limitation: for example, in a cloud environment the "peer" service may be arbitrarily scheduled on any server within the cluster, where all nodes are trying to send encapsulated traffic. And the unlucky node will not be able to. Moreover, delivering encapsulated IPv4 traffic locally is allowed. But I may not have all the context about this restriction and this code predates the observable git history. Reported-by:
Amir Razmjou <arazmjou@cloudflare.com> Signed-off-by:
Ignat Korchagin <ignat@cloudflare.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20220107123842.211335-1-ignat@cloudflare.comSigned-off-by:
-
Yevhen Orlov authored
* Add missed call prestera_router_fini in prestera_switch_fini * Add prestera_router_hw_fini, which verify lists are empty Fixes: 69204174 ("net: marvell: prestera: Add prestera router infra") Signed-off-by:
Yevhen Orlov <yevhen.orlov@plvision.eu> Link: https://lore.kernel.org/r/20220111011129.5457-1-yevhen.orlov@plvision.euSigned-off-by:
-
Yevhen Orlov authored
* Reverse xmas tree variables order * User friendly messages on error paths * Refactor __prestera_inetaddr_event to use early return Signed-off-by:
-
Yevhen Orlov authored
* Use refcount, instead of uint * Increment/decrement recount inside get/put * Fix error path in __prestera_vr_create. Remove unnecessary kfree. * Make __prestera_vr_destroy symmetric to "create" Fixes: bca5859b ("net: marvell: prestera: add hardware router objects accounting") Signed-off-by:
-
Yevhen Orlov authored
Field "aborted" was added in 69204174 ("net: marvell: prestera: Add prestera router infra"). It will not be used. So remove. Signed-off-by:
-
Jakub Kicinski authored
Neil Armstrong says: ==================== ARM: ox810se: Add Ethernet support This adds support for the Synopsys DWMAC controller found in the OX820SE SoC, by using almost the same glue code as the OX820. ==================== Link: https://lore.kernel.org/r/20220104145646.135877-1-narmstrong@baylibre.comSigned-off-by:
-
Neil Armstrong authored
Add support for OX810SE dwmac glue setup, which is a simplified version of the OX820 introduced later with more control on the PHY interface. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Neil Armstrong authored
Add SoC specific bindings for OX810SE support. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Jie Wang authored
In Linux bonding scenario, one packet is copied to several copies and sent by all slave device of bond0 in mode 3(broadcast mode). The mode 3 xmit function bond_xmit_broadcast() only ueses the last slave device's tx result as the final result. In this case, if the last slave device is down, then it always return NET_XMIT_DROP, even though the other slave devices xmit success. It may cause the tx statistics error, and cause the application (e.g. scp) consider the network is unreachable. For example, use the following command to configure server A. echo 3 > /sys/class/net/bond0/bonding/mode ifconfig bond0 up ifenslave bond0 eth0 eth1 ifconfig bond0 192.168.1.125 ifconfig eth0 up ifconfig eth1 down The slave device eth0 and eth1 are connected to server B(192.168.1.107). Run the ping 192.168.1.107 -c 3 -i 0.2 command, the following information is displayed. PING 192.168.1.107 (192.168.1.107) 56(84) bytes of data. 64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=0.077 ms 64 bytes from 192.168.1.107: icmp_seq=2 ttl=64 time=0.056 ms 64 bytes from 192.168.1.107: icmp_seq=3 ttl=64 time=0.051 ms 192.168.1.107 ping statistics 0 packets transmitted, 3 received Actually, the slave device eth0 of the bond successfully sends three ICMP packets, but the result shows that 0 packets are transmitted. Also if we use scp command to get remote files, the command end with the following printings. ssh_exchange_identification: read: Connection timed out So this patch modifies the bond_xmit_broadcast to return NET_XMIT_SUCCESS if one slave device in the bond sends packets successfully. If all slave devices send packets fail, the discarded packets stats is increased. The skb is released when there is no slave device in the bond or the last slave device is down. Fixes: ae46f184 ("bonding: propagate transmit status") Signed-off-by:
Jie Wang <wangjie125@huawei.com> Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
-
Eric Dumazet authored
I missed that @ndev value can be NULL. I prefer not factorizing this NULL check, and instead clearly document where a NULL might be expected. general protection fault, probably for non-canonical address 0xdffffc00000000ba: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x00000000000005d0-0x00000000000005d7] CPU: 0 PID: 19875 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__lock_acquire+0xd7a/0x5470 kernel/locking/lockdep.c:4897 Code: 14 0e 41 bf 01 00 00 00 0f 86 c8 00 00 00 89 05 5c 20 14 0e e9 bd 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 9f 2e 00 00 49 81 3e 20 c5 1a 8f 0f 84 52 f3 ff RSP: 0018:ffffc900057071d0 EFLAGS: 00010002 RAX: dffffc0000000000 RBX: 1ffff92000ae0e65 RCX: 1ffff92000ae0e4c RDX: 00000000000000ba RSI: 0000000000000000 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 R10: fffffbfff1b24ae2 R11: 000000000008808a R12: 0000000000000000 R13: ffff888040ca4000 R14: 00000000000005d0 R15: 0000000000000000 FS: 00007fbd683e0700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2be22000 CR3: 0000000013fea000 CR4: 00000000003526f0 Call Trace: <TASK> lock_acquire kernel/locking/lockdep.c:5637 [inline] lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5602 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162 ref_tracker_alloc+0x182/0x440 lib/ref_tracker.c:84 netdev_tracker_alloc include/linux/netdevice.h:3859 [inline] smc_pnet_add_eth net/smc/smc_pnet.c:372 [inline] smc_pnet_enter net/smc/smc_pnet.c:492 [inline] smc_pnet_add+0x49a/0x14d0 net/smc/smc_pnet.c:555 genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:731 genl_family_rcv_msg net/netlink/genetlink.c:775 [inline] genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:792 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494 genl_rcv+0x24/0x40 net/netlink/genetlink.c:803 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_sendmsg+0x6e8/0x810 net/socket.c:2413 ___sys_sendmsg+0xf3/0x170 net/socket.c:2467 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2496 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 Fixes: b6064524 ("net/smc: add net device tracker to struct smc_pnetentry") Signed-off-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
-
Eric Dumazet authored
I left one dev_put() in br_add_if() error path and sure enough syzbot found its way. As the tracker is allocated in new_nbp(), we must make sure to properly free it. We have to call dev_put_track(dev, &p->dev_tracker) before @p object is freed, of course. This is not an issue because br_add_if() owns a reference on @dev. Fixes: b2dcdc7f ("net: bridge: add net device refcount tracker") Signed-off-by:
-
David S. Miller authored
Alex Elder says: ==================== net: ipa: fix two replenish bugs This series contains two fixes for bugs in the IPA receive buffer replenishing code. The (new) second patch defines a bitmap to represent endpoint the replenish enabled flag. Its purpose is to prepare for the third patch, which adds an additional flag. Version 2 of this series uses bitmap operations in the second bug fix rather than an atomic variable, as suggested by Jakub. ==================== Signed-off-by: -
Alex Elder authored
We have seen cases where an endpoint RX completion interrupt arrives while replenishing for the endpoint is underway. This causes another instance of replenishing to begin as part of completing the receive transaction. If this occurs it can lead to transaction corruption. Use a new flag to ensure only one replenish instance for an endpoint executes at a time. Fixes: 84f9bd12 ("soc: qcom: ipa: IPA endpoints") Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
Define a new replenish_flags bitmap to contain Boolean flags associated with an endpoint's replenishing state. Replace the replenish_enabled field with a flag in that bitmap. This is to prepare for the next patch, which adds another flag. Signed-off-by:
-
Alex Elder authored
In ipa_endpoint_replenish(), if an error occurs when attempting to replenish a receive buffer, we just quit and try again later. In that case we increment the backlog count to reflect that the attempt was unsuccessful. Then, if the add_one flag was true we increment the backlog again. This second increment is not included in the backlog local variable though, and its value determines whether delayed work should be scheduled. This is a bug. Fix this by determining whether 1 or 2 should be added to the backlog before adding it in a atomic_add_return() call. Reviewed-by:
Matthias Kaehlcke <mka@chromium.org> Fixes: 84f9bd12 ("soc: qcom: ipa: IPA endpoints") Signed-off-by:
-
Eric Dumazet authored
syzbot was able to trigger this warning from new_slab() /* * All existing users of the __GFP_NOFAIL are blockable, so warn * of any new users that actually require GFP_NOWAIT */ if (WARN_ON_ONCE(!can_direct_reclaim)) goto fail; Indeed, we should use __GFP_NOFAIL if direct reclaim is possible. Hopefully in the future we will be able to use SLAB_NOFAILSLAB option so that syzbot can benefit from full ref_tracker even in the presence of memory fault injections. WARNING: CPU: 0 PID: 13 at mm/page_alloc.c:5081 __alloc_pages_slowpath.constprop.0+0x1b7b/0x20d0 mm/page_alloc.c:5081 mm/page_alloc.c:5081 Modules linked in: CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 5.16.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__alloc_pages_slowpath.constprop.0+0x1b7b/0x20d0 mm/page_alloc.c:5081 mm/page_alloc.c:5081 Code: 90 08 00 00 48 81 c7 d8 04 00 00 48 89 f8 48 c1 e8 03 42 80 3c 30 00 0f 84 f0 ea ff ff e8 3d 82 09 00 e9 e6 ea ff ff 4d 89 fd <0f> 0b 48 b8 00 00 00 00 00 fc ff df 48 8b 54 24 30 48 c1 ea 03 80 RSP: 0018:ffffc90000d272b8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88813fffc300 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88813fffc348 RBP: ffff88813fffc300 R08: 00000000000013dc R09: 00000000000013c8 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffffc90000d274e8 R14: dffffc0000000000 R15: ffffc90000d274e8 FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffefe6000f8 CR3: 000000001d21e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __alloc_pages+0x412/0x500 mm/page_alloc.c:5382 mm/page_alloc.c:5382 alloc_pages+0x1a7/0x300 mm/mempolicy.c:2191 mm/mempolicy.c:2191 alloc_slab_page mm/slub.c:1793 [inline] allocate_slab mm/slub.c:1938 [inline] alloc_slab_page mm/slub.c:1793 [inline] mm/slub.c:1993 allocate_slab mm/slub.c:1938 [inline] mm/slub.c:1993 new_slab+0x349/0x4a0 mm/slub.c:1993 mm/slub.c:1993 ___slab_alloc+0x918/0xfe0 mm/slub.c:3022 mm/slub.c:3022 __slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3109 mm/slub.c:3109 slab_alloc_node mm/slub.c:3200 [inline] slab_alloc mm/slub.c:3242 [inline] slab_alloc_node mm/slub.c:3200 [inline] mm/slub.c:3259 slab_alloc mm/slub.c:3242 [inline] mm/slub.c:3259 kmem_cache_alloc_trace+0x289/0x2c0 mm/slub.c:3259 mm/slub.c:3259 kmalloc include/linux/slab.h:590 [inline] kzalloc include/linux/slab.h:724 [inline] kmalloc include/linux/slab.h:590 [inline] lib/ref_tracker.c:74 kzalloc include/linux/slab.h:724 [inline] lib/ref_tracker.c:74 ref_tracker_alloc+0xe1/0x430 lib/ref_tracker.c:74 lib/ref_tracker.c:74 netdev_tracker_alloc include/linux/netdevice.h:3855 [inline] dev_hold_track include/linux/netdevice.h:3872 [inline] netdev_tracker_alloc include/linux/netdevice.h:3855 [inline] net/core/dst.c:52 dev_hold_track include/linux/netdevice.h:3872 [inline] net/core/dst.c:52 dst_init+0xe0/0x520 net/core/dst.c:52 net/core/dst.c:52 dst_alloc+0x16b/0x1f0 net/core/dst.c:96 net/core/dst.c:96 rt_dst_alloc+0x73/0x450 net/ipv4/route.c:1614 net/ipv4/route.c:1614 ip_route_input_mc net/ipv4/route.c:1720 [inline] ip_route_input_mc net/ipv4/route.c:1720 [inline] net/ipv4/route.c:2465 ip_route_input_rcu.part.0+0x4fe/0xcc0 net/ipv4/route.c:2465 net/ipv4/route.c:2465 ip_route_input_rcu net/ipv4/route.c:2420 [inline] ip_route_input_rcu net/ipv4/route.c:2420 [inline] net/ipv4/route.c:2416 ip_route_input_noref+0x1b8/0x2a0 net/ipv4/route.c:2416 net/ipv4/route.c:2416 ip_rcv_finish_core.constprop.0+0x288/0x1e90 net/ipv4/ip_input.c:354 net/ipv4/ip_input.c:354 ip_rcv_finish+0x135/0x2f0 net/ipv4/ip_input.c:427 net/ipv4/ip_input.c:427 NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] NF_HOOK include/linux/netfilter.h:307 [inline] net/ipv4/ip_input.c:540 NF_HOOK include/linux/netfilter.h:301 [inline] net/ipv4/ip_input.c:540 ip_rcv+0xaa/0xd0 net/ipv4/ip_input.c:540 net/ipv4/ip_input.c:540 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5350 net/core/dev.c:5350 __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5464 net/core/dev.c:5464 process_backlog+0x2a5/0x6c0 net/core/dev.c:5796 net/core/dev.c:5796 __napi_poll+0xaf/0x440 net/core/dev.c:6364 net/core/dev.c:6364 napi_poll net/core/dev.c:6431 [inline] napi_poll net/core/dev.c:6431 [inline] net/core/dev.c:6518 net_rx_action+0x801/0xb40 net/core/dev.c:6518 net/core/dev.c:6518 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558 kernel/softirq.c:558 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd kernel/softirq.c:921 [inline] kernel/softirq.c:913 run_ksoftirqd+0x2d/0x60 kernel/softirq.c:913 kernel/softirq.c:913 smpboot_thread_fn+0x645/0x9c0 kernel/smpboot.c:164 kernel/smpboot.c:164 kthread+0x405/0x4f0 kernel/kthread.c:327 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 arch/x86/entry/entry_64.S:295 Fixes: 4e66934e ("lib: add reference counting tracking infrastructure") Signed-off-by:
-
Jordy Zomer authored
It appears that there are some buffer overflows in EVT_TRANSACTION. This happens because the length parameters that are passed to memcpy come directly from skb->data and are not guarded in any way. Signed-off-by:
Jordy Zomer <jordy@pwning.systems> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
-
Miroslav Lichvar authored
Don't forget to release the device in sock_timestamping_bind_phc() after it was used to get the vclock indices. Fixes: d463126e ("net: sock: extend SO_TIMESTAMPING for PHC binding") Signed-off-by:
Miroslav Lichvar <mlichvar@redhat.com> Cc: Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by:
-
Michael Walle authored
This reverts commit 9ed319e4. We can already post process a nvmem cell value in a particular driver. Instead of having yet another place to convert the values, the post processing hook of the nvmem provider should be used in this case. Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
-
Colin Ian King authored
Don't populate the read-only const array offsets on the stack but instead make it static. Also makes the object code a little smaller. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220109231716.59012-1-colin.i.king@gmail.comSigned-off-by:
-
Colin Ian King authored
Don't populate the read-only array rset_cmd on the stack but instead it static const. Also makes the object code a little smaller. Signed-off-by:
-
Eric Dumazet authored
While struct tcf_exts has a net pointer, it is not refcounted until tcf_exts_get_net() is called. Fixes: dbdcda63 ("net: sched: add netns refcount tracker to struct tcf_exts") Signed-off-by:
-
Jakub Kicinski authored
Guillaume Nault says: ==================== ipv4: Fix accidental RTO_ONLINK flags passed to ip_route_output_key_hash() The IPv4 stack generally uses the last bit of ->flowi4_tos as a flag indicating link scope for route lookups (RTO_ONLINK). Therefore, we have to be careful when copying a TOS value to ->flowi4_tos. In particular, the ->tos field of IPv4 packets may have this bit set because of ECN. Also tunnel keys generally accept any user value for the tos. This series fixes several places where ->flowi4_tos was set from non-sanitised values and the flowi4 structure was later used by ip_route_output_key_hash(). Note that the IPv4 stack usually clears the RTO_ONLINK bit using RT_TOS(). However this macro is based on an obsolete interpretation of the old IPv4 TOS field (RFC 1349) and clears the three high order bits too. Since we don't need to clear these bits and since it doesn't make sense to clear only one of the ECN bits, this patch series uses INET_ECN_MASK instead. All patches were compile tested only. ==================== Link: https://lore.kernel.org/r/cover.1641821242.git.gnault@redhat.comSigned-off-by:
-
Guillaume Nault authored
Mask the ECN bits before calling mlx5e_route_lookup_ipv4_get(). The tunnel key might have the last ECN bit set. This interferes with the route lookup process as ip_route_output_key_hash() interpretes this bit specially (to restrict the route scope). Found by code inspection, compile tested only. Fixes: c7b9038d ("net/mlx5e: TC preparation refactoring for routing update event") Fixes: 9a941117 ("net/mlx5e: Maximize ip tunnel key usage on the TC offloading path") Signed-off-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
-
Guillaume Nault authored
Mask the ECN bits before calling ip_route_output_ports(). The tos variable might be passed directly from an IPv4 header, so it may have the last ECN bit set. This interferes with the route lookup process as ip_route_output_key_hash() interpretes this bit specially (to restrict the route scope). Found by code inspection, compile tested only. Fixes: 804c2f3e ("libcxgb,iw_cxgb4,cxgbit: add cxgb_find_route()") Signed-off-by:
-
Guillaume Nault authored
Mask the ECN bits before initialising ->flowi4_tos. The tunnel key may have the last ECN bit set, which will interfere with the route lookup process as ip_route_output_key_hash() interpretes this bit specially (to restrict the route scope). Found by code inspection, compile tested only. Fixes: 962924fa ("ip_gre: Refactor collect metatdata mode tunnel xmit to ip_md_tunnel_xmit") Signed-off-by:
-
Guillaume Nault authored
Similar to commit 94e22389 ("xfrm4: strip ECN bits from tos field"), clear the ECN bits from iph->tos when setting ->flowi4_tos. This ensures that the last bit of ->flowi4_tos is cleared, so ip_route_output_key_hash() isn't going to restrict the scope of the route lookup. Use ~INET_ECN_MASK instead of IPTOS_RT_MASK, because we have no reason to clear the high order bits. Found by code inspection, compile tested only. Fixes: 4da3089f ("[IPSEC]: Use TOS when doing tunnel lookups") Signed-off-by:
-
