- 10 Aug, 2016 1 commit
-
-
Julia Lawall authored
The xfrm_replay structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com>
-
- 09 Aug, 2016 4 commits
-
-
Niklas Söderlund authored
The interface would not function after the system had been woken up after have been suspended (echo mem > /sys/power/state) cycle. The reason for this is that all device registers have been reset to its default values. This patch adds sleep suspend and resume functions that detached the interface at suspend and restore the registers and reattach the interface at resume. Only the registers that are only configured at probe time needs to be explicitly restored by the resume handler. All other registers are reconfigured by either reopening the device in the resume handler (if the device was running when the system was suspended) or when the interface is opened by a user at a later time. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Julia Lawall authored
The b53_io_ops structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David Ahern authored
After commit 0ddcf43d ("ipv4: FIB Local/MAIN table collapse") fib_local is set but not used. Remove it. Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
-
Guillaume Nault authored
Userspace programs generally need to know the name of the ppp devices they create. Both ioctl and rtnl interfaces use the ppp<suffix> sheme to name them. But although the suffix used by the ioctl interface can be known by userspace (it's the PPP unit identifier returned by the PPPIOCGUNIT ioctl), the one used by the rtnl is only known by the kernel. This patch brings more consistency between ioctl and rtnl based ppp devices by generating device names using the PPP unit identifer as suffix in both cases. This way, userspace can always infer the name of the devices they create. Signed-off-by:
Guillaume Nault <g.nault@alphalink.fr> Signed-off-by:
-
- 08 Aug, 2016 35 commits
-
-
Nicolas Iooss authored
This is helpful to detect at compile-time errors related to format strings. Signed-off-by:
Nicolas Iooss <nicolas.iooss_linux@m4x.org> Acked-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by:
-
Raju Lakkaraju authored
Hello, I added all review comments and re-sending for review. >From a5017f5878a92d2acec86a6a29b1498c457cb73a Mon Sep 17 00:00:00 2001 From: Nagaraju Lakkaraju <Raju.Lakkaraju@microsemi.com> Date: Wed, 3 Aug 2016 18:28:24 +0530 Subject: [PATCH v2] net: phy: Add drivers for Microsemi PHYs Signed-off-by:
Nagaraju Lakkaraju <Raju.Lakkaraju@microsemi.com> Signed-off-by:
-
Julia Lawall authored
Use of_property_read_bool to check for the existence of a property. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression e1,e2,x; @@ - if (of_get_property(e1,e2,NULL)) - x = true; - else - x = false; + x = of_property_read_bool(e1,e2); // </smpl> Signed-off-by:
-
Haiyang Zhang authored
On Hyper-V host 2016 and later, VMs gets an event message of the physical link speed when vSwitch is changed. This patch handles this message, so the updated link speed can be reported by ethtool. Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Haiyang Zhang authored
The physical link speed value will be reported by ethtool command. The real speed is available from Windows 2016 host or later. Signed-off-by:
-
Grygorii Strashko authored
The struct cpdma_desc_pool->used_desc field can be safely removed from CPDMA driver (and hot patch) because used_descs counter is used just for pool consistency check at CPDMA deinitialization and now this check can be re-implemnted using gen_pool_size(pool->gen_pool) != gen_pool_avail(pool->gen_pool). More over, this will allow to get rid of warnings in cpdma_desc_pool_destro()-> WARN_ON(pool->used_desc) which may happen because the used_descs is used unprotected, since CPDMA has been switched to use genalloc, and may get wrong values on SMP. Hence, remove used_desc from struct cpdma_desc_pool. Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by:
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by:
-
Michal Soltys authored
The code using this variable has been commented out in the past as it was causing issues in upperlimited link-sharing scenarios. Signed-off-by:
Michal Soltys <soltys@ziu.info> Signed-off-by:
-
Michal Soltys authored
This patch simplifies how we update fsc and calculate vt from it - while keeping the expected functionality identical with how hfsc behaves curently. It also fixes a certain issue introduced with a very old patch. The idea is, that instead of correcting cl_vt before fsc curve update (rtsc_min) and correcting cl_vt after calculation (rtsc_y2x) to keep cl_vt local to the current period - we can simply rely on virtual times and curve values always being in sync - analogously to how rsc and usc function, except that we use virtual time here. Why hasn't it been done since the beginning this way ? The likely scenario (basing on the code trying to correct curves whenever possible) was to keep the virtual times as small as possible - as they have tendency to "gallop" forward whenever their siblings and other fair sharing subtrees are idling. On top of that, current code is subtly bugged, so cumulative time (without any corrections) is always kept and used in init_vf() when a new backlog period begins (using cl_cvtoff). Is cumulative value safe ? Generally yes, though corner cases are easy to create. For example consider: 1gbit interface some 100kbit leaf, everything else idle With current tick (64ns) 1s is 15625000 ticks, but the leaf is alone and it's virtual time, so in reality it's 10000 times more. ITOW 38 bits are needed to hold 1 second. 54 - 1 day, 59 - 1 month, 63 - 1 year (all logarithms rounded up). It's getting somewhat dangerous, but also requires setup excusing this kind of values not mentioning permanently backlogged class for a year. In near most extreme case (10gbit, 10kbit leaf), we have "enough" to hold ~13.6 days in 64 bits. Well, the issue remains mostly theoretical and cl_cvtoff has been working fine for all those years. Sensible configuration are de-facto immune to this issue, and not so sensible can solve it with a cronjob and its period inversely proportional to the insanity of such setup =) Now let's explain the subtle bug mentioned earlier. The issue is related to how offsets are kept and how we calculate virtual times and update fair service curve(s). The issue itself is subtle, but easy to observe with long m1 segments. It was introduced in rather old patch: Commit 99296150: "[NET_SCHED]: O(1) children vtoff adjustment in HFSC scheduler" (available in git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git) Originally when a new backlog period was started, cl_vtoff of each sibling was updated with cl_cvtmax from past period - naturally moving all cl_vt to proper starting point. That patch adjusted it so cumulative offset is kept in the parent, and there is no need for traversing the list (as any subsequent child activation derives new vt from already active sibling(s)). But with this change, cl_vtoff (of each sibling) is no longer persistent across the inactivity periods, as it's calculated from parent's cl_cvtoff on a new backlog period, conflicting with the following curve correction from the previous period: if (cl->cl_virtual.x == vt) { cl->cl_virtual.x -= cl->cl_vtoff; cl->cl_vtoff = 0; } This essentially tries to keep curve as if it was local to the period and resets cl_vtoff (cumulative vt offset of the class) to 0 when possible (read: when we have an intersection or if a new curve is below the old one). But then it's recalculated from cl_cvtoff on next active period. Then rtsc_min() call preceding the above if() doesn't really do what we expect it to do in such scenario - as it calculates the minimum of corrected curve (from the previous backlog period) and the new uncorrected curve (with offset derived from cl_cvtoff). Example: tc class add dev $ife parent 1:0 classid 1:1 hfsc ls m2 100mbit ul m2 100mbit tc class add dev $ife parent 1:1 classid 1:10 hfsc ls m1 80mbit d 10s m2 20mbit tc class add dev $ife parent 1:1 classid 1:11 hfsc ls m2 20mbit start B, keep it backlogged, let it run 6s (30s worth of vt as A is idle) pause B briefly to force cl_cvtoff update in parent (whole 1:1 going idle) start A, let it run 10s pause A briefly to force rtsc_min() At this point we would expect A to continue at 20mbit after a brief moment of 80mbit. But instead A will use 80mbit for full 10s again. It's the effect of first correcting A (during 'start A'), and then - after unpausing - calculating rtsc_min() from old corrected and new uncorrected curve. The patch fixes this bug and keepis vt and fsc in sync (virtual times are cumulative, not local to the backlog period). Signed-off-by:
-
Wei Yongjun authored
spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Signed-off-by:
Wei Yongjun <weiyj.lk@gmail.com> Acked-by:
Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by:
-
Hangbin Liu authored
Based on RFC3376 5.1 and RFC3810 6.1 If the per-interface listening change that triggers the new report is a filter mode change, then the next [Robustness Variable] State Change Reports will include a Filter Mode Change Record. This applies even if any number of source list changes occur in that period. Old State New State State Change Record Sent --------- --------- ------------------------ INCLUDE (A) EXCLUDE (B) TO_EX (B) EXCLUDE (A) INCLUDE (B) TO_IN (B) So we should not send source-list change if there is a filter-mode change. Here are two scenarios: 1. Group deleted and filter mode is EXCLUDE, which means we need send a TO_IN { }. 2. Not group deleted, but has pcm->crcount, which means we need send a normal filter-mode-change. At the same time, if the type is ALLOW or BLOCK, and have psf->sf_crcount, we stop add records and decrease sf_crcount directly Reference: https://www.ietf.org/mail-archive/web/magma/current/msg01274.htmlSigned-off-by:Hangbin Liu <liuhangbin@gmail.com> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Philippe Reynes authored
The ethtool api {get|set}_settings is deprecated. We move the mvneta driver to new api {get|set}_link_ksettings. We use the generic function phy_ethtool_get_link_ksettings, and update old mvneta_ethtool_set_settings to the new api. Signed-off-by:Philippe Reynes <tremyfr@gmail.com> Signed-off-by:
-
Philippe Reynes authored
The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phy_dev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by:
-
Philippe Reynes authored
There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: -
Philippe Reynes authored
The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phy in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by:
-
Philippe Reynes authored
There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. There was a check on CAP_NET_ADMIN in cvm_oct_set_settings, but this check is already done in dev_ethtool, so no need to repeat it before calling the generic function. Signed-off-by: -
Philippe Reynes authored
The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by:
-
David S. Miller authored
Ivan Vecera says: ==================== bna: remove useless global variables The set removes useless global bnad_list as well as bnad->entry that track a list of driver instances but it is not used anywhere. The associated bnad_list_mutex is removed as well but as it is also used to protect bna_id increment it is necessary to convert bna_id to atomic_t. ==================== Signed-off-by:Ivan Vecera <ivecera@redhat.com>
-
Ivan Vecera authored
Remove global bnad_list_mutex as it is not used anymore. This makes bnad_add_to_list() and bnad_remove_from_list() empty so remove them too. Signed-off-by:
-
Ivan Vecera authored
Change type of bna_id to atomic_t. The bnad_list_mutex is used to prevent a race when bna_id is incremented. After the change the mutex can be removed in the next step. Signed-off-by:
-
Ivan Vecera authored
Remove global variable bnad_list and bnad->list_entry that are used as list of bna driver instances. It is not necessary and useless. Signed-off-by:
-
David S. Miller authored
Uwe Kleine-König says: ==================== net: ipconfig: improve DHCP timeout handling this series teaches the ipconfig code to handle a DHCP reply on eth0 even if a request on eth1 was already sent out. This is a follow fix to 2513dfb8 ("ipconfig: handle case of delayed DHCP server") that dropped a late reply. This makes it possible at all to work with slow DHCP servers at all in some configurations and improves boot speed in general. The first patch is not really necessary, it only helps decoding debug messages when there is more than one device. ==================== Signed-off-by:
-
Uwe Kleine-König authored
Now that ipconfig learned to handle "delayed replies" in the previous commit, there is no reason any more to delay sending a first request per device. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Uwe Kleine-König authored
The dhcp code only waits 1s between sending DHCP requests on different devices and only accepts an answer for the device that sent out the last request. Only the timeout at the end of a loop is increased iteratively which favours only the last device. This makes it impossible to work with a dhcp server that takes little more than 1s connected to a device that is not the last one. Instead of also increasing the inter-device timeout, teach the code to handle delayed replies. To accomplish that, make *ic_dev track the current ic_device instead of the current net_device and adapt all users accordingly. The relevant change then is to reset d to ic_dev on a reply to assert that the followup request goes through the right device. Signed-off-by:
-
Uwe Kleine-König authored
This simplifies understanding what happens when there is more than one device. Signed-off-by:
-
David S. Miller authored
Sathya Perla says: ==================== be2net: patch set Patch 1 fixes the driver to workaournd a bug in the Lancer FW in the vlan-config cmd processing. The FW in some cases clears the vlan-promisc setting even if it cannot apply the vlan filter. The driver has no means of knowing if the vlan-promisc setting has been cleared or not. This patch now explicitly clears the vlan-promisc setting via the RX-Filter cmd and then tries to program the vlan-list. Patch 2 fixes the failure path in the vlan vid add code. The driver currently removes a new vid from the adapter->vids[] array if be_vid_config() returns an error, which occurs when there is an error in HW/FW. This is wrong. After the HW/FW error is recovered from, we need the complete vids[] array to re-program the vlan list. Patch 3 fixes the ndo_set_rx_mode() path to avoid unnecessary multicast list updates to the FW. Each time the ndo_set_rx_mode() routine is called, the driver programs the multicast list in the adapter without checking if there are any changes to the list. This leads to a flood of RX_FILTER cmds when a number of vlan interfaces are configured over the device, as the ndo_ gets called for each vlan interface. To avoid this, we now use __dev_mc_sync() and __dev_uc_sync() API, but only to detect if there is a change in the mc/uc lists. Now that we use this API, the code has to be-designed to issue these API calls for each invocation of the ndo_ call. Patch 4 replaces polling with sleeping in the FW completion path. The ndo_set_rx_mode() and ndo_add/del_vxlan_port() calls may be called with BHs disabled. The driver currently issues the required cmds to the FW in these contexts and polls on completions from the FW, while BHs remain disabled. This can cause either packet loss or packet reception to be delayed on that CPU. This patch defers processing of the above cmds to a separate workqueue. With this change, FW cmds are now issued only in process context. Now that the FW cmds are issued only in process context, they can sleep waiting for a completion instead of polling. ==================== Signed-off-by: -
Sathya Perla authored
The ndo_set_rx_mode() and ndo_add/del_vxlan_port() calls may be called with BHs disabled. The driver currently issues the required cmds to the FW in these contexts and polls on completions from the FW, while BHs remain disabled. This can cause either packet loss or packet reception to be delayed on that CPU. This patch defers processing of the above cmds to a separate workqueue. With this change, FW cmds are now issued only in process context. Now that the FW cmds are issued only in process context, they can sleep waiting for a completion instead of polling. All the spin_lock_bh(mcc_lock) calls are now replaced with mutex calls. Also a new rx_filter_lock is now needed to protect the RX filtering fields like vids[] between be_vlan_add/rem_vid() and __be_set_rx_mode() contexts. Signed-off-by:
Sathya Perla <sathya.perla@broadcom.com> Signed-off-by:
-
Sriharsha Basavapatna authored
Eachtime the ndo_set_rx_mode() routine is called, the driver programs the multicast list in the adapter without checking if there are any changes to the list. This leads to a flood of RX_FILTER cmds when a number of vlan interfaces are configured over the device, as the ndo_ gets called for each vlan interface. To avoid this, we now use __dev_mc_sync() and __dev_uc_sync() API, but only to detect if there is a change in the mc/uc lists. Now that we use this API, the code has to be-designed to issue these API calls for each invocation of the be_set_rx_mode() call. Signed-off-by:
Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Signed-off-by:
-
Sathya Perla authored
The driver currently removes a new vid from the adapter->vids[] array if be_vid_config() returns an error, which occurs when there is an error in HW/FW. This is wrong. After the HW/FW error is recovered from, we need the complete vids[] array to re-program the vlan list. Signed-off-by:
-
Somnath Kotur authored
The Lancer FW has a bug due to which in some cases vlan-promisc setting is cleared eventhough the vlan-list programming did not succeed (via VLAN_CONFIG) cmd. The driver has no way of knowing if the vlan-promisc mode was cleared or not when this cmd fails. To work around this issue, this patch first explicitly clears the vlan-promisc mode via RX_FILTER cmd and then tries to program the vlan list. Signed-off-by:
Somnath Kotur <somnath.kotur@emulex.com> Signed-off-by:
-
Julian Anastasov authored
Admin should be able to set any state. Currently, this fails when lladdr is not changed and state is changed from NUD_CONNECTED to NUD_STALE: ip neigh add 192.168.8.1 lladdr 00:11:22:33:44:55 nud perm dev wlan0 ip neigh show to 192.168.8.1 192.168.8.1 dev wlan0 lladdr 00:11:22:33:44:55 PERMANENT ip neigh change 192.168.8.1 lladdr 00:11:22:33:44:55 nud stale dev wlan0 ip neigh show to 192.168.8.1 192.168.8.1 dev wlan0 lladdr 00:11:22:33:44:55 PERMANENT Problem may be from 2.1.X days. Signed-off-by:
Julian Anastasov <ja@ssi.bg> Reviewed-by:
Chunhui He <hchunhui@mail.ustc.edu.cn> Signed-off-by:
-
Xin Long authored
Commit 52253db9 ("sctp: also point GSO head_skb to the sk when it's available") used event->chunk->head_skb to get the head_skb in sctp_ulpevent_set_owner(). But at that moment, the event->chunk was NULL, as it cloned the skb in sctp_ulpevent_make_rcvmsg(). Therefore, that patch didn't really work. This patch is to move the event->chunk initialization before calling sctp_ulpevent_receive_data() so that it uses event->chunk when it's valid. Fixes: 52253db9 ("sctp: also point GSO head_skb to the sk when it's available") Signed-off-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
pravin shelar authored
vxlan driver has bypass for local vxlan traffic, but that depends on information about all VNIs on local system in vxlan driver. This is not available in case of LWT. Therefore following patch disable encap bypass for LWT vxlan traffic. Fixes: ee122c79 ("vxlan: Flow based tunneling"). Reported-by:
Jakub Libosvar <jlibosva@redhat.com> Signed-off-by:
Pravin B Shelar <pshelar@ovn.org> Acked-by:
Jiri Benc <jbenc@redhat.com> Signed-off-by:
-
pravin shelar authored
LWT user can specify destination as well as source ip address for given tunnel endpoint. But vxlan is ignoring given source ip address. Following patch uses both ip address to route the tunnel packet. This consistent with other LWT implementations, like GENEVE and GRE. Fixes: ee122c79 ("vxlan: Flow based tunneling"). Signed-off-by:
-
David S. Miller authored
Daniel Borkmann says: ==================== Few BPF helper related checksum fixes The set contains three fixes with regards to CHECKSUM_COMPLETE and BPF helper functions. For details please see individual patches. Thanks! v1 -> v2: - Fixed make htmldocs issue reported by kbuild bot. - Rest as is. ==================== Signed-off-by: -
Daniel Borkmann authored
When having skbs on ingress with CHECKSUM_COMPLETE, tc BPF programs don't push rcsum of mac header back in and after BPF run back pull out again as opposed to some other subsystems (ovs, for example). For cases like q-in-q, meaning when a vlan tag for offloading is already present and we're about to push another one, then skb_vlan_push() pushes the inner one into the skb, increasing mac header and skb_postpush_rcsum()'ing the 4 bytes vlan header diff. Likewise, for the reverse operation in skb_vlan_pop() for the case where vlan header needs to be pulled out of the skb, we're decreasing the mac header and skb_postpull_rcsum()'ing the 4 bytes rcsum of the vlan header that was removed. However mangling the rcsum here will lead to hw csum failure for BPF case, since we're pulling or pushing data that was not part of the current rcsum. Changing tc BPF programs in general to push/pull rcsum around BPF_PROG_RUN() is also not really an option since current behaviour is ABI by now, but apart from that would also mean to do quite a bit of useless work in the sense that usually 12 bytes need to be rcsum pushed/pulled also when we don't need to touch this vlan related corner case. One way to fix it would be to push the necessary rcsum fixup down into vlan helpers that are (mostly) slow-path anyway. Fixes: 4e10df9a ("bpf: introduce bpf_skb_vlan_push/pop() helpers") Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
