- 18 Sep, 2020 40 commits
-
-
YueHaibing authored
It is no used any more, so can remove it. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Wang Hai authored
If the header file containing a function's prototype isn't included by the sourcefile containing the associated function, the build system complains of missing prototypes. Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c:453:6: warning: no previous prototype for ‘hclge_dcb_ops_set’ [-Wmissing-prototypes] Signed-off-by:
Wang Hai <wanghai38@huawei.com> Reviewed-by:
Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
-
Wang Hai authored
If the header file containing a function's prototype isn't included by the sourcefile containing the associated function, the build system complains of missing prototypes. Fixes the following W=1 kernel build warning(s): drivers/net/appletalk/cops.c:213:28: warning: no previous prototype for ‘cops_probe’ [-Wmissing-prototypes] drivers/net/appletalk/ltpc.c:1014:28: warning: no previous prototype for ‘ltpc_probe’ [-Wmissing-prototypes] Signed-off-by:
-
Wang Hai authored
If the header file containing a function's prototype isn't included by the sourcefile containing the associated function, the build system complains of missing prototypes. Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/cavium/liquidio/cn68xx_device.c:124:5: warning: no previous prototype for ‘lio_setup_cn68xx_octeon_device’ [-Wmissing-prototypes] drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:159:1: warning: no previous prototype for ‘octeon_pci_read_core_mem’ [-Wmissing-prototypes] drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:168:1: warning: no previous prototype for ‘octeon_pci_write_core_mem’ [-Wmissing-prototypes] drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:176:5: warning: no previous prototype for ‘octeon_read_device_mem64’ [-Wmissing-prototypes] drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:185:5: warning: no previous prototype for ‘octeon_read_device_mem32’ [-Wmissing-prototypes] drivers/net/ethernet/cavium/liquidio/octeon_mem_ops.c:194:6: warning: no previous prototype for ‘octeon_write_device_mem32’ [-Wmissing-prototypes] Signed-off-by:
-
Tom Parkin authored
Historically L2TP core statistics count the L2TP header in the per-session and per-tunnel byte counts tracked for transmission and receipt. Now that l2tp_xmit_skb updates tx stats, it is necessary for l2tp_xmit_core to pass out the length of the transmitted packet so that the statistics can be updated correctly. Signed-off-by:
Tom Parkin <tparkin@katalix.com> Signed-off-by:
-
Luo bin authored
Make a distinction between different irqs by netdev name or pci name. Signed-off-by:
Luo bin <luobin9@huawei.com> Reviewed-by:
-
Zheng Yongjun authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/cortina/gemini.c: In function gmac_get_ringparam: drivers/net/ethernet/cortina/gemini.c:2125:21: warning: variable ‘config0’ set but not used [-Wunused-but-set-variable] drivers/net/ethernet/cortina/gemini.c: In function gmac_init: drivers/net/ethernet/cortina/gemini.c:512:6: warning: variable ‘val’ set but not used [-Wunused-but-set-variable] these variable is never used, so remove it. Signed-off-by:
Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by:
-
David S. Miller authored
Yangbo Lu says: ==================== dpaa2_eth: support 1588 one-step timestamping This patch-set is to add MC APIs of 1588 one-step timestamping, and support one-step timestamping for PTP Sync packet on DPAA2. Before egress, one-step timestamping enablement needs, - Enabling timestamp and FAS (Frame Annotation Status) in dpni buffer layout. - Write timestamp to frame annotation and set PTP bit in FAS to mark as one-step timestamping event. - Enabling one-step timestamping by dpni_set_single_step_cfg() API, with offset provided to insert correction time on frame. The offset must respect all MAC headers, VLAN tags and other protocol headers accordingly. The correction field update can consider delays up to one second. So PTP frame needs to be filtered and parsed, and written timestamp into Sync frame originTimestamp field. The operation of API dpni_set_single_step_cfg() has to be done when no one-step timestamping frames are in flight. So we have to make sure the last one-step timestamping frame has already been transmitted on hardware before starting to send the current one. The resolution is, - Utilize skb->cb[0] to mark timestamping request per packet. If it is one-step timestamping PTP sync packet, queue to skb queue. If not, transmit immediately. - Schedule a work to transmit skbs in skb queue. - mutex lock is used to ensure the last one-step timestamping packet has already been transmitted on hardware through TX confirmation queue before transmitting current packet. Changes for v2: - Removed unused variable priv in dpaa2_eth_xdp_create_fd(). Changes for v3: - Fixed sparse warnings. - Fix build issue on 32-bit. - Converted to use ptp_parse_header. Changes for v4: - Used WARN_ONCE instead of netdev_err in data path. - Enabled timestamping only when PTP driver is ready. - Added comments in using onestep_tstamp_lock. - Dropped dpmac.c sparse warning fix-up patch. ==================== Signed-off-by: -
Yangbo Lu authored
This patch is to add PTP sync packet one-step timestamping support. Before egress, one-step timestamping enablement needs, - Enabling timestamp and FAS (Frame Annotation Status) in dpni buffer layout. - Write timestamp to frame annotation and set PTP bit in FAS to mark as one-step timestamping event. - Enabling one-step timestamping by dpni_set_single_step_cfg() API, with offset provided to insert correction time on frame. The offset must respect all MAC headers, VLAN tags and other protocol headers accordingly. The correction field update can consider delays up to one second. So PTP frame needs to be filtered and parsed, and written timestamp into Sync frame originTimestamp field. The operation of API dpni_set_single_step_cfg() has to be done when no one-step timestamping frames are in flight. So we have to make sure the last one-step timestamping frame has already been transmitted on hardware before starting to send the current one. The resolution is, - Utilize skb->cb[0] to mark timestamping request per packet. If it is one-step timestamping PTP sync packet, queue to skb queue. If not, transmit immediately. - Schedule a work to transmit skbs in skb queue. - mutex lock is used to ensure the last one-step timestamping packet has already been transmitted on hardware through TX confirmation queue before transmitting current packet. Signed-off-by:
Yangbo Lu <yangbo.lu@nxp.com> Signed-off-by:
-
Yangbo Lu authored
This patch is a preparation for next hardware one-step timestamping support. For DPAA2, the one step timestamping configuration on hardware registers has to be done when there is no one-step timestamping packet in flight. So we will have to use workqueue and skb queue for such packets transmitting, to make sure waiting the last packet has already been sent on hardware, and starting to transmit the current one. So the tx timestamping flag in private data may not reflect the actual request for the one-step timestamping packets of skb queue. This also affects skb headroom allocation. Let's use skb->cb[0] to mark the timestamping request for each skb. Signed-off-by:
-
Yangbo Lu authored
Invoke dpaa2_eth_enable_tx_tstamp() once in code after building FD, rather than calling it in dpaa2_eth_build_single_fd(), dpaa2_eth_build_sg_fd_single_buf(), and dpaa2_eth_build_sg_fd(). Signed-off-by:
-
Yangbo Lu authored
Define a global ptp_qoriq structure pointer, and export to use. The ptp clock operations will be used in dpaa2-eth driver. For example, supporting one step timestamping needs to write current time to hardware frame annotation before sending and then hardware inserts the delay time on frame during sending. So in driver, at least clock gettime operation will be needed to make sure right time is written to hardware frame annotation for one step timestamping. Signed-off-by:
-
Yangbo Lu authored
This patch is to add APIs of 1588 single step timestamping. - dpni_set_single_step_cfg - dpni_get_single_step_cfg Signed-off-by:
-
Zeng Tao authored
In the function ovs_ct_limit_exit, there is already a helper vaibale which could be reused to improve the readability, so i fix it in this patch. Signed-off-by:
Zeng Tao <prime.zeng@hisilicon.com> Signed-off-by:
-
Mahesh Bandewar authored
Earlier commit 316cdaa1 ("net: add option to not create fall-back tunnels in root-ns as well") removed the CONFIG_SYSCTL to enable the kernel-commandline to work. However, this variable gets defined only when CONFIG_SYSCTL option is selected. With this change the behavior would default to creating fall-back tunnels in all namespaces when CONFIG_SYSCTL is not selected and the kernel commandline option will be ignored. Fixes: 316cdaa1 ("net: add option to not create fall-back tunnels in root-ns as well") Signed-off-by:
Mahesh Bandewar <maheshb@google.com> Reported-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kernel test robot <lkp@intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by:
-
David S. Miller authored
Randy Dunlap says: ==================== net: various: delete duplicated words [PATCH 1/7 net-next] net: core: delete duplicated words [PATCH 2/7 net-next] net: rds: delete duplicated words [PATCH 3/7 net-next] net: ipv6: delete duplicated words [PATCH 4/7 net-next] net: bluetooth: delete duplicated words [PATCH 5/7 net-next] net: tipc: delete duplicated words [PATCH 6/7 net-next] net: atm: delete duplicated words [PATCH 7/7 net-next] net: bridge: delete duplicated words ==================== Signed-off-by: -
Randy Dunlap authored
Drop repeated words in net/bridge/. Signed-off-by:
-
Randy Dunlap authored
Drop repeated words in net/atm/. Signed-off-by:
-
Randy Dunlap authored
Drop repeated words in net/tipc/. Signed-off-by:
-
Randy Dunlap authored
Drop repeated words in net/bluetooth/. Signed-off-by:
-
Randy Dunlap authored
Drop repeated words in net/ipv6/. Signed-off-by:
-
Randy Dunlap authored
Drop repeated words in net/rds/. Signed-off-by:
-
Randy Dunlap authored
Drop repeated words in net/core/. Signed-off-by:
-
Lijun Pan authored
This reverts commit 550f4d46. adapter->from_passive_init may be changed in ibmvnic_handle_crq while ibmvnic_reset_init is waiting for the completion of adapter->init_done. Signed-off-by:
Lijun Pan <ljp@linux.ibm.com> Signed-off-by:
-
David S. Miller authored
Tuong Lien says: ==================== tipc: add more features to TIPC encryption This series adds some new features to TIPC encryption: - Patch 1 ("tipc: optimize key switching time and logic") optimizes the code and logic in preparation for the following commits. - Patch 2 ("tipc: introduce encryption master key") introduces support of 'master key' for authentication of new nodes and key exchange. A master key can be set/changed by user via netlink (eg. using the same 'tipc node set key' command in iproute2/tipc). - Patch 3 ("tipc: add automatic session key exchange") allows a session key to be securely exchanged between nodes as needed. - Patch 4 ("tipc: add automatic rekeying for encryption key") adds automatic 'rekeying' of session keys a specific interval. The new key will be distributed automatically to peer nodes, so become active then. The rekeying interval is configurable via netlink as well. v2: update the "tipc: add automatic session key exchange" patch to fix "implicit declaration" issue when built without "CONFIG_TIPC_CRYPTO". v3: update the patches according to David comments by using the "genl_info->extack" for messages in response to netlink user config requests. ==================== Signed-off-by: -
Tuong Lien authored
Rekeying is required for security since a key is less secure when using for a long time. Also, key will be detached when its nonce value (or seqno ...) is exhausted. We now make the rekeying process automatic and configurable by user. Basically, TIPC will at a specific interval generate a new key by using the kernel 'Random Number Generator' cipher, then attach it as the node TX key and securely distribute to others in the cluster as RX keys (- the key exchange). The automatic key switching will then take over, and make the new key active shortly. Afterwards, the traffic from this node will be encrypted with the new session key. The same can happen in peer nodes but not necessarily at the same time. For simplicity, the automatically generated key will be initiated as a per node key. It is not too hard to also support a cluster key rekeying (e.g. a given node will generate a unique cluster key and update to the others in the cluster...), but that doesn't bring much benefit, while a per-node key is even more secure. We also enable user to force a rekeying or change the rekeying interval via netlink, the new 'set key' command option: 'TIPC_NLA_NODE_REKEYING' is added for these purposes as follows: - A value >= 1 will be set as the rekeying interval (in minutes); - A value of 0 will disable the rekeying; - A value of 'TIPC_REKEYING_NOW' (~0) will force an immediate rekeying; The default rekeying interval is (60 * 24) minutes i.e. done every day. There isn't any restriction for the value but user shouldn't set it too small or too large which results in an "ineffective" rekeying (thats ok for testing though). Acked-by:
Jon Maloy <jmaloy@redhat.com> Signed-off-by:
Tuong Lien <tuong.t.lien@dektech.com.au> Signed-off-by:
-
Tuong Lien authored
With support from the master key option in the previous commit, it becomes easy to make frequent updates/exchanges of session keys between authenticated cluster nodes. Basically, there are two situations where the key exchange will take in place: - When a new node joins the cluster (with the master key), it will need to get its peer's TX key, so that be able to decrypt further messages from that peer. - When a new session key is generated (by either user manual setting or later automatic rekeying feature), the key will be distributed to all peer nodes in the cluster. A key to be exchanged is encapsulated in the data part of a 'MSG_CRYPTO /KEY_DISTR_MSG' TIPC v2 message, then xmit-ed as usual and encrypted by using the master key before sending out. Upon receipt of the message it will be decrypted in the same way as regular messages, then attached as the sender's RX key in the receiver node. In this way, the key exchange is reliable by the link layer, as well as security, integrity and authenticity by the crypto layer. Also, the forward security will be easily achieved by user changing the master key actively but this should not be required very frequently. The key exchange feature is independent on the presence of a master key Note however that the master key still is needed for new nodes to be able to join the cluster. It is also optional, and can be turned off/on via the sysfs: 'net/tipc/key_exchange_enabled' [default 1: enabled]. Backward compatibility is guaranteed because for nodes that do not have master key support, key exchange using master key ie. tx_key = 0 if any will be shortly discarded at the message validation step. In other words, the key exchange feature will be automatically disabled to those nodes. v2: fix the "implicit declaration of function 'tipc_crypto_key_flush'" error in node.c. The function only exists when built with the TIPC "CONFIG_TIPC_CRYPTO" option. v3: use 'info->extack' for a message emitted due to netlink operations instead (- David's comment). Reported-by:
-
Tuong Lien authored
In addition to the supported cluster & per-node encryption keys for the en/decryption of TIPC messages, we now introduce one option for user to set a cluster key as 'master key', which is simply a symmetric key like the former but has a longer life cycle. It has two purposes: - Authentication of new member nodes in the cluster. New nodes, having no knowledge of current session keys in the cluster will still be able to join the cluster as long as they know the master key. This is because all neighbor discovery (LINK_CONFIG) messages must be encrypted with this key. - Encryption of session encryption keys during automatic exchange and update of those.This is a feature we will introduce in a later commit in this series. We insert the new key into the currently unused slot 0 in the key array and start using it immediately once the user has set it. After joining, a node only knowing the master key should be fully communicable to existing nodes in the cluster, although those nodes may have their own session keys activated (i.e. not the master one). To support this, we define a 'grace period', starting from the time a node itself reports having no RX keys, so the existing nodes will use the master key for encryption instead. The grace period can be extended but will automatically stop after e.g. 5 seconds without a new report. This is also the basis for later key exchanging feature as the new node will be impossible to decrypt anything without the support from master key. For user to set a master key, we define a new netlink flag - 'TIPC_NLA_NODE_KEY_MASTER', so it can be added to the current 'set key' netlink command to specify the setting key to be a master key. Above all, the traditional cluster/per-node key mechanism is guaranteed to work when user comes not to use this master key option. This is also compatible to legacy nodes without the feature supported. Even this master key can be updated without any interruption of cluster connectivity but is so is needed, this has to be coordinated and set by the user. Acked-by:
-
Tuong Lien authored
We reduce the lasting time for a pending TX key to be active as well as for a passive RX key to be freed which generally helps speed up the key switching. It is not expected to be too fast but should not be too slow either. Also the key handling logic is simplified that a pending RX key will be removed automatically if it is found not working after a number of times; the probing for a pending TX key is now carried on a specific message user ('LINK_PROTOCOL' or 'LINK_CONFIG') which is more efficient than using a timer on broadcast messages, the timer is reserved for use later as needed. The kernel logs or 'pr***()' are now made as clear as possible to user. Some prints are added, removed or changed to the debug-level. The 'TIPC_CRYPTO_DEBUG' definition is removed, and the 'pr_debug()' is used instead which will be much helpful in runtime. Besides we also optimize the code in some other places as a preparation for later commits. v2: silent more kernel logs, also use 'info->extack' for a message emitted due to netlink operations instead (- David's comments). Acked-by: -
David S. Miller authored
Shannon Nelson says: ==================== ionic: add devlink dev flash support Add support for using devlink's dev flash facility to update the firmware on an ionic device, and add a new timeout parameter to the devlink flash netlink message. For long-running flash commands, we add a timeout element to the dev flash notify message in order for a userland utility to display a timeout deadline to the user. This allows the userland utility to display a count down to the user when a firmware update action is otherwise going to go for ahile without any updates. An example use is added to the netdevsim module. The ionic driver uses this timeout element in its new flash function. The driver uses a simple model of pushing the firmware file to the NIC, asking the NIC to unpack and install the file into the device, and then selecting it for the next boot. If any of these steps fail, the whole transaction is failed. A couple of the steps can take a long time, so we use the timeout status message rather than faking it with bogus done/total messages. The driver doesn't currently support doing these steps individually. In the future we want to be able to list the FW that is installed and selectable but we don't yet have the API to fully support that. v5: pulled the cmd field back out of the new params struct changed netdevsim example message to "Flash select" v4: Added a new devlink status notify message for showing timeout information, and modified the ionic fw update to use it for its long running firmware commands. v3: Changed long dev_cmd timeout on status check calls to a loop around calls with a normal timeout, which allows for more intermediate log messaging when in a long wait, and for letting other threads run dev_cmds if waiting. v2: Changed "Activate" to "Select" in status messages. ==================== Signed-off-by: -
Shannon Nelson authored
Add support for firmware update through the devlink interface. This update copies the firmware object into the device, asks the current firmware to install it, then asks the firmware to select the new firmware for the next boot-up. The install and select steps are launched as asynchronous requests, which are then followed up with status request commands. These status request commands will be answered with an EAGAIN return value and will try again until the request has completed or reached the timeout specified. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Acked-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Shannon Nelson authored
Add the rest of the firmware api bits needed to support the driver running a firmware update. Signed-off-by:
-
Shannon Nelson authored
Add a simple devlink flash timeout message to exercise the message mechanism. Signed-off-by:
-
Shannon Nelson authored
The dev flash status notify function parameter lists are getting rather long, so add a struct to be filled and passed rather than continuously changing the function signatures. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Reviewed-by:
-
Shannon Nelson authored
Add a timeout element to the DEVLINK_CMD_FLASH_UPDATE_STATUS netlink message for use by a userland utility to show that a particular firmware flash activity may take a long but bounded time to finish. Also add a handy helper for drivers to make use of the new timeout value. UI usage hints: - if non-zero, add timeout display to the end of the status line [component] status_msg ( Xm Ys : Am Bs ) using the timeout value for Am Bs and updating the Xm Ys every second - if the timeout expires while awaiting the next update, display something like [component] status_msg ( timeout reached : Am Bs ) - if new status notify messages are received, remove the timeout and start over Signed-off-by: -
Francesco Ruggeri authored
The combination of aca_free_rcu, introduced in commit 2384d025 ("net/ipv6: Add anycast addresses to a global hashtable"), and fib6_info_destroy_rcu, introduced in commit 9b0a8da8 ("net/ipv6: respect rcu grace period before freeing fib6_info"), can result in an extra rcu grace period being needed when deleting an interface, with the result that netdev_wait_allrefs ends up hitting the msleep(250), which is considerably longer than the required grace period. This can result in long delays when deleting a large number of interfaces, and it can be observed with this script: ns=dummy-ns NIFS=100 ip netns add $ns ip netns exec $ns ip link set lo up ip netns exec $ns sysctl net.ipv6.conf.default.disable_ipv6=0 ip netns exec $ns sysctl net.ipv6.conf.default.forwarding=1 for ((i=0; i<$NIFS; i++)) do if=eth$i ip netns exec $ns ip link add $if type dummy ip netns exec $ns ip link set $if up ip netns exec $ns ip -6 addr add 2021:$i::1/120 dev $if done for ((i=0; i<$NIFS; i++)) do if=eth$i ip netns exec $ns ip link del $if done ip netns del $ns Instead of using a fixed msleep(250), this patch tries an extra rcu_barrier() followed by an exponential backoff. Time with this patch on a 5.4 kernel: real 0m7.704s user 0m0.385s sys 0m1.230s Time without this patch: real 0m31.522s user 0m0.438s sys 0m1.156s v2: use exponential backoff instead of trying to wake up netdev_wait_allrefs. v3: preserve reverse christmas tree ordering of local variables v4: try an extra rcu_barrier before the backoff, plus some cosmetic changes. Signed-off-by:
Francesco Ruggeri <fruggeri@arista.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Paolo Abeni authored
Christoph reported an infinite loop in the subflow receive path under stress condition. If there are multiple subflows, each of them using a large send buffer, the delta between the sequence number used by MPTCP-level retransmission can and the current msk->ack_seq can be greater than MAX_INT. In the above scenario, when calling mptcp_subflow_discard_data(), such delta will be truncated to int, and could result in a negative number: no bytes will be dropped, and subflow_check_data_avail() will try again to process the same packet, looping forever. This change addresses the issue by expanding the 'limit' size to 64 bits, so that overflows are not possible anymore. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/87 Fixes: 6719331c ("mptcp: trigger msk processing even for OoO data") Reported-and-tested-by:
Christoph Paasch <cpaasch@apple.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Reviewed-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Ursula Braun authored
If smc_listen_rmda_finish() returns with an error, the storage addressed by 'buf' is freed a second time. Consolidate freeing under a common label and jump to that label. Fixes: 6bb14e48 ("net/smc: dynamic allocation of CLC proposal buffer") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Ursula Braun <ubraun@linux.ibm.com> Signed-off-by:
Karsten Graul <kgraul@linux.ibm.com> Signed-off-by:
-
Shannon Nelson authored
>> ld.lld: error: undefined symbol: net_dim_get_rx_moderation >>> referenced by ionic_lif.c:52 (drivers/net/ethernet/pensando/ionic/ionic_lif.c:52) >>> net/ethernet/pensando/ionic/ionic_lif.o:(ionic_dim_work) in archive drivers/built-in.a >> ld.lld: error: undefined symbol: net_dim >>> referenced by ionic_txrx.c:456 (drivers/net/ethernet/pensando/ionic/ionic_txrx.c:456) >>> net/ethernet/pensando/ionic/ionic_txrx.o:(ionic_dim_update) in archive drivers/built-in.a v2: removed sketchy dashes in commit message Fixes: 04a83459 ("ionic: dynamic interrupt moderation") Reported-by:
-
Jakub Kicinski authored
We removed the misleading comments from struct rtnl_link_stats64 when we added proper kdoc. struct rtnl_link_stats has the same inline comments, so remove them, too. Signed-off-by:
-
