summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-06-08Merge branch 'net-add-const-to-mii_phy_ops-structures'David S. Miller
Bhumika Goyal says: ==================== drivers: net: add const to mii_phy_ops structures The object references of mii_phy_ops structures are only stored in the ops field of a mii_phy_def structure. This ops field is of type const. So, mii_phy_ops structures having similar properties can be declared as const. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08drivers: net: emac: add const to mii_phy_ops structuresBhumika Goyal
The object references of mii_phy_ops structures are only stored in the ops field of a mii_phy_def structure. This ops field is of type const. So, mii_phy_ops structures having similar properties can be declared as const. Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08drivers/net/sungem: add const to mii_phy_ops structuresBhumika Goyal
The object references of mii_phy_ops structures are only stored in the ops field of a mii_phy_def structure. This ops field is of type const. So, mii_phy_ops structures having similar properties can be declared as const. Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08Merge branch '1GbE' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue Jeff Kirsher says: ==================== 1GbE Intel Wired LAN Driver Updates 2017-06-07 This series contains a fix for e1000e and igb. Colin Ian King fixes sparse warnings in igb by making functions static. Chris Wilson provides a fix for a previous commit which is causing an issue during suspend "e1000e_pm_suspend()", where we need to run e1000e_pm_thaw() if __e1000_shutdown() is unsuccessful. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08cxgb4: fix to bring link down after adapter crashRahul Lakkireddy
Use PORT_REG for T4 and T5_PORT_REG for > T4 to write to correct register to bring down link during shutdown after adapter crash. Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: ipmr: add getlink supportNikolay Aleksandrov
Currently there's no way to dump the VIF table for an ipmr table other than the default (via proc). This is a major issue when debugging ipmr issues and in general it is good to know which interfaces are configured. This patch adds support for RTM_GETLINK for the ipmr family so we can dump the VIF table and the ipmr table's current config for each table. We're protected by rtnl so no need to acquire RCU or mrt_lock. Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08Merge branch 'mlxsw-Remove-compatibility-with-old-firmware'David S. Miller
Jiri Pirko says: ==================== mlxsw: Remove compatibility with old firmware Up until recently we couldn't enforce a minimal firmware version, which forced us to be compatible with old firmware versions. This patchset removes this code and simplifies the driver. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08mlxsw: spectrum: Pass port argument to module mapping functionsIdo Schimmel
Previous patch made it unnecessary to map ports to modules before we allocate their struct. We can now therefore pass the port struct to these functions, thereby making them consistent with other functions that operate on ports. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08mlxsw: spectrum: Simplify port split flowIdo Schimmel
In commit be94535f9531 ("mlxsw: spectrum: Make split flow match firmware requirements") we had to modify the port split flow to overcome quirks in the device's firmware. This resulted in asymmetrical code with regards to port creation and removal. The problem in the firmware is long gone and since we can now enforce a minimal firmware version, we can simplify the code and make it symmetric again. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08mlxsw: spectrum_router: Mark only first LPM tree as reservedIdo Schimmel
In new firmware versions (that we can now enforce via request_firmware()), only the first LPM tree is reserved and not the first two as in older versions. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08Merge branch 'net-Remove-support-from-bridge-bypass-for-mlxsw-rocker-drivers'David S. Miller
Jiri Pirko says: =================== net: Remove support from bridge bypass for mlxsw/rocker drivers Currently setting bridge port attributes and adding FDBs are done via setting the SELF flag which implies unconsistent offloading model. This patch-set fixes this behavior by making the bridge and drivers which are using it to be totally in sync. This implies several changes: - Offloading bridge flags from the bridge code. - Sending notification about FDB add/del to the software bridge in a similiar way it is done for the hardware externally learned FDBs. By making the offloading model more consistent a cleanup is done in the drivers supporting it. This is done in order to remove un-needed logic related to dump operation which is redundant. First add missing functionality to bridge, then clean up the mlxsw/rocker drivers. v1->v2 - Move bridge-switchdev related stuff to br_switchdev.c as suggested by Nik =================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08rocker: Remove support bridge bypass FDBArkadi Sharshevsky
The FDB add/delete are now done through the notification chain. The FDBs are synced with the bridge and there is no need for extra dumping. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08rocker: Remove support for bypass bridge port attributes/vlan setArkadi Sharshevsky
The bridge port attributes/vlan for mlxsw devices should be set only from bridge code. The vlans are synced totally with the bridge so there is no need to special dump support. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08rocker: Add support for learning FDB through notificationArkadi Sharshevsky
Add support for learning FDB through notification. The driver defers the hardware update via ordered work queue. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08rocker: Change world_ops API and implementation to be switchdev independantArkadi Sharshevsky
Currently the switchdev_trans struct is embedded in the world_ops API. In order to add support for adding FDB via a notfication chain the API should be switchdev independent. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08rocker: Add support for querying supported bridge flagsArkadi Sharshevsky
Add support for querying supported bridge flags. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08rocker: Remove support for bridge FDB learning syncArkadi Sharshevsky
Currently the rocker driver supports an option for disabling syncing the hardware learned FDBs with the software bridge. This behavior breaks the bridge offload model and thus it is removed. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: Remove support for bridge bypass ndos from stacked devicesArkadi Sharshevsky
Remove support for bridge bypass ndos from stacked devices. At this point no driver which supports stack device behavior offload supports operation with SELF flag. The case for upper device is already taken care of in both of the following cases: 1. FDB add/del - driver should check at the notification cb if the stacked device contains his ports. 2. Port attribute - calls switchdev code directly which checks for case of stack device. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08mlxsw: spectrum: Remove support for bridge bypass FDB add/delArkadi Sharshevsky
The FDB add/del are now done through the notification chain. The FDBs are synced with the bridge and there is no need for extra dumping. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08mlxsw: spectrum_switchdev: Add support for learning FDB through notificationArkadi Sharshevsky
Add support for learning FDB through notification. The driver defers the hardware update via ordered work queue. Support for stacked devices is also provided. In case of a successful FDB add a notification is sent back to bridge. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08mlxsw: spectrum_switchdev: Change switchdev notifier APIArkadi Sharshevsky
The current API for sending switchdev notifications implies only FDB add/del. In order to support notification about successful FDB offload the API is changed. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08mlxsw: spectrum: Remove support for bypass bridge port attributes/vlan setArkadi Sharshevsky
The bridge port attributes/vlan for mlxsw devices should be set only from bridge code. The vlans are synced totally with the bridge so there is no need to special dump support. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08mlxsw: spectrum_switchdev: Add support for querying supported bridge flagsArkadi Sharshevsky
Add support for querying supported bridge flags. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08mlxsw: spectrum: Remove support for bridge FDB learning syncArkadi Sharshevsky
Currently the mlxsw driver supports an option for disabling syncing the hardware learned FDBs with the software bridge. This behavior breaks the bridge offload model and thus it is removed. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: bridge: Receive notification about successful FDB offloadArkadi Sharshevsky
When a new static FDB is added to the bridge a notification is sent to the driver for offload. In case of successful offload the driver should notify the bridge back, which in turn should mark the FDB as offloaded. Currently, externally learned is equivalent for being offloaded which is not correct due to the fact that FDBs which are added from user-space are also marked as externally learned. In order to specify if an FDB was successfully offloaded a new flag is introduced. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: bridge: Add support for notifying devices about FDB add/delArkadi Sharshevsky
Currently the bridge doesn't notify the underlying devices about new FDBs learned. The FDB sync is placed on the switchdev notifier chain because devices may potentially learn FDB that are not directly related to their ports, for example: 1. Mixed SW/HW bridge - FDBs that point to the ASICs external devices should be offloaded as CPU traps in order to perform forwarding in slow path. 2. EVPN - Externally learned FDBs for the vtep device. Notification is sent only about static FDB add/del. This is done due to fact that currently this is the only scenario supported by switch drivers. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Reviewed-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: switchdev: Change notifier chain to be atomicArkadi Sharshevsky
In order to use the switchdev notifier chain for FDB sync with the device it has to be changed to atomic. The is done because the bridge can learn new FDBs in atomic context. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: bridge: Add support for calling FDB external learning under rcuArkadi Sharshevsky
This is done as a preparation to moving the switchdev notifier chain to be atomic. The FDB external learning should be called under rtnl or rcu. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: bridge: Add support for offloading port attributesArkadi Sharshevsky
Currently the flood, learning and learning_sync port attributes are offloaded by setting the SELF flag. Add support for offloading the flood and learning attribute through the bridge code. In case of setting an unsupported flag on a offloded port the operation will fail. The learning_sync attribute doesn't have any software representation and cannot be offloaded through the bridge code. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Reviewed-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: switchdev: Add support for querying supported bridge flags by hardwareArkadi Sharshevsky
This is done as a preparation stage before setting the bridge port flags from the bridge code. Currently the device can be queried for the bridge flags state, but the querier cannot distinguish if the flag is disabled or if it is not supported at all. Thus, add new attr and a bit-mask which include information regarding the support on a per-flag basis. Drivers that support bridge offload but not support bridge flags should return zeroed bitmask. Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08Merge branch 'dsa-add-cross-chip-VLAN-support'David S. Miller
Vivien Didelot says: ==================== net: dsa: add cross-chip VLAN support The current code in DSA does not support cross-chip VLAN. This means that in a multi-chip environment such as this one (similar to ZII Rev B) [CPU].................... (mdio) (eth0) | : : : _|_____ _______ _______ [__sw0__]--[__sw1__]--[__sw2__] | | | | | | | | | v v v v v v v v v p1 p2 p3 p4 p5 p6 p7 p8 p9 adding a VLAN to p9 won't be enough to reach the CPU, until at least one port of sw0 and sw1 join the VLAN as well and become aware of the VID. This patchset makes the DSA core program the VLAN on the CPU and DSA links itself, which brings seamlessly cross-chip VLAN support to DSA. With this series applied*, the hardware VLAN tables of a 3-switch setup look like this after adding a VLAN to only one port of the end switch: # cat /sys/class/net/br0/bridge/default_pvid 42 # cat /sys/kernel/debug/mv88e6xxx/sw{0,1,2}/vtu # ip link set up master br0 dev lan6 # cat /sys/kernel/debug/mv88e6xxx/sw{0,1,2}/vtu VID FID SID 0 1 2 3 4 5 6 42 1 0 x x x x x = = VID FID SID 0 1 2 3 4 5 6 42 1 0 x x x x x = = VID FID SID 0 1 2 3 4 5 6 7 8 9 42 1 0 u x x x x x x x x = ('x' is excluded, 'u' is untagged, '=' is unmodified DSA and CPU ports.) Completely removing a VLAN entry (which is currently the responsibility of drivers anyway) is not supported yet since it requires some caching. (*) the output is shown from this out-of-tree debugfs patch: https://github.com/vivien/linux/commit/7b61a684b9d6b6a499135a587c7f62a1fddceb8b.patch Changes in v2: - canonical incrementation (port++ instead of ++port) - check CPU and DSA ports before purging a VLAN - add Reviewed-by tags ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: dsa: mv88e6xxx: do not skip ports on VLAN delVivien Didelot
The mv88e6xxx driver currently tries to be smart and remove by itself a VLAN entry from the VTU when the driven switch sees no user ports as members of the VLAN. This is bad in a multi-chip switch fabric, since a chip in between others may have no bridge port members, but still needs to be aware of the VID in order to correctly pass frames in the data path. Now that the DSA core explicitly manages DSA and CPU ports, do not skip them when checking remaining VLAN members. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: dsa: mv88e6xxx: exclude all ports in new VLANVivien Didelot
Now that the DSA core adds the CPU and DSA ports itself to the new VLAN entry, there is no need to include them as members of this VLAN when initializing a new VTU entry. As of now, initialize a new VTU entry with all ports excluded. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: dsa: add CPU and DSA ports as VLAN membersVivien Didelot
In a multi-chip switch fabric, it is currently the responsibility of the driver to add the CPU or DSA (interconnecting chips together) ports as members of a new VLAN entry. This makes the drivers more complicated. We want the DSA drivers to be stupid and the DSA core being the one responsible for caring about the abstracted switch logic and topology. Make the DSA core program the CPU and DSA ports as part of the VLAN. This makes all chips of the data path to be aware of VIDs spanning the the whole fabric and thus, seamlessly add support for cross-chip VLAN. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: dsa: check VLAN capability of every switchVivien Didelot
Now that the VLAN object is propagated to every switch chip of the switch fabric, we can easily ensure that they all support the required VLAN operations before modifying an entry on a single switch. To achieve that, remove the condition skipping other target switches, and add a bitmap of VLAN members, eventually containing the target port, if we are programming the switch target. This will allow us to easily add other VLAN members, such as the DSA or CPU ports (to introduce cross-chip VLAN support) or the other port members if we want to reduce hardware accesses later. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: dsa: mv88e6xxx: define membership on VLAN addVivien Didelot
Define the target port membership of the VLAN entry in mv88e6xxx_port_vlan_add where ds is scoped. Allow the DSA core to call later the port_vlan_add operation for CPU or DSA ports, by using the Unmodified membership for these ports, as in the current behavior. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08Merge tag 'rxrpc-rewrite-20170607-v2' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs David Howells says: ==================== rxrpc: Tx length parameter Here's a set of patches that allows someone initiating a client call with AF_RXRPC to indicate upfront the total amount of data that will be transmitted. This will allow AF_RXRPC to encrypt directly from source buffer to packet rather than having to copy into the buffer and only encrypt when it's full (the encrypted portion of the packet starts with a length and so we can't encrypt until we know what the length will be). The three patches are: (1) Provide a means of finding out what control message types are actually supported. EINVAL is reported if an unsupported cmsg type is seen, so we don't want to set the new cmsg unless we know it will be accepted. (2) Consolidate some stuff into a struct to reduce the parameter count on the function that parses the cmsg buffer. (3) Introduce the RXRPC_TX_LENGTH cmsg. This can be provided on the first sendmsg() that contributes data to a client call request or a service call reply. If provided, the user must provide exactly that amount of data or an error will be incurred. Changes in version 2: (*) struct rxrpc_send_params::tx_total_len should be s64 not u64. Thanks to Julia Lawall for reporting this. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08Merge branch 'qrtr-features'David S. Miller
Bjorn Andersson says: ==================== Missing QRTR features The QMUX specification covers packet routing as well as service life cycle and discovery. The current implementation of qrtr supports the prior part, but in order to fully implement service management on-top a few more parts are needed. The first patch in the series serves the purpose of reducing duplication in patch two and three. The second and third patch adds two qrtr-level notifications required by the specification, in order to notify local and remote service controllers about dying clients. The last patch serves the purpose of notifying local clients about the presence of a local service register, allowing them to register services as well as querying for remote registered services. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: qrtr: Inform open sockets about new controllerBjorn Andersson
As the higher level communication only deals with "services" the a service directory is required to keep track of local and remote services. In order for qrtr clients to be informed about when the service directory implementation is available some event needs to be passed to them. Rather than introducing support for broadcasting such a message in-band to all open local sockets we flag each socket with ENETRESET, as there are no other expected operations that would benefit from having support from locally broadcasting messages. Cc: Courtney Cavin <ccavin@gmail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: qrtr: Broadcast DEL_CLIENT message when endpoint is closedBjorn Andersson
Per the QMUXv2 protocol specificiation a DEL_CLIENT message should be broadcasted when an endpoint is disconnected. The protocol specification does suggest that the router can keep track of which nodes the endpoint has been communicating with to not wake up sleeping remotes unecessarily, but implementation of this suggestion is left for the future. Cc: Courtney Cavin <ccavin@gmail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: qrtr: Inject BYE on remote terminationBjorn Andersson
Per the QMUX protocol specification a terminating node can send a BYE control message to signal that the link is going down, upon receiving this all information about remote services should be discarded and local clients should be notified. In the event that the link was brought down abruptly the router is supposed to act like a BYE message has arrived. As there is no harm in receiving an extra BYE from the remote this patch implements the latter by injecting a BYE when the link to the remote is unregistered. The name service will receive the BYE and can implement the notification to the local clients. Cc: Courtney Cavin <ccavin@gmail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: qrtr: Refactor packet allocationBjorn Andersson
Extract the allocation and filling in the control message header fields to a separate function in order to reuse this in subsequent patches. Cc: Courtney Cavin <ccavin@gmail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08mISDN: remove unnecessary variable assignmentsGustavo A. R. Silva
Remove unnecessary variable assignments. Addresses-Coverity-ID: 1226917 Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08tcp: add TCPMemoryPressuresChrono counterEric Dumazet
DRAM supply shortage and poor memory pressure tracking in TCP stack makes any change in SO_SNDBUF/SO_RCVBUF (or equivalent autotuning limits) and tcp_mem[] quite hazardous. TCPMemoryPressures SNMP counter is an indication of tcp_mem sysctl limits being hit, but only tracking number of transitions. If TCP stack behavior under stress was perfect : 1) It would maintain memory usage close to the limit. 2) Memory pressure state would be entered for short times. We certainly prefer 100 events lasting 10ms compared to one event lasting 200 seconds. This patch adds a new SNMP counter tracking cumulative duration of memory pressure events, given in ms units. $ cat /proc/sys/net/ipv4/tcp_mem 3088 4117 6176 $ grep TCP /proc/net/sockstat TCP: inuse 180 orphan 0 tw 2 alloc 234 mem 4140 $ nstat -n ; sleep 10 ; nstat |grep Pressure TcpExtTCPMemoryPressures 1700 TcpExtTCPMemoryPressuresChrono 5209 v2: Used EXPORT_SYMBOL_GPL() instead of EXPORT_SYMBOL() as David instructed. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08Merge branch 'tcp-Namespaceify-3-sysctls'David S. Miller
Eric Dumazet says: ==================== tcp: Namespaceify 3 sysctls Move tcp_sack, tcp_window_scaling and tcp_timestamps sysctls to network namespaces. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08tcp: Namespaceify sysctl_tcp_timestampsEric Dumazet
Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08tcp: Namespaceify sysctl_tcp_window_scalingEric Dumazet
Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08tcp: Namespaceify sysctl_tcp_sackEric Dumazet
Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08tcp: add a struct net parameter to tcp_parse_options()Eric Dumazet
We want to move some TCP sysctls to net namespaces in the future. tcp_window_scaling, tcp_sack and tcp_timestamps being fetched from tcp_parse_options(), we need to pass an extra parameter. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-08net: propagate tc filter chain index down the ndo_setup_tc callJiri Pirko
We need to push the chain index down to the drivers, so they have the information to which chain the rule belongs. For now, no driver supports multichain offload, so only chain 0 is supported. This is needed to prevent chain squashes during offload for now. Later this will be used to implement multichain offload. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>