- 25 Jan, 2018 31 commits
-
-
Ursula Braun authored
Once a linkgroup is created successfully, it stays alive for a certain time to service more connections potentially created. If one of the initialization steps for a new linkgroup fails, the linkgroup should not be reused by other connections following. Signed-off-by:
Ursula Braun <ubraun@linux.vnet.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ursula Braun authored
If ib_post_send() fails, terminate all connections of this link group. Signed-off-by:
-
Ursula Braun authored
A state transition from closing state SMC_PEERFINCLOSEWAIT to closing state SMC_APPFINCLOSEWAIT is not allowed. Once a closing indication from the peer has been received, the socket reaches state SMC_CLOSED. And receiving a peer_conn_abort just changes the state of the socket into one of the states SMC_PROCESSABORT or SMC_CLOSED; sending a peer_conn_abort occurs in smc_close_active() for state SMC_PROCESSABORT only. Signed-off-by:
-
Ursula Braun authored
If an SMC socket is aborted, the tx worker should be cancelled. Signed-off-by:
-
David S. Miller authored
Edward Cree says: ==================== sfc: support PTP on 8000 and X2000 series NICs Starting from the 8000-series (Medford 1), SFC NICs can timestamp TX packets sent through an ordinary DMA queue, rather than a special control-plane operation as in the 7000-series. Patches 2-8 implement support for this. The X2000-series (Medford 2) changes the format of timestamps, from seconds+ (2^27)ths to seconds + quarter nanoseconds, as well as changing the shift of the frequency adjustment for increased precision. Patches 9-12 implement support for these changes. Patch #1 is an unrelated fix for NAPI budget handling, needed in order for TX completion changes in the later patches to apply cleanly. ==================== Signed-off-by: -
Laurence Evans authored
Support increased precision frequency adjustment format (FP44) used by Medford2 adapters. Signed-off-by:
Laurence Evans <levans@solarflare.com> Signed-off-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
-
Edward Cree authored
The time_format that we stash in the PTP data structure is never referenced, so we can remove it. Instead, store the information needed to interpret sync event timestamps. Also rolls in a couple of other related minor PTP fixes. Based on patches by Bert Kenward <bkenward@solarflare.com> and Laurence Evans <levans@solarflare.com>. Signed-off-by:
-
Laurence Evans authored
Support MC_CMD_PTP_OUT_GET_TIMESTAMP_CORRECTIONS_V2. Extract general timestamp corrections in addition to PTP corrections. Apply receive timestamp corrections for general datapath receive timestamping, and correspondingly for transmit. Signed-off-by:
-
Laurence Evans authored
Use timestamp conversion function with correction to avoid duplicate correction handling. Signed-off-by:
-
Martin Habets authored
We check the license for TX hardware timestamping capability. The PTP probe will have enabled PTP sync events from the adapter. If later, at TX queue init, it turns out we do not have the license, we don't need the sync events either. Signed-off-by:
Martin Habets <mhabets@solarflare.com> Signed-off-by:
-
Edward Cree authored
For this we create and use one or more new TX queues on the PTP channel, and enable sync events for it. Based on a patch by Martin Habets <mhabets@solarflare.com>. Signed-off-by:
-
Martin Habets authored
TX timestamps on 8000 series are supplied from the MAC. This timestamp is only 48 bits long. The high order bits from the last time sync event are used for the top 16 bits. Signed-off-by:
-
Martin Habets authored
If we try to enable the feature and do not have the license for it, the MCPU will refuse and fail our TX queue init. Signed-off-by:
-
Martin Habets authored
We can now transmit SKBs in 2 ways: 1. Via the MC (for the 7XXX series and earlier), using efx_ptp_xmit_skb_mc(). 2. Via the TX queues on the dedicated PTP channel (8XXX series and later), using efx_ptp_xmit_skb_queue(). The PTP worker thread uses the method set up at probe time. It never checked the return code from the old efx_ptp_xmit_skb(), so it now returns void. We increment the TX dropped counter of the device if the transmit fails. As a result of the probe per channel the remove gets called multiple times. Clean up efx->ptp_data properly to avoid the 2nd call blowing up. Signed-off-by:
-
Martin Habets authored
Use MC capability MC_CMD_GET_CAPABILITIES_V2_OUT_TX_MAC_TIMESTAMPING to detect whether the NIC supports timestamping packets sent out the main datapath. Signed-off-by:
-
Martin Habets authored
Before this work, TX timestamping is done by sending each SKB to the MC. On the 8000 series (Medford1) we have high speed timestamping via the MAC, which means we can use normal TX queues for this without a significant drop in bandwidth. On the X2000 series (Medford2) support for transmitting via the MC is removed, so the new way must be used. This patch enables timestamping on a TX queue, if requested. It also enhances TX event handling to process the extra completion events, and puts the time in the SKB. Signed-off-by:
-
Bert Kenward authored
The NAPI budget is only for RX processing work, not other work such as TX or MCDI completion handling. Signed-off-by:
Bert Kenward <bkenward@solarflare.com> Signed-off-by:
-
Kirill Tkhai authored
Currently, we unhash a dying net from netns_ids lists under rtnl_lock(). It's a leftover from the time when net::netns_ids was introduced. There was no net::nsid_lock, and rtnl_lock() was mostly need to order modification of alive nets nsid idr, i.e. for: for_each_net(tmp) { ... id = __peernet2id(tmp, net); idr_remove(&tmp->netns_ids, id); ... } Since we have net::nsid_lock, the modifications are protected by this local lock, and now we may introduce better scheme of netns_ids destruction. Let's look at the functions peernet2id_alloc() and get_net_ns_by_id(). Previous commits taught these functions to work well with dying net acquired from rtnl unlocked lists. And they are the only functions which can hash a net to netns_ids or obtain from there. And as easy to check, other netns_ids operating functions works with id, not with net pointers. So, we do not need rtnl_lock to synchronize cleanup_net() with all them. The another property, which is used in the patch, is that net is unhashed from net_namespace_list in the only place and by the only process. So, we avoid excess rcu_read_lock() or rtnl_lock(), when we'are iterating over the list in unhash_nsid(). All the above makes possible to keep rtnl_lock() locked only for net->list deletion, and completely avoid it for netns_ids unhashing and destruction. As these two doings may take long time (e.g., memory allocation to send skb), the patch should positively act on the scalability and signify decrease the time, which rtnl_lock() is held in cleanup_net(). Signed-off-by:Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsDavid S. Miller authored
Signed-off-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller authored
Signed-off-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) Avoid negative netdev refcount in error flow of xfrm state add, from Aviad Yehezkel. 2) Fix tcpdump decoding of IPSEC decap'd frames by filling in the ethernet header protocol field in xfrm{4,6}_mode_tunnel_input(). From Yossi Kuperman. 3) Fix a syzbot triggered skb_under_panic in pppoe having to do with failing to allocate an appropriate amount of headroom. From Guillaume Nault. 4) Fix memory leak in vmxnet3 driver, from Neil Horman. 5) Cure out-of-bounds packet memory access in em_nbyte EMATCH module, from Wolfgang Bumiller. 6) Restrict what kinds of sockets can be bound to the KCM multiplexer and also disallow when another layer has attached to the socket and made use of sk_user_data. From Tom Herbert. 7) Fix use before init of IOTLB in vhost code, from Jason Wang. 8) Correct STACR register write bit definition in IBM emac driver, from Ivan Mikhaylov. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: net/ibm/emac: wrong bit is used for STA control register write net/ibm/emac: add 8192 rx/tx fifo size vhost: do not try to access device IOTLB when not initialized vhost: use mutex_lock_nested() in vhost_dev_lock_vqs() i40e: flower: check if TC offload is enabled on a netdev qed: Free reserved MR tid qed: Remove reserveration of dpi for kernel kcm: Check if sk_user_data already set in kcm_attach kcm: Only allow TCP sockets to be attached to a KCM mux net: sched: fix TCF_LAYER_LINK case in tcf_get_base_ptr net: sched: em_nbyte: don't add the data offset twice mlxsw: spectrum_router: Don't log an error on missing neighbor vmxnet3: repair memory leak ipv6: Fix getsockopt() for sockets with default IPV6_AUTOFLOWLABEL pppoe: take ->needed_headroom of lower device into account on xmit xfrm: fix boolean assignment in xfrm_get_type_offload xfrm: Fix eth_hdr(skb)->h_proto to reflect inner IP version xfrm: fix error flow in case of add state fails xfrm: Add SA to hardware at the end of xfrm_state_construct() -
Al Viro authored
no users since 2014 Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
same story... Signed-off-by: -
Al Viro authored
Same story as with dev_ifsioc(), except that the last cases with non-trivial conversions had been taken out in 2013... Signed-off-by: -
Al Viro authored
Once upon a time net/socket.c:dev_ifsioc() used to handle SIOCSHWTSTAMP and SIOCSIFMAP. These have different native and compat layout, so the format conversion had been needed. In 2009 these two cases had been taken out, turning the rest into a convoluted way to calling sock_do_ioctl(). We copy compat structure into native one, call sock_do_ioctl() on that and copy the result back for the in/out ioctls. No layout transformation anywhere, so we might as well just call sock_do_ioctl() and skip all the headache with copying. Signed-off-by: -
Al Viro authored
Reviewed-by:
-
Al Viro authored
Reviewed-by:
-
Al Viro authored
Only two of dev_ioctl() callers may pass SIOCGIFCONF to it. Separating that codepath from the rest of dev_ioctl() allows both to simplify dev_ioctl() itself (all other cases work with struct ifreq *) *and* seriously simplify the compat side of that beast: all it takes is passing to inet_gifconf() an extra argument - the size of individual records (sizeof(struct ifreq) or sizeof(struct compat_ifreq)). With dev_ifconf() called directly from sock_do_ioctl()/compat_dev_ifconf() that's easy to arrange. As the result, compat side of SIOCGIFCONF doesn't need any allocations, copy_in_user() back and forth, etc. Reviewed-by:
-
- 24 Jan, 2018 9 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds authored
Pull sparc bugfix from David Miller: "Sparc Makefile typo fix" * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sparc64: fix typo in CONFIG_CRYPTO_DES_SPARC64 => CONFIG_CRYPTO_CAMELLIA_SPARC64
-
Ivan Mikhaylov authored
STA control register has areas of mode and opcodes for opeations. 18 bit is using for mode selection, where 0 is old MIO/MDIO access method and 1 is indirect access mode. 19-20 bits are using for setting up read/write operation(STA opcodes). In current state 'read' is set into old MIO/MDIO mode with 19 bit and write operation is set into 18 bit which is mode selection, not a write operation. To correlate write with read we set it into 20 bit. All those bit operations are MSB 0 based. Signed-off-by:
Ivan Mikhaylov <ivan@de.ibm.com> Signed-off-by:
-
Ivan Mikhaylov authored
emac4syn chips has availability to use 8192 rx/tx fifo buffer sizes, in current state if we set it up in dts 8192 as example, we will get only 2048 which may impact on network speed. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 100GbE Intel Wired LAN Driver Updates 2018-01-24 This series contains updates to fm10k only. Alex fixes MACVLAN offload for fm10k, where we were not seeing unicast packets being received because we did not correctly configure the default VLAN ID for the port and defaulting to 0. Jake cleans up unnecessary parenthesis in a couple of "if" statements. Fixed the driver to stop adding VLAN 0 into the VLAN table, since it would cause the VLAN table to be inconsistent between the PF and VF. Also fixed an issue where we were assuming that VLAN 1 is enabled when the default VLAN ID is not set, so resolve by not requesting any filters for the default_vid if it has not yet been assigned. Ngai fixes an issue which was generating a dmesg regarding unbale to kill a particular VLAN ID for the device. This is due to ndo_vlan_rx_kill_vid() exits with an error and the handler for this ndo is fm10k_update_vid() which exits prematurely under PF VLAN management. So to resolve, we must check the VLAN update action type before exiting fm10k_update_vid(), and act appropriately based on the action type. Also corrected code comment typos. ==================== Signed-off-by: -
Ngai-Mint Kwan authored
Clarify the comment for when entering promiscuous mode that we update the VLAN table. Add a comment distinguishing the case where we're exiting promiscuous mode and need to clear the entire VLAN table. Signed-off-by:
Ngai-Mint Kwan <ngai-mint.kwan@intel.com> Signed-off-by:
Jacob Keller <jacob.e.keller@gmail.com> Tested-by:
Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Ngai-Mint Kwan authored
Signed-off-by:
-
Jacob Keller authored
Since commit 856dfd69e84f ("fm10k: Fix multicast mode synch issues", 2016-03-03) we've incorrectly assumed that VLAN 1 is enabled when the default VID is not set. This occurs because we check the default_vid and if it's zero, start several loops over the active_vlans bitmask at 1, instead of checking to ensure that that bit is active. This happened because of commit d9ff3ee8efe9 ("fm10k: Add support for VLAN 0 w/o default VLAN", 2014-08-07) which mistakenly assumed that we should send requests for MAC and VLAN filters with VLAN 0 when the default_vid isn't set. However, the switch generally considers this an invalid configuration, so the only time we'd have a default_vid of 0 is when the switch is down. Instead, lets just not request any filters for the default_vid if it's not yet been assigned. Signed-off-by:Jacob Keller <jacob.e.keller@intel.com> Tested-by:
-
Jacob Keller authored
Currently, when the driver loads, it sends a request to add VLAN 0 to the VLAN table. For the PF, this is honored, and VLAN 0 is indeed set. For the VF, this request is silently converted into a request for the default VLAN as defined by either the switch vid or the PF vid. This results in the odd behavior that the VLAN table doesn't appear consistent between the PF and the VF. Furthermore, setting a MAC filter with VLAN 0 is generally considered an invalid configuration by the switch, and since commit 856dfd69e84f ("fm10k: Fix multicast mode synch issues", 2016-03-03) we've had code which prevents us from ever sending such a request. Since there's not really a good reason to keep VLAN 0 in the VLAN table, stop requesting it in fm10k_restore_rx_state(). This might seem to indicate that we would no longer properly configure the MAC and VLAN tables for the default vid. However, due to the way that fm10k_find_next_vlan() behaves, it will always return the default_vid as enabled. Signed-off-by: -
Ngai-Mint Kwan authored
When a VF is under PF VLAN assignment: ip link set <pf> vf <#> vlan <vid> This will remove all previous entries in the VLAN table including those generated by VLAN interfaces created on the VF. The issue arises when the VF is under PF VLAN assignment and one or more of these VLAN interfaces of the VF are deleted. When deleting these VLAN interfaces, the following message will be generated in "dmesg": failed to kill vid 0081/<vid> for device <vf> This is due to the fact that "ndo_vlan_rx_kill_vid" exits with an error. The handler for this ndo is "fm10k_update_vid". Any calls to this function while under PF VLAN management will exit prematurely and, thus, it will generate the failure message. Additionally, since "fm10k_update_vid" exits prematurely, none of the VLAN update is performed. So, even though the actual VLAN interfaces of the VF will be deleted, the active_vlans bitmask is not cleared. When the VF is no longer under PF VLAN assignment, the driver mistakenly restores the previous entries of the VLAN table based on an unsynchronized list of active VLANs. The solution to this issue involves checking the VLAN update action type before exiting "fm10k_update_vid". If the VLAN update action type is to "add", this action will not be permitted while the VF is under PF VLAN assignment and the VLAN update is abandoned like before. However, if the VLAN update action type is to "kill", then we need to also clear the active_vlans bitmask. However, we don't need to actually queue any messages to the PF, because the MAC and VLAN tables have already been cleared, and the PF would silently ignore these requests anyways. Signed-off-by:
-
