- 26 Jul, 2021 4 commits
-
-
Yufeng Mo authored
Add devlink get info support for HNS3 ethernet PF driver. Signed-off-by:
Yufeng Mo <moyufeng@huawei.com> Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Yufeng Mo authored
Add devlink register support for HNS3 ethernet VF driver. Signed-off-by:
-
Yufeng Mo authored
Add devlink register support for HNS3 ethernet PF driver. Signed-off-by:
-
Hao Chen authored
Add a file to document devlink support for hns3 driver, now support devlink info and devlink reload. Signed-off-by:
Hao Chen <chenhao288@hisilicon.com> Signed-off-by:
-
- 25 Jul, 2021 14 commits
-
-
Xin Long authored
syzbot reported an use-after-free crash: BUG: KASAN: use-after-free in tipc_recvmsg+0xf77/0xf90 net/tipc/socket.c:1979 Call Trace: tipc_recvmsg+0xf77/0xf90 net/tipc/socket.c:1979 sock_recvmsg_nosec net/socket.c:943 [inline] sock_recvmsg net/socket.c:961 [inline] sock_recvmsg+0xca/0x110 net/socket.c:957 tipc_conn_rcv_from_sock+0x162/0x2f0 net/tipc/topsrv.c:398 tipc_conn_recv_work+0xeb/0x190 net/tipc/topsrv.c:421 process_one_work+0x98d/0x1630 kernel/workqueue.c:2276 worker_thread+0x658/0x11f0 kernel/workqueue.c:2422 As Hoang pointed out, it was caused by skb_cb->bytes_read still accessed after calling tsk_advance_rx_queue() to free the skb in tipc_recvmsg(). This patch is to fix it by accessing skb_cb->bytes_read earlier than calling tsk_advance_rx_queue(). Fixes: f4919ff5 ("tipc: keep the skb in rcv queue until the whole data is read") Reported-by: syzbot+e6741b97d5552f97c24d@syzkaller.appspotmail.com Signed-off-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
Jon Maloy <jmaloy@redhat.com> Signed-off-by:
-
David S. Miller authored
Krzysztof Kozlowski says: ==================== nfc: constify data structures Constify pointers to several data structures which are not modified by NFC core or by drivers to make it slightly safer. No functional impact expected. ==================== Signed-off-by: -
Krzysztof Kozlowski authored
Neither the core nor the drivers modify the passed pointer to struct nfc_digital_ops, so make it a pointer to const for correctness and safety. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
-
Krzysztof Kozlowski authored
Neither the core nor the drivers modify the passed pointer to struct nfc_llc_ops, so make it a pointer to const for correctness and safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Neither the core nor the drivers modify the passed pointer to struct nfc_hci_ops, so make it a pointer to const for correctness and safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Neither the core nor the drivers modify the passed pointer to struct nfc_ops, so make it a pointer to const for correctness and safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Neither the core nor the drivers modify the passed pointer to struct nfc_hci_gate, so make it a pointer to const for correctness and safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Neither the core nor the drivers modify the passed pointer to struct nfc_vendor_cmd, so make it a pointer to const for correctness and safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Driver only reads len_seq and wait_tab variables. Signed-off-by:
-
Krzysztof Kozlowski authored
Neither the core nor the drivers modify the passed pointer to struct nfc_phy_ops (consisting of function pointers), so make it a pointer to const for correctness and safety. Signed-off-by:
-
Krzysztof Kozlowski authored
Neither the core nor the drivers modify the passed pointer to struct nci_driver_ops (consisting of function pointers), so make it a pointer to const for correctness and safety. Signed-off-by:
-
Krzysztof Kozlowski authored
s3fwrn5 driver modifies static struct nci_ops only to set prop_ops. Since prop_ops is build time constant with known size, it can be made const. This allows to removeo the function setting the prop_ops - s3fwrn5_nci_get_prop_ops(). Signed-off-by:
-
Krzysztof Kozlowski authored
The struct nci_ops is modified by NFC core in only one case: nci_allocate_device() receives too many proprietary commands (prop_ops) to configure. This is a build time known constrain, so a graceful handling of such case is not necessary. Instead, fail the nci_allocate_device() and add BUILD_BUG_ON() to places which set these. This allows to constify the struct nci_ops (consisting of function pointers) for correctness and safety. Signed-off-by:
-
Krzysztof Kozlowski authored
The nci_send_cmd() payload argument is passed directly to skb_put_data() which already accepts a pointer to const, so make it const as well for correctness and safety. Signed-off-by:
-
- 24 Jul, 2021 1 commit
-
-
Vladimir Oltean authored
Switchdev support can be disabled at compile time, and in that case, struct sk_buff will not contain the offload_fwd_mark field. To make the code in br_forward.c work in both cases, we do what is done in other places and we create a helper function, with an empty shim definition, that is implemented by the br_switchdev.o translation module. This is always compiled if and only if CONFIG_NET_SWITCHDEV is y or m. Reported-by:
kernel test robot <lkp@intel.com> Fixes: 47211192 ("net: bridge: switchdev: allow the TX data plane forwarding to be offloaded") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
- 23 Jul, 2021 21 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
Tony Nguyen says: ==================== 1GbE Intel Wired LAN Driver Updates 2021-07-23 This series contains updates to igb and e100 drivers. Grzegorz adds a timeout check to prevent possible infinite loop for igb. Kees Cook adjusts memcpy() argument to represent the entire structure to allow for appropriate bounds checking for igb and e100. ==================== Signed-off-by: -
chongjiapeng authored
Eliminate the follow versioncheck warning: ./drivers/net/phy/mxl-gpy.c: 9 linux/version.h not needed. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
chongjiapeng <jiapeng.chong@linux.alibaba.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Krzysztof Kozlowski authored
File-scope "port100_protocol" array is read-only and passed as pointer to const, so it can be made a const to increase code safety. Signed-off-by:
-
Kangmin Park authored
Defer ttl decrement to optimize in tx_err case. There is no need to decrease ttl in the case of goto tx_err. Signed-off-by:
Kangmin Park <l4stpr0gr4m@gmail.com> Signed-off-by:
-
Loic Poulain authored
A wwan link created via the wwan_create_default_link procedure is never notified to the user (RTM_NEWLINK), causing issues with user tools relying on such event to track network links (NetworkManager). This is because the procedure misses a call to rtnl_configure_link(), which sets the link as initialized and notifies the new link (cf proper usage in __rtnl_newlink()). Cc: stable@vger.kernel.org Fixes: ca374290 ("wwan: core: support default netdev creation") Suggested-by:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Acked-by:
-
Jerin Jacob authored
Added mailbox id to name translation on trace entry for better tracing output. Before the change: otx2_msg_process: [0002:01:00.0] msg:(0x03) error:0 After the change: otx2_msg_process: [0002:01:00.0] msg:(DETACH_RESOURCES) error:0 Signed-off-by:
Jerin Jacob <jerinj@marvell.com> Signed-off-by:
-
Kees Cook authored
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally reading across neighboring array fields. The memcpy() is copying the entire structure, not just the first array. Adjust the source argument so the compiler can do appropriate bounds checking. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Kees Cook authored
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally reading across neighboring array fields. The memcpy() is copying the entire structure, not just the first array. Adjust the source argument so the compiler can do appropriate bounds checking. Signed-off-by:
Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by:
-
Grzegorz Siwik authored
Add failed_counter to i21x_doublecheck(). There is possibility that loop will never end. With this patch the loop will stop after maximum 3 retries to write to MTA_REGISTER Signed-off-by:
Grzegorz Siwik <grzegorz.siwik@intel.com> Tested-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Allow TX forwarding for the software bridge data path to be offloaded to capable devices On RX, switchdev drivers have the ability to mark packets for the software bridge as "already forwarded in hardware" via skb->offload_fwd_mark. This instructs the nbp_switchdev_allowed_egress() function to perform software forwarding of that packet only to the bridge ports that are not in the same hardware domain as the source packet. This series expands the concept for TX, in the sense that we can trust the accelerator to: (a) look up its FDB (which is more or less in sync with the software bridge FDB) for selecting the destination ports for a packet (b) replicate the frame in hardware in case it's a multicast/broadcast, instead of the software bridge having to clone it and send the clones to each net device one at a time. This reduces the bandwidth needed between the CPU and the accelerator, as well as the CPU time spent. This is done by augmenting nbp_switchdev_allowed_egress() to also exclude the bridge ports which have the tx_fwd_offload capability if the skb has already been transmitted to one port from their hardware domain. Even though in reality, the software bridge still technically looks up the FDB/MDB for every frame, but all skb clones are suppressed, this offload specifically requires that the switchdev accelerator looks up its FDB/MDB again. It is intended to be used to inject "data plane packets" into the hardware as opposed to "control plane packets" which target a precise destination port. Towards that goal, the bridge always provides the TX packets with skb->offload_fwd_mark = true with the VLAN tag always present, so that the accelerator can forward according to that VLAN broadcast domain. This work is not intended to cater to switches which can inject control plane packets to a bit mask of destination ports. I see that as a more difficult task to accomplish with potentially less benefits (it provides only replication offload). The reason it is more difficult is that struct skb_buff would probably need to be extended to contain a list of struct net_devices that the packet must be replicated to. Sending data plane packets avoids that issue by keeping the hardware and software FDB more or less in sync and looking it up twice. Additionally, the ability for the software bridge to request data plane packets to be sent brings the opportunity for "dumb switches" to support traffic termination to/from the bridge. Such switches (DSA or otherwise) typically only use control packets for link-local traps, and sending or receiving a control packet is an expensive operation. For this class of switches, this patch series makes the difference between supporting and not supporting local IP termination through a VLAN-aware bridge, bridging with a foreign interface, bridging with software upper interfaces like LAG, etc. So instead of telling them "oh, what a dumb switch you are!", we can now tell them "oh, what a stark contrast you have between the control and data plane!". Patches 1-3 tested on Turris MOX (3 mv88e6xxx switches in a daisy chain topology) and a second DSA driver to be added soon. Patches 4-5 tested only on Turris MOX. =========================================================== Changes in v5: - make sure the static key is decremented on bridge port unoffload - rename functions and variables so that the "tx_fwd_offload" string is easy to grep across the git tree - simplify DSA core bookkeeping of the bridge_num =========================================================== Changes in v4: The biggest change compared to the previous series is not present in the patches, but is rather a lack of them. Previously we were replaying switchdev objects on the public notifier chain, but that was a mistake in my reasoning and it was reverted for v4. Therefore, we are now passing the notifier blocks as arguments to switchdev_bridge_port_offload() for all drivers. This alone gets rid of 7 patches compared to v3. Other changes are: - Take more care for the case where mlxsw leaves a VLAN or LAG upper that is a bridge port, make sure that switchdev_bridge_port_unoffload() gets called for that case - A couple of DSA bug fixes - Add change logs for all patches - Copy all switchdev driver maintainers on the changes relevant to them =========================================================== Message for v3: https://patchwork.kernel.org/project/netdevbpf/cover/20210712152142.800651-1-vladimir.oltean@nxp.com/ In this submission I have introduced a "native switchdev" driver API to signal whether the TX forwarding offload is supported or not. This comes after a third person has said that the macvlan offload framework used for v2 and v1 was simply too convoluted. This large patch set is submitted for discussion purposes (it is provided in its entirety so it can be applied & tested on net-next). It is only minimally tested, and yet I will not copy all switchdev driver maintainers until we agree on the viability of this approach. The major changes compared to v2: - The introduction of switchdev_bridge_port_offload() and switchdev_bridge_port_unoffload() as two major API changes from the perspective of a switchdev driver. All drivers were converted to call these. - Augment switchdev_bridge_port_{,un}offload to also handle the switchdev object replays on port join/leave. - Augment switchdev_bridge_port_offload to also signal whether the TX forwarding offload is supported. =========================================================== Message for v2: https://patchwork.kernel.org/project/netdevbpf/cover/20210703115705.1034112-1-vladimir.oltean@nxp.com/ For this series I have taken Tobias' work from here: https://patchwork.kernel.org/project/netdevbpf/cover/20210426170411.1789186-1-tobias@waldekranz.com/ and made the following changes: - I collected and integrated (hopefully all of) Nikolay's, Ido's and my feedback on the bridge driver changes. Otherwise, the structure of the bridge changes is pretty much the same as Tobias left it. - I basically rewrote the DSA infrastructure for the data plane forwarding offload, based on the commonalities with another switch driver for which I implemented this feature (not submitted here) - I adapted mv88e6xxx to use the new infrastructure, hopefully it still works but I didn't test that ==================== Signed-off-by: -
Tobias Waldekranz authored
Allow the DSA tagger to generate FORWARD frames for offloaded skbs sent from a bridge that we offload, allowing the switch to handle any frame replication that may be required. This also means that source address learning takes place on packets sent from the CPU, meaning that return traffic no longer needs to be flooded as unknown unicast. Signed-off-by:
Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by:
-
Vladimir Oltean authored
The mv88e6xxx switches have the ability to receive FORWARD (data plane) frames from the CPU port and route them according to the FDB. We can use this to offload the forwarding process of packets sent by the software bridge. Because DSA supports bridge domain isolation between user ports, just sending FORWARD frames is not enough, as they might leak the intended broadcast domain of the bridge on behalf of which the packets are sent. It should be noted that FORWARD frames are also (and typically) used to forward data plane packets on DSA links in cross-chip topologies. The FORWARD frame header contains the source port and switch ID, and switches receiving this frame header forward the packet according to their cross-chip port-based VLAN table (PVT). To address the bridging domain isolation in the context of offloading the forwarding on TX, the idea is that we can reuse the parts of the PVT that don't have any physical switch mapped to them, one entry for each software bridge. The switches will therefore think that behind their upstream port lie many switches, all in fact backed up by software bridges through tag_dsa.c, which constructs FORWARD packets with the right switch ID corresponding to each bridge. The mapping we use is absolutely trivial: DSA gives us a unique bridge number, and we add the number of the physical switches in the DSA switch tree to that, to obtain a unique virtual bridge device number to use in the PVT. Co-developed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
For a DSA switch, to offload the forwarding process of a bridge device means to send the packets coming from the software bridge as data plane packets. This is contrary to everything that DSA has done so far, because the current taggers only know to send control packets (ones that target a specific destination port), whereas data plane packets are supposed to be forwarded according to the FDB lookup, much like packets ingressing on any regular ingress port. If the FDB lookup process returns multiple destination ports (flooding, multicast), then replication is also handled by the switch hardware - the bridge only sends a single packet and avoids the skb_clone(). DSA keeps for each bridge port a zero-based index (the number of the bridge). Multiple ports performing TX forwarding offload to the same bridge have the same dp->bridge_num value, and ports not offloading the TX data plane of a bridge have dp->bridge_num = -1. The tagger can check if the packet that is being transmitted on has skb->offload_fwd_mark = true or not. If it does, it can be sure that the packet belongs to the data plane of a bridge, further information about which can be obtained based on dp->bridge_dev and dp->bridge_num. It can then compose a DSA tag for injecting a data plane packet into that bridge number. For the switch driver side, we offer two new dsa_switch_ops methods, called .port_bridge_fwd_offload_{add,del}, which are modeled after .port_bridge_{join,leave}. These methods are provided in case the driver needs to configure the hardware to treat packets coming from that bridge software interface as data plane packets. The switchdev <-> bridge interaction happens during the netdev_master_upper_dev_link() call, so to switch drivers, the effect is that the .port_bridge_fwd_offload_add() method is called immediately after .port_bridge_join(). If the bridge number exceeds the number of bridges for which the switch driver can offload the TX data plane (and this includes the case where the driver can offload none), DSA falls back to simply returning tx_fwd_offload = false in the switchdev_bridge_port_offload() call. Signed-off-by: -
Vladimir Oltean authored
In preparation of supporting data plane forwarding on behalf of a software bridge, some drivers might need to view bridges as virtual switches behind the CPU port in a cross-chip topology. Give them some help and let them know how many physical switches there are in the tree, so that they can count the virtual switches starting from that number on. Note that the first dsa_switch_ops method where this information is reliably available is .setup(). This is because of how DSA works: in a tree with 3 switches, each calling dsa_register_switch(), the first 2 will advance until dsa_tree_setup() -> dsa_tree_setup_routing_table() and exit with error code 0 because the topology is not complete. Since probing is parallel at this point, one switch does not know about the existence of the other. Then the third switch comes, and for it, dsa_tree_setup_routing_table() returns complete = true. This switch goes ahead and calls dsa_tree_setup_switches() for everybody else, calling their .setup() methods too. This acts as the synchronization point. Signed-off-by:
-
Tobias Waldekranz authored
Allow switchdevs to forward frames from the CPU in accordance with the bridge configuration in the same way as is done between bridge ports. This means that the bridge will only send a single skb towards one of the ports under the switchdev's control, and expects the driver to deliver the packet to all eligible ports in its domain. Primarily this improves the performance of multicast flows with multiple subscribers, as it allows the hardware to perform the frame replication. The basic flow between the driver and the bridge is as follows: - When joining a bridge port, the switchdev driver calls switchdev_bridge_port_offload() with tx_fwd_offload = true. - The bridge sends offloadable skbs to one of the ports under the switchdev's control using skb->offload_fwd_mark = true. - The switchdev driver checks the skb->offload_fwd_mark field and lets its FDB lookup select the destination port mask for this packet. v1->v2: - convert br_input_skb_cb::fwd_hwdoms to a plain unsigned long - introduce a static key "br_switchdev_fwd_offload_used" to minimize the impact of the newly introduced feature on all the setups which don't have hardware that can make use of it - introduce a check for nbp->flags & BR_FWD_OFFLOAD to optimize cache line access - reorder nbp_switchdev_frame_mark_accel() and br_handle_vlan() in __br_forward() - do not strip VLAN on egress if forwarding offload on VLAN-aware bridge is being used - propagate errors from .ndo_dfwd_add_station() if not EOPNOTSUPP v2->v3: - replace the solution based on .ndo_dfwd_add_station with a solution based on switchdev_bridge_port_offload - rename BR_FWD_OFFLOAD to BR_TX_FWD_OFFLOAD v3->v4: rebase v4->v5: - make sure the static key is decremented on bridge port unoffload - more function and variable renaming and comments for them: br_switchdev_fwd_offload_used to br_switchdev_tx_fwd_offload br_switchdev_accels_skb to br_switchdev_frame_uses_tx_fwd_offload nbp_switchdev_frame_mark_tx_fwd to nbp_switchdev_frame_mark_tx_fwd_to_hwdom nbp_switchdev_frame_mark_accel to nbp_switchdev_frame_mark_tx_fwd_offload fwd_accel to tx_fwd_offload Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller authored
Conflicts are simple overlapping changes. Signed-off-by: -
David S. Miller authored
Arnd Bergmann says: ==================== remove compat_alloc_user_space() This is the fifth version of my series, now spanning four patches instead of two, with a new approach for handling struct ifreq compatibility after I realized that my earlier approach introduces additional problems. The idea here is to always push down the compat conversion deeper into the call stack: rather than pretending to be native mode with a modified copy of the original data on the user space stack, have the code that actually works on the data understand the difference between native and compat versions. I have spent a long time looking at all drivers that implement an ndo_do_ioctl callback to verify that my assumptions are correct. This has led to a series of ~30 additional patches that I am not including here but will post separately, fixing a number of bugs in SIOCDEVPRIVATE ioctls, removing dead code, and splitting ndo_do_ioctl into multiple new ndo callbacks for private and ethernet specific commands. Arnd Link: https://lore.kernel.org/netdev/20201124151828.169152-1-arnd@kernel.org/ Changes in v6: - Split out and expand linux/compat.h rework - Split ifconf change into two patches - Rebase on latest net-next/master Changes in v5: - Rebase to v5.14-rc2 - Fix a few build issues Changes in v4: - build fix without CONFIG_INET - build fix without CONFIG_COMPAT - style fixes pointed out by hch Changes in v3: - complete rewrite of the series ==================== Signed-off-by: -
Arnd Bergmann authored
compat_ifreq_ioctl() is one of the last users of copy_in_user() and compat_alloc_user_space(), as it attempts to convert the 'struct ifreq' arguments from 32-bit to 64-bit format as used by dev_ioctl() and a couple of socket family specific interpretations. The current implementation works correctly when calling dev_ioctl(), inet_ioctl(), ieee802154_sock_ioctl(), atalk_ioctl(), qrtr_ioctl() and packet_ioctl(). The ioctl handlers for x25, netrom, rose and x25 do not interpret the arguments and only block the corresponding commands, so they do not care. For af_inet6 and af_decnet however, the compat conversion is slightly incorrect, as it will copy more data than the native handler accesses, both of them use a structure that is shorter than ifreq. Replace the copy_in_user() conversion with a pair of accessor functions to read and write the ifreq data in place with the correct length where needed, while leaving the other ones to copy the (already compatible) structures directly. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Arnd Bergmann authored
The dev_ifconf() calling conventions make compat handling more complicated than necessary, simplify this by moving the in_compat_syscall() check into the function. Signed-off-by:
-
Arnd Bergmann authored
Since dynamic registration of the gifconf() helper is only used for IPv4, and this can not be in a loadable module, this can be simplified noticeably by turning it into a direct function call as a preparation for cleaning up the compat handling. Signed-off-by:
-
Arnd Bergmann authored
SIOCGIFMAP and SIOCSIFMAP currently require compat_alloc_user_space() and copy_in_user() for compat mode. Move the compat handling into the location where the structures are actually used, to avoid using those interfaces and get a clearer implementation. Reviewed-by:
-
