- 24 Jul, 2018 40 commits
-
-
Stephen Hemminger authored
Signed-off-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Remove trailing whitespace and extra lines at EOF Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Remove blank line at EOF and trailing whitespace. Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Remove trailing whitespace and blank lines at EOF Signed-off-by:
-
Tariq Toukan authored
The cited patch added a call to dev_change_tx_queue_len in SIOCSIFTXQLEN case. This obsoletes the new len comparison check done before the function call. Remove it here. For the desicion of keep/remove the negative value check, we examine the range check in dev_change_tx_queue_len. On 64-bit we will fail with -ERANGE. The 32-bit int ifr_qlen will be sign extended to 64-bits when it is passed into dev_change_tx_queue_len(). And then for negative values this test triggers: if (new_len != (unsigned int)new_len) return -ERANGE; because: if (0xffffffffWHATEVER != 0x00000000WHATEVER) On 32-bit the signed value will be accepted, changing behavior. Therefore, the negative value check is kept. Fixes: 3f76df19 ("net: use dev_change_tx_queue_len() for SIOCSIFTXQLEN") Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Reviewed-by:
Eran Ben Elisha <eranbe@mellanox.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
David S. Miller authored
Rahul Lakkireddy says: ==================== cxgb4: collect free Tx/Rx pages and page pointers Patch 1 collects number of free PSTRUCT page pointers in context memory. Patch 2 moves the collection logic for Tx/Rx free pages to common code, since this information needs to be collected in vmcore device dump as well. ==================== Signed-off-by: -
Rahul Lakkireddy authored
This information needs to be collected in vmcore device dump as well. So, move to common code. Fixes: fa145d5d ("cxgb4: display number of rx and tx pages free") Signed-off-by:
Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by:
Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by:
-
Rahul Lakkireddy authored
Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Add extack messages for tc flower Nir says: This patch set adds extack messages support to tc flower part of mlxsw. The messages provide clear reasoning to failures, as some of the available actions and keys are not supported in driver or HW and resources may get exhausted. The first patch deals with propagation of the extack pointer among the functions dealing with key parsing and action sets handling. Following patches 2-4 add appropriate messages across the different layers of mlxsw tc flower implementation. ==================== Signed-off-by: -
Nir Dotan authored
Return extack messages in order to explain failures of unsupported actions, keys and invalid user input. Signed-off-by:
Nir Dotan <nird@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Nir Dotan authored
Return extack messages for failures in action set creation. Messages provide reasons for not being able to implement the action in HW. Signed-off-by:
-
Nir Dotan authored
Return extack messages for failures in action set creation. Errors may occur when action is not currently supported or due to lack of resources. Signed-off-by:
-
Nir Dotan authored
Propagate extack pointer in order to add extack messages for ACL. In the follow-up patches, appropriate messages will be added in various points. Signed-off-by:
-
Florian Westphal authored
->start() is called once when dump is being initialized, there is no need to store it in netlink_cb. Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
David S. Miller authored
Merge tag 'mac80211-next-for-davem-2018-07-24' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== Only a few things: * HE (802.11ax) support in HWSIM * bypass TXQ with NDP frames as they're special * convert ahash -> shash in lib80211 TKIP * avoid playing with tailroom counter defer unless needed to avoid issues in some cases ==================== Signed-off-by:
-
Manikanta Pubbisetty authored
As explained in ieee80211_delayed_tailroom_dec(), during roam, keys of the old AP will be destroyed and new keys will be installed. Deletion of the old key causes crypto_tx_tailroom_needed_cnt to go from 1 to 0 and the new key installation causes a transition from 0 to 1. Whenever crypto_tx_tailroom_needed_cnt transitions from 0 to 1, we invoke synchronize_net(); the reason for doing this is to avoid a race in the TX path as explained in increment_tailroom_need_count(). This synchronize_net() operation can be slow and can affect the station roam time. To avoid this, decrementing the crypto_tx_tailroom_needed_cnt is delayed for a while so that upon installation of new key the transition would be from 1 to 2 instead of 0 to 1 and thereby improving the roam time. This is all correct for a STA iftype, but deferring the tailroom_needed decrement for other iftypes may be unnecessary. For example, let's consider the case of a 4-addr client connecting to an AP for which AP_VLAN interface is also created, let the initial value for tailroom_needed on the AP be 1. * 4-addr client connects to the AP (AP: tailroom_needed = 1) * AP will clear old keys, delay decrement of tailroom_needed count * AP_VLAN is created, it takes the tailroom count from master (AP_VLAN: tailroom_needed = 1, AP: tailroom_needed = 1) * Install new key for the station, assume key is plumbed in the HW, there won't be any change in tailroom_needed count on AP iface * Delayed decrement of tailroom_needed count on AP (AP: tailroom_needed = 0, AP_VLAN: tailroom_needed = 1) Because of the delayed decrement on AP iface, tailroom_needed count goes out of sync between AP(master iface) and AP_VLAN(slave iface) and there would be unnecessary tailroom created for the packets going through AP_VLAN iface. Also, WARN_ONs were observed while trying to bring down the AP_VLAN interface: (warn_slowpath_common) (warn_slowpath_null+0x18/0x20) (warn_slowpath_null) (ieee80211_free_keys+0x114/0x1e4) (ieee80211_free_keys) (ieee80211_del_virtual_monitor+0x51c/0x850) (ieee80211_del_virtual_monitor) (ieee80211_stop+0x30/0x3c) (ieee80211_stop) (__dev_close_many+0x94/0xb8) (__dev_close_many) (dev_close_many+0x5c/0xc8) Restricting delayed decrement to station interface alone fixes the problem and it makes sense to do so because delayed decrement is done to improve roam time which is applicable only for client devices. Signed-off-by:
Manikanta Pubbisetty <mpubbise@codeaurora.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Kees Cook authored
In preparing to remove all stack VLA usage from the kernel[1], this removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of the smaller SHASH_DESC_ON_STACK by converting from ahash-wrapped-shash to direct shash. The stack allocation will be made a fixed size in a later patch to the crypto subsystem. [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.comSigned-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
David S. Miller authored
Merge tag 'wireless-drivers-next-for-davem-2018-07-23' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 4.19 The first set of patches for 4.19. Only smaller features and bug fixes, not really anything major. Also included are changes to include/linux/bitfield.h, we agreed with Johannes that it makes sense to apply them via wireless-drivers-next. Major changes: ath10k * support channel 173 * fix spectral scan for QCA9984 and QCA9888 chipsets ath6kl * add support for Dell Wireless 1537 ti wlcore * add support for runtime PM * enable runtime PM autosuspend support qtnfmac * support changing MAC address * enable source MAC address randomization support libertas * fix suspend and resume for SDIO cards mt76 * add software DFS radar pattern detector for mt76x2 based devices ==================== Signed-off-by:
-
David S. Miller authored
Ka-Cheong Poon says: ==================== rds: IPv6 support This patch set adds IPv6 support to the kernel RDS and related modules. Existing RDS apps using IPv4 address continue to run without any problem. New RDS apps which want to use IPv6 address can do so by passing the address in struct sockaddr_in6 to bind(), connect() or sendmsg(). And those apps also need to use the new IPv6 equivalents of some of the existing socket options as the existing options use a 32 bit integer to store IP address. All RDS code now use struct in6_addr to store IP address. IPv4 address is stored as an IPv4 mapped address. Header file changes There are many data structures (RDS socket options) used by RDS apps which use a 32 bit integer to store IP address. To support IPv6, struct in6_addr needs to be used. To ensure backward compatibility, a new data structure is introduced for each of those data structures which use a 32 bit integer to represent an IP address. And new socket options are introduced to use those new structures. This means that existing apps should work without a problem with the new RDS module. For apps which want to use IPv6, those new data structures and socket options can be used. IPv4 mapped address is used to represent IPv4 address in the new data structures. Internally, all RDS data structures which contain an IP address are changed to use struct in6_addr to store the address. IPv4 address is stored as an IPv4 mapped address. All the functions which take an IP address as argument are also changed to use struct in6_addr. RDS/RDMA/IB uses a private data (struct rds_ib_connect_private) exchange between endpoints at RDS connection establishment time to support RDMA. This private data exchange uses a 32 bit integer to represent an IP address. This needs to be changed in order to support IPv6. A new private data struct rds6_ib_connect_private is introduced to handle this. To ensure backward compatibility, an IPv6 capable RDS stack uses another RDMA listener port (RDS_CM_PORT) to accept IPv6 connection. And it continues to use the original RDS_PORT for IPv4 RDS connections. When it needs to communicate with an IPv6 peer, it uses the RDS_TCP_PORT to send the connection set up request. RDS/TCP changes TCP related code is changed to support IPv6. Note that only an IPv6 TCP listener on port RDS_TCP_PORT is created as it can accept both IPv4 and IPv6 connection requests. IB/RDMA changes The initial private data exchange between IB endpoints using RDMA is changed to support IPv6 address instead, if the peer address is IPv6. To ensure backward compatibility, annother RDMA listener port (RDS_CM_PORT) is used to accept IPv6 connection. An IPv6 capable RDS module continues to use the original RDS_PORT for IPv4 RDS connections. When it needs to communicate with an IPv6 peer, it uses the RDS_CM_PORT to send the connection set up request. ==================== Signed-off-by: -
Ka-Cheong Poon authored
There are many data structures (RDS socket options) used by RDS apps which use a 32 bit integer to store IP address. To support IPv6, struct in6_addr needs to be used. To ensure backward compatibility, a new data structure is introduced for each of those data structures which use a 32 bit integer to represent an IP address. And new socket options are introduced to use those new structures. This means that existing apps should work without a problem with the new RDS module. For apps which want to use IPv6, those new data structures and socket options can be used. IPv4 mapped address is used to represent IPv4 address in the new data structures. v4: Revert changes to SO_RDS_TRANSPORT Signed-off-by:
Ka-Cheong Poon <ka-cheong.poon@oracle.com> Acked-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by:
-
Ka-Cheong Poon authored
This patch enables RDS to use IPv6 addresses. For RDS/TCP, the listener is now an IPv6 endpoint which accepts both IPv4 and IPv6 connection requests. RDS/RDMA/IB uses a private data (struct rds_ib_connect_private) exchange between endpoints at RDS connection establishment time to support RDMA. This private data exchange uses a 32 bit integer to represent an IP address. This needs to be changed in order to support IPv6. A new private data struct rds6_ib_connect_private is introduced to handle this. To ensure backward compatibility, an IPv6 capable RDS stack uses another RDMA listener port (RDS_CM_PORT) to accept IPv6 connection. And it continues to use the original RDS_PORT for IPv4 RDS connections. When it needs to communicate with an IPv6 peer, it uses the RDS_CM_PORT to send the connection set up request. v5: Fixed syntax problem (David Miller). v4: Changed port history comments in rds.h (Sowmini Varadhan). v3: Added support to set up IPv4 connection using mapped address (David Miller). Added support to set up connection between link local and non-link addresses. Various review comments from Santosh Shilimkar and Sowmini Varadhan. v2: Fixed bound and peer address scope mismatched issue. Added back rds_connect() IPv6 changes. Signed-off-by: -
Ka-Cheong Poon authored
This patch changes the internal representation of an IP address to use struct in6_addr. IPv4 address is stored as an IPv4 mapped address. All the functions which take an IP address as argument are also changed to use struct in6_addr. But RDS socket layer is not modified such that it still does not accept IPv6 address from an application. And RDS layer does not accept nor initiate IPv6 connections. v2: Fixed sparse warnings. Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== sched: introduce chain templates support with offloading to mlxsw For the TC clsact offload these days, some of HW drivers need to hold a magic ball. The reason is, with the first inserted rule inside HW they need to guess what fields will be used for the matching. If later on this guess proves to be wrong and user adds a filter with a different field to match, there's a problem. Mlxsw resolves it now with couple of patterns. Those try to cover as many match fields as possible. This aproach is far from optimal, both performance-wise and scale-wise. Also, there is a combination of filters that in certain order won't succeed. Most of the time, when user inserts filters in chain, he knows right away how the filters are going to look like - what type and option will they have. For example, he knows that he will only insert filters of type flower matching destination IP address. He can specify a template that would cover all the filters in the chain. This patchset is providing the possibility to user to provide such template to kernel and propagate it all the way down to device drivers. See the examples below. Create dummy device with clsact first: There is no chain present by by default: Add chain number 11 by explicit command: chain parent ffff: chain 11 Add filter to chain number 12 which does not exist. That will create implicit chain 12: chain parent ffff: chain 11 chain parent ffff: chain 12 Delete both chains: Add a chain with template of type flower allowing to insert rules matching on last 2 bytes of destination mac address: The chain with template is now showed in the list: chain parent ffff: flower chain 0 dst_mac 00:00:00:00:00:00/00:00:00:00:ff:ff eth_type ipv4 Add another chain (number 22) with template: chain parent ffff: flower chain 0 dst_mac 00:00:00:00:00:00/00:00:00:00:ff:ff eth_type ipv4 chain parent ffff: flower chain 22 eth_type ipv4 dst_ip 0.0.0.0/16 Add a filter that fits the template: Addition of filters that does not fit the template would fail: Error: cls_flower: Mask does not fit the template. We have an error talking to the kernel, -1 Error: cls_flower: Mask does not fit the template. We have an error talking to the kernel, -1 Additions of filters to chain 22: Error: cls_flower: Mask does not fit the template. We have an error talking to the kernel, -1 Error: cls_flower: Mask does not fit the template. We have an error talking to the kernel, -1 --- v3->v4: - patch 2: - new patch - patch 3: - new patch, derived from the previous v3 chaintemplate obj patch - patch 4: - only templates part as chains creation/deletion is now a separate patch - don't pass template priv as arg of "change" op - patch 6: - rebased on top of flower cvlan patch and ip tos/ttl patch - patch 7: - templave priv is no longer passed as an arg to "change" op - patch 11: - split from the originally single patch - patch 12: - split from the originally single patch v2->v3: - patch 7: - rebase on top of the reoffload patchset - patch 8: - rebase on top of the reoffload patchset v1->v2: - patch 8: - remove leftover extack arg in fl_hw_create_tmplt() ==================== Signed-off-by: -
Jiri Pirko authored
Add basic sanity tests for TC chain templates. Signed-off-by:
-
Jiri Pirko authored
Add basic sanity tests for TC chains. Signed-off-by:
-
Jiri Pirko authored
The shared block support is only needed for tc_shblock.sh. No need to require that for other test. Signed-off-by:
-
Jiri Pirko authored
Since cld_flower provides information about the filter template for specific chain, use this information in order to prepare a region. Use the template to find out what elements are going to be used and pass that down to mlxsw_sp_acl_tcam_group_add(). Later on, when the first filter is inserted, the mlxsw_sp_acl_tcam_group_use_patterns() function would use this element usage information instead of looking up a pattern. Signed-off-by:
-
Jiri Pirko authored
Introduce a couple of flower offload commands in order to propagate template creation/destruction events down to device drivers. Drivers may use this information to prepare HW in an optimal way for future filter insertions. Signed-off-by:
-
Jiri Pirko authored
Use the previously introduced template extension and implement callback to create, destroy and dump chain template. The existing parsing and dumping functions are re-used. Also, check if newly added filters fit the template if it is set. Signed-off-by:
-
Jiri Pirko authored
This function is going to be used for templates as well, so we need to pass the pointer separately. Signed-off-by:
-
Jiri Pirko authored
Push key/mask dumping from fl_dump() into a separate function fl_dump_key(), that will be reused for template dumping. Signed-off-by:
-
