- 09 Aug, 2019 2 commits
-
-
Jakub Kicinski authored
No error message is currently printed if the pin syscall itself fails. It got lost in the loadall refactoring. Fixes: 77380998 ("bpftool: add loadall command") Reported-by:
Andy Lutomirski <luto@kernel.org> Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
Quentin Monnet <quentin.monnet@netronome.com> Acked-by:
Andrii Nakryiko <andriin@fb.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
-
Jakub Kicinski authored
Change an error message to work for any object being pinned not just programs. Fixes: 71bb428f ("tools: bpf: add bpftool") Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
-
- 01 Aug, 2019 4 commits
-
-
Alexei Starovoitov authored
Add 2 tests that check JIT code generation to jumps to 1st insn. 1st test is similar to syzbot reproducer. The backwards branch is never taken at runtime. 2nd test has branch to 1st insn that executes. The test is written as two bpf functions, since it's not possible to construct valid single bpf program that jumps to 1st insn. Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Song Liu <songliubraving@fb.com>
-
Alexei Starovoitov authored
Introduction of bounded loops exposed old bug in x64 JIT. JIT maintains the array of offsets to the end of all instructions to compute jmp offsets. addrs[0] - offset of the end of the 1st insn (that includes prologue). addrs[1] - offset of the end of the 2nd insn. JIT didn't keep the offset of the beginning of the 1st insn, since classic BPF didn't have backward jumps and valid extended BPF couldn't have a branch to 1st insn, because it didn't allow loops. With bounded loops it's possible to construct a valid program that jumps backwards to the 1st insn. Fix JIT by computing: addrs[0] - offset of the end of prologue == start of the 1st insn. addrs[1] - offset of the end of 1st insn. v1->v2: - Yonghong noticed a bug in jit linfo. Fix it by passing 'addrs + 1' to bpf_prog_fill_jited_linfo(), since it expects insn_to_jit_off array to be offsets to last byte. Reported-by: syzbot+35101610ff3e83119b1b@syzkaller.appspotmail.com Fixes: 2589726d ("bpf: introduce bounded loops") Fixes: 0a14842f ("net: filter: Just In Time compiler for x86-64") Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Song Liu <songliubraving@fb.com>
-
Andrii Nakryiko authored
5d01ab7b ("libbpf: fix erroneous multi-closing of BTF FD") introduced backwards-compatibility issue, manifesting itself as -E2BIG error returned on program load due to unknown non-zero btf_fd attribute value for BPF_PROG_LOAD sys_bpf() sub-command. This patch fixes bug by ensuring that we only ever associate BTF FD with program if there is a BTF.ext data that was successfully loaded into kernel, which automatically means kernel supports func_info/line_info and associated BTF FD for progs (checked and ensured also by BTF sanitization code). Fixes: 5d01ab7b ("libbpf: fix erroneous multi-closing of BTF FD") Reported-by:
Andrey Ignatov <rdna@fb.com> Signed-off-by:
Andrii Nakryiko <andriin@fb.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org>
-
Takshak Chahande authored
Having static variable `cpus` in libbpf_num_possible_cpus function without guarding it with mutex makes this function thread-unsafe. If multiple threads accessing this function, in the current form; it leads to incrementing the static variable value `cpus` in the multiple of total available CPUs. Used local stack variable to calculate the number of possible CPUs and then updated the static variable using WRITE_ONCE(). Changes since v1: * added stack variable to calculate cpus * serialized static variable update using WRITE_ONCE() * fixed Fixes tag Fixes: 6446b315 ("bpf: add a new API libbpf_num_possible_cpus()") Signed-off-by:
Takshak Chahande <ctakshak@fb.com> Acked-by:
Andrey Ignatov <rdna@fb.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org>
-
- 27 Jul, 2019 1 commit
-
-
Andrii Nakryiko authored
Libbpf stores associated BTF FD per each instance of bpf_program. When program is unloaded, that FD is closed. This is wrong, because leads to a race and possibly closing of unrelated files, if application simultaneously opens new files while bpf_programs are unloaded. It's also unnecessary, because struct btf "owns" that FD, and btf__free(), called from bpf_object__close() will close it. Thus the fix is to never have per-program BTF FD and fetch it from obj->btf, when necessary. Fixes: 2993e051 ("tools/bpf: add support to read .BTF.ext sections") Reported-by:
Andrey Ignatov <rdna@fb.com> Signed-off-by:
Andrii Nakryiko <andriin@fb.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org>
-
- 26 Jul, 2019 10 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== Mellanox, mlx5 fixes 2019-07-25 This series introduces some fixes to mlx5 driver. 1) Ariel is addressing an issue with enacp flow counter race condition 2) Aya fixes ethtool speed handling 3) Edward fixes modify_cq hw bits alignment 4) Maor fixes RDMA_RX capabilities handling 5) Mark reverses unregister devices order to address an issue with LAG 6) From Tariq, - wrong max num channels indication regression - TLS counters naming and documentation as suggested by Jakub - kTLS, Call WARN_ONCE on netdev mismatch There is one patch in this series that touches nfp driver to align TLS statistics names with latest documentation, Jakub is CC'ed. Please pull and let me know if there is any problem. For -stable v4.9: ('net/mlx5: Use reversed order when unregister devices') For -stable v4.20 ('net/mlx5e: Prevent encap flow counter update async to user query') ('net/mlx5: Fix modify_cq_in alignment') For -stable v5.1 ('net/mlx5e: Fix matching of speed to PRM link modes') For -stable v5.2 ('net/mlx5: Add missing RDMA_RX capabilities') ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Subash Abhinov Kasiviswanathan authored
The udp_ip4_ind bit is set only for IPv4 UDP non-fragmented packets so that the hardware can flip the checksum to 0xFFFF if the computed checksum is 0 per RFC768. However, this bit had to be set for IPv6 UDP non fragmented packets as well per hardware requirements. Otherwise, IPv6 UDP packets with computed checksum as 0 were transmitted by hardware and were dropped in the network. In addition to setting this bit for IPv6 UDP, the field is also appropriately renamed to udp_ind as part of this change. Fixes: 5eb5f860 ("net: qualcomm: rmnet: Add support for TX checksum offload") Cc: Sean Tranchetti <stranche@codeaurora.org> Signed-off-by:
Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Haishuang Yan authored
ip4ip6/ip6ip6 tunnels run iptunnel_handle_offloads on xmit which can cause a possible use-after-free accessing iph/ipv6h pointer since the packet will be 'uncloned' running pskb_expand_head if it is a cloned gso skb. Fixes: 0e9a7095 ("ip6_tunnel, ip6_gre: fix setting of DSCP on encapsulated packets") Signed-off-by:
Haishuang Yan <yanhaishuang@cmss.chinamobile.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Claudiu Manoil authored
Make sure the delayed work for stats update is not pending before wq destruction. This fixes the module unload path. The issue is there since day 1. Fixes: a556c76a ("net: mscc: Add initial Ocelot switch support") Signed-off-by:
Claudiu Manoil <claudiu.manoil@nxp.com> Reviewed-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Michal Kalderon authored
The hw_ver field was initialized to zero. Return the chip revision. This is relevant for rdma driver. Signed-off-by:
Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bob Ham authored
The BroadMobi BM818 M.2 card uses the QMI protocol Signed-off-by:
Bob Ham <bob.ham@puri.sm> Signed-off-by:
Angus Ainslie (Purism) <angus@akkea.ca> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller authored
Alexei Starovoitov says: ==================== pull-request: bpf 2019-07-25 The following pull-request contains BPF updates for your *net* tree. The main changes are: 1) fix segfault in libbpf, from Andrii. 2) fix gso_segs access, from Eric. 3) tls/sockmap fixes, from Jakub and John. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Haishuang Yan authored
We need the same checks introduced by commit cb9f1b78 ("ip: validate header length on virtual device xmit") for ipip tunnel. Fixes: cb9f1b78 ("ip: validate header length on virtual device xmit") Signed-off-by:
Haishuang Yan <yanhaishuang@cmss.chinamobile.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
ipv6_flowlabel and ipv6_flowlabel_mgr are missing from gitignore. Quentin points out that the original commit 3fb321fd ("selftests/net: ipv6 flowlabel") did add ignore entries, they are just missing the "ipv6_" prefix. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
Quentin Monnet <quentin.monnet@netronome.com> Acked-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sudarsana Reddy Kalluru authored
Commit 3968d389 ("bnx2x: Fix Multi-Cos.") which enabled multi-cos feature after prolonged time in driver added some regression causing numerous issues (sudden reboots, tx timeout etc.) reported by customers. We plan to backout this commit and submit proper fix once we have root cause of issues reported with this feature enabled. Fixes: 3968d389 ("bnx2x: Fix Multi-Cos.") Signed-off-by:
Sudarsana Reddy Kalluru <skalluru@marvell.com> Signed-off-by:
Manish Chopra <manishc@marvell.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 25 Jul, 2019 18 commits
-
-
Tariq Toukan authored
Add missing description of counters. Split tx_tls_encrypted counter into two, to give packets and bytes indications. Fixes: f42c104f ("Documentation: add TLS offload documentation") Suggested-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com>
-
Tariq Toukan authored
Align to the naming convention in TLS documentation. Fixes: 51a5e563 ("nfp: tls: add basic statistics") Suggested-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com>
-
Tariq Toukan authored
A netdev mismatch in the processed TLS SKB should not occur, and indicates a kernel bug. Add WARN_ONCE to spot such cases. Fixes: d2ead1f3 ("net/mlx5e: Add kTLS TX HW offload support") Suggested-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com>
-
Ariel Levkovich authored
This patch prevents a race between user invoked cached counters query and a neighbor last usage updater. The cached flow counter stats can be queried by calling "mlx5_fc_query_cached" which provides the number of bytes and packets that passed via this flow since the last time this counter was queried. It does so by reducting the last saved stats from the current, cached stats and then updating the last saved stats with the cached stats. It also provide the lastuse value for that flow. Since "mlx5e_tc_update_neigh_used_value" needs to retrieve the last usage time of encapsulation flows, it calls the flow counter query method periodically and async to user queries of the flow counter using cls_flower. This call is causing the driver to update the last reported bytes and packets from the cache and therefore, future user queries of the flow stats will return lower than expected number for bytes and packets since the last saved stats in the driver was updated async to the last saved stats in cls_flower. This causes wrong stats presentation of encapsulation flows to user. Since the neighbor usage updater only needs the lastuse stats from the cached counter, the fix is to use a dedicated lastuse query call that returns the lastuse value without synching between the cached stats and the last saved stats. Fixes: f6dfb4c3 ("net/mlx5e: Update neighbour 'used' state using HW flow rules counters") Signed-off-by:
Ariel Levkovich <lariel@mellanox.com> Reviewed-by:
Roi Dayan <roid@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com>
-
Aya Levin authored
Speed translation is performed based on legacy or extended PTYS register. Translate speed with respect to: 1) Capability bit of extended PTYS table. 2) User request: a) When auto-negotiation is turned on, inspect advertisement whether it contains extended link modes. b) When auto-negotiation is turned off, speed > 100Gbps (maximal speed supported in legacy mode). With both conditions fulfilled translation is done with extended PTYS table otherwise use legacy PTYS table. Without this patch 25/50/100 Gbps speed cannot be set, since try to configure in extended mode but read from legacy mode. Fixes: dd1b9e09 ("net/mlx5: ethtool, Allow legacy link-modes configuration via non-extended ptys") Signed-off-by:
Aya Levin <ayal@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com>
-
Tariq Toukan authored
No XSK support in the enhanced IPoIB driver and representors. Add a profile property to specify this, and enhance the logic that calculates the max number of channels to take it into account. Fixes: db05815b ("net/mlx5e: Add XSK zero-copy support") Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com>
-
Edward Srouji authored
Fix modify_cq_in alignment to match the device specification. After this fix the 'cq_umem_valid' field will be in the right offset. Cc: <stable@vger.kernel.org> # 4.19 Fixes: bd371975 ("net/mlx5: Update mlx5_ifc with DEVX UID bits") Signed-off-by:
Edward Srouji <edwards@mellanox.com> Reviewed-by:
Yishai Hadas <yishaih@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com>
-
Maor Gottlieb authored
New flow table type RDMA_RX was added but the MLX5_CAP_FLOW_TABLE_TYPE didn't handle this new flow table type. This means that MLX5_CAP_FLOW_TABLE_TYPE returns an empty capability to this flow table type. Update both the macro and the maximum supported flow table type to RDMA_RX. Fixes: d83eb50e ("net/mlx5: Add support in RDMA RX steering") Signed-off-by:
Maor Gottlieb <maorg@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com>
-
Mark Zhang authored
When lag is active, which is controlled by the bonded mlx5e netdev, mlx5 interface unregestering must happen in the reverse order where rdma is unregistered (unloaded) first, to guarantee all references to the lag context in hardware is removed, then remove mlx5e netdev interface which will cleanup the lag context from hardware. Without this fix during destroy of LAG interface, we observed following errors: * mlx5_cmd_check:752:(pid 12556): DESTROY_LAG(0x843) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0xe4ac33) * mlx5_cmd_check:752:(pid 12556): DESTROY_LAG(0x843) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0xa5aee8). Fixes: a31208b1 ("net/mlx5_core: New init and exit flow for mlx5_core") Reviewed-by:
Parav Pandit <parav@mellanox.com> Reviewed-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Mark Zhang <markz@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com>
-
Chris Packham authored
fm_set_max_frm() existed in the Freescale SDK as a callback for an early_param. When this code was ported to the upstream kernel the early_param was converted to a module_param making the reference to the function incorrect. The rest of the comment already does a good job of explaining the parameter so removing the reference to the non-existent function seems like the best thing to do. Signed-off-by:
Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Navid Emamdoost authored
devm_kzalloc may fail and return NULL. So the null check is needed. Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Navid Emamdoost authored
devm_kzalloc may fail and return null. So the null check is needed. Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Alexis Bauvin authored
- v1 -> v2: Move skb_set_owner_w to __tun_build_skb to reduce patch size Small packets going out of a tap device go through an optimized code path that uses build_skb() rather than sock_alloc_send_pskb(). The latter calls skb_set_owner_w(), but the small packet code path does not. The net effect is that small packets are not owned by the userland application's socket (e.g. QEMU), while large packets are. This can be seen with a TCP session, where packets are not owned when the window size is small enough (around PAGE_SIZE), while they are once the window grows (note that this requires the host to support virtio tso for the guest to offload segmentation). All this leads to inconsistent behaviour in the kernel, especially on netfilter modules that uses sk->socket (e.g. xt_owner). Fixes: 66ccbc9c ("tap: use build_skb() for small packet") Signed-off-by:
Alexis Bauvin <abauvin@scaleway.com> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Leon Romanovsky says: ==================== DIM fixes for 5.3 Those two fixes for recently merged DIM patches, both exposed through RDMa DIM usage. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
DIM causes to the following warnings during kernel compilation which indicates that tx_profile and rx_profile are supposed to be declared in *.c and not in *.h files. In file included from ./include/rdma/ib_verbs.h:64, from ./include/linux/mlx5/device.h:37, from ./include/linux/mlx5/driver.h:51, from ./include/linux/mlx5/vport.h:36, from drivers/infiniband/hw/mlx5/ib_virt.c:34: ./include/linux/dim.h:326:1: warning: _tx_profile_ defined but not used [-Wunused-const-variable=] 326 | tx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = { | ^~~~~~~~~~ ./include/linux/dim.h:320:1: warning: _rx_profile_ defined but not used [-Wunused-const-variable=] 320 | rx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = { | ^~~~~~~~~~ Fixes: 4f75da36 ("linux/dim: Move implementation to .c files") Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Acked-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Yamin Friedman authored
While using net_dim, a dim_sample was used without ever initializing the comps value. Added use of DIV_ROUND_DOWN_ULL() to prevent potential overflow, it should not be a problem to save the final result in an int because after the division by epms the value should not be larger than a few thousand. [ 1040.127124] UBSAN: Undefined behaviour in lib/dim/dim.c:78:23 [ 1040.130118] signed integer overflow: [ 1040.131643] 134718714 * 100 cannot be represented in type 'int' Fixes: 398c2b05 ("linux/dim: Add completions count to dim_sample") Signed-off-by:
Yamin Friedman <yaminf@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Acked-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Cong Wang authored
act_ife at least requires TCA_IFE_PARMS, so we have to bail out when there is no attribute passed in. Reported-by: syzbot+fbb5b288c9cb6a2eeac4@syzkaller.appspotmail.com Fixes: ef6980b6 ("introduce IFE action") Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Andrii Nakryiko authored
Despite a proper NULL-termination after strncpy(..., ..., IFNAMSIZ - 1), GCC8 still complains about *expected* string truncation: xsk.c:330:2: error: 'strncpy' output may be truncated copying 15 bytes from a string of length 15 [-Werror=stringop-truncation] strncpy(ifr.ifr_name, xsk->ifname, IFNAMSIZ - 1); This patch gets rid of the issue altogether by using memcpy instead. There is no performance regression, as strncpy will still copy and fill all of the bytes anyway. v1->v2: - rebase against bpf tree. Cc: Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by:
Andrii Nakryiko <andriin@fb.com> Acked-by:
Magnus Karlsson <magnus.karlsson@intel.com> Acked-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org>
-
- 24 Jul, 2019 5 commits
-
-
Cong Wang authored
sock_efree() releases the sock refcnt, if we don't hold this refcnt when setting skb->destructor to it, the refcnt would not be balanced. This leads to several bug reports from syzbot. I have checked other users of sock_efree(), all of them hold the sock refcnt. Fixes: c8c8218e ("netrom: fix a memory leak in nr_rx_frame()") Reported-and-tested-by: <syzbot+622bdabb128acc33427d@syzkaller.appspotmail.com> Reported-and-tested-by: <syzbot+6eaef7158b19e3fec3a0@syzkaller.appspotmail.com> Reported-and-tested-by: <syzbot+9399c158fcc09b21d0d2@syzkaller.appspotmail.com> Reported-and-tested-by: <syzbot+a34e5f3d0300163f0c87@syzkaller.appspotmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arnd Bergmann authored
Some functions in the datapath code are factored out so that each one has a stack frame smaller than 1024 bytes with gcc. However, when compiling with clang, the functions are inlined more aggressively and combined again so we get net/openvswitch/datapath.c:1124:12: error: stack frame size of 1528 bytes in function 'ovs_flow_cmd_set' [-Werror,-Wframe-larger-than=] Marking both get_flow_actions() and ovs_nla_init_match_and_action() as 'noinline_for_stack' gives us the same behavior that we see with gcc, and no warning. Note that this does not mean we actually use less stack, as the functions call each other, and we still get three copies of the large 'struct sw_flow_key' type on the stack. The comment tells us that this was previously considered safe, presumably since the netlink parsing functions are called with a known backchain that does not also use a lot of stack space. Fixes: 9cc9a5cb ("datapath: Avoid using stack larger than 1024.") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
I've been spending quite a bit of time fixing and preventing bit rot in the core TLS code. TLS seems to only be growing in importance, I'd like to help ensuring the quality of our implementation. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
John Fastabend <john.fastabend@gmail.com> Acked-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Andreas Schwab authored
The memory allocated for the stats array may contain arbitrary data. Fixes: e4f9ba64 ("net: phy: mscc: add support for VSC8514 PHY.") Fixes: 00d70d8e ("net: phy: mscc: add support for VSC8574 PHY") Fixes: a5afc167 ("net: phy: mscc: add support for VSC8584 PHY") Fixes: f76178dc ("net: phy: mscc: add ethtool statistics counters") Signed-off-by:
Andreas Schwab <schwab@suse.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arseny Solokha authored
SFP modules connected using the SGMII interface have their own PHYs which are handled by the struct phylink's phydev field. On the other hand, for the modules connected using 1000Base-X interface that field is not set. Since commit ce0aa27f ("sfp: add sfp-bus to bridge between network devices and sfp cages") phylink_start() ends up setting the phydev field using the sfp-bus infrastructure, which eventually calls phy_start() on it, and then calling phy_start() again on the same phydev from phylink_start() itself. Similar call sequence holds for phylink_stop(), only in the reverse order. This results in WARNs during network interface bringup and shutdown when a copper SFP module is connected, as phy_start() and phy_stop() are called twice in a row for the same phy_device: % ip link set up dev eth0 ------------[ cut here ]------------ called from state UP WARNING: CPU: 1 PID: 155 at drivers/net/phy/phy.c:895 phy_start+0x74/0xc0 Modules linked in: CPU: 1 PID: 155 Comm: backend Not tainted 5.2.0+ #1 NIP: c0227bf0 LR: c0227bf0 CTR: c004d224 REGS: df547720 TRAP: 0700 Not tainted (5.2.0+) MSR: 00029000 <CE,EE,ME> CR: 24002822 XER: 00000000 GPR00: c0227bf0 df5477d8 df5d7080 00000014 df9d2370 df9d5ac4 1f4eb000 00000001 GPR08: c061fe58 00000000 00000000 df5477d8 0000003c 100c8768 00000000 00000000 GPR16: df486a00 c046f1c8 c046eea0 00000000 c046e904 c0239604 db68449c 00000000 GPR24: e9083204 00000000 00000001 db684460 e9083404 00000000 db6dce00 db6dcc00 NIP [c0227bf0] phy_start+0x74/0xc0 LR [c0227bf0] phy_start+0x74/0xc0 Call Trace: [df5477d8] [c0227bf0] phy_start+0x74/0xc0 (unreliable) [df5477e8] [c023cad0] startup_gfar+0x398/0x3f4 [df547828] [c023cf08] gfar_enet_open+0x364/0x374 [df547898] [c029d870] __dev_open+0xe4/0x140 [df5478c8] [c029db70] __dev_change_flags+0xf0/0x188 [df5478f8] [c029dc28] dev_change_flags+0x20/0x54 [df547918] [c02ae304] do_setlink+0x310/0x818 [df547a08] [c02b1eb8] __rtnl_newlink+0x384/0x6b0 [df547c28] [c02b222c] rtnl_newlink+0x48/0x68 [df547c48] [c02ad7c8] rtnetlink_rcv_msg+0x240/0x27c [df547c98] [c02cc068] netlink_rcv_skb+0x8c/0xf0 [df547cd8] [c02cba3c] netlink_unicast+0x114/0x19c [df547d08] [c02cbd74] netlink_sendmsg+0x2b0/0x2c0 [df547d58] [c027b668] sock_sendmsg_nosec+0x20/0x40 [df547d68] [c027d080] ___sys_sendmsg+0x17c/0x1dc [df547e98] [c027df7c] __sys_sendmsg+0x68/0x84 [df547ef8] [c027e430] sys_socketcall+0x1a0/0x204 [df547f38] [c000d1d8] ret_from_syscall+0x0/0x38 --- interrupt: c01 at 0xfd4e030 LR = 0xfd4e010 Instruction dump: 813f0188 38800000 2b890005 419d0014 3d40c046 5529103a 394aa208 7c8a482e 3c60c046 3863a1b8 4cc63182 4be009a1 <0fe00000> 48000030 3c60c046 3863a1d0 ---[ end trace d4c095aeaf6ea998 ]--- and % ip link set down dev eth0 ------------[ cut here ]------------ called from state HALTED WARNING: CPU: 1 PID: 184 at drivers/net/phy/phy.c:858 phy_stop+0x3c/0x88 <...> Call Trace: [df581788] [c0228450] phy_stop+0x3c/0x88 (unreliable) [df581798] [c022d548] sfp_sm_phy_detach+0x1c/0x44 [df5817a8] [c022e8cc] sfp_sm_event+0x4b0/0x87c [df581848] [c022f04c] sfp_upstream_stop+0x34/0x44 [df581858] [c0225608] phylink_stop+0x7c/0xe4 [df581868] [c023c57c] stop_gfar+0x7c/0x94 [df581888] [c023c5b8] gfar_close+0x24/0x94 [df5818a8] [c0298688] __dev_close_many+0xdc/0xf8 [df5818c8] [c029db58] __dev_change_flags+0xd8/0x188 [df5818f8] [c029dc28] dev_change_flags+0x20/0x54 [df581918] [c02ae304] do_setlink+0x310/0x818 [df581a08] [c02b1eb8] __rtnl_newlink+0x384/0x6b0 [df581c28] [c02b222c] rtnl_newlink+0x48/0x68 [df581c48] [c02ad7c8] rtnetlink_rcv_msg+0x240/0x27c [df581c98] [c02cc068] netlink_rcv_skb+0x8c/0xf0 [df581cd8] [c02cba3c] netlink_unicast+0x114/0x19c [df581d08] [c02cbd74] netlink_sendmsg+0x2b0/0x2c0 [df581d58] [c027b668] sock_sendmsg_nosec+0x20/0x40 [df581d68] [c027d080] ___sys_sendmsg+0x17c/0x1dc [df581e98] [c027df7c] __sys_sendmsg+0x68/0x84 [df581ef8] [c027e430] sys_socketcall+0x1a0/0x204 [df581f38] [c000d1d8] ret_from_syscall+0x0/0x38 <...> ---[ end trace d4c095aeaf6ea999 ]--- SFP modules with the 1000Base-X interface are not affected. Place explicit calls to phy_start() and phy_stop() before enabling or after disabling an attached SFP module, where phydev is not yet set (or is already unset), so they will be made only from the inside of sfp-bus, if needed. Fixes: 21796261 ("net: phy: warn if phy_start is called from invalid state") Signed-off-by:
Arseny Solokha <asolokha@kb.kras.ru> Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-