summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* tcp: avoid possible arithmetic overflowsEric Dumazet2014-09-225-14/+23
| | | | | | | | | | | | | | icsk_rto is a 32bit field, and icsk_backoff can reach 15 by default, or more if some sysctl (eg tcp_retries2) are changed. Better use 64bit to perform icsk_rto << icsk_backoff operations As Joe Perches suggested, add a helper for this. Yuchung spotted the tcp_v4_err() case. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* ipv6: mld: answer mldv2 queries with mldv1 reports in mldv1 fallbackDaniel Borkmann2014-09-222-11/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC2710 (MLDv1), section 3.7. says: The length of a received MLD message is computed by taking the IPv6 Payload Length value and subtracting the length of any IPv6 extension headers present between the IPv6 header and the MLD message. If that length is greater than 24 octets, that indicates that there are other fields present *beyond* the fields described above, perhaps belonging to a *future backwards-compatible* version of MLD. An implementation of the version of MLD specified in this document *MUST NOT* send an MLD message longer than 24 octets and MUST ignore anything past the first 24 octets of a received MLD message. RFC3810 (MLDv2), section 8.2.1. states for *listeners* regarding presence of MLDv1 routers: In order to be compatible with MLDv1 routers, MLDv2 hosts MUST operate in version 1 compatibility mode. [...] When Host Compatibility Mode is MLDv2, a host acts using the MLDv2 protocol on that interface. When Host Compatibility Mode is MLDv1, a host acts in MLDv1 compatibility mode, using *only* the MLDv1 protocol, on that interface. [...] While section 8.3.1. specifies *router* behaviour regarding presence of MLDv1 routers: MLDv2 routers may be placed on a network where there is at least one MLDv1 router. The following requirements apply: If an MLDv1 router is present on the link, the Querier MUST use the *lowest* version of MLD present on the network. This must be administratively assured. Routers that desire to be compatible with MLDv1 MUST have a configuration option to act in MLDv1 mode; if an MLDv1 router is present on the link, the system administrator must explicitly configure all MLDv2 routers to act in MLDv1 mode. When in MLDv1 mode, the Querier MUST send periodic General Queries truncated at the Multicast Address field (i.e., 24 bytes long), and SHOULD also warn about receiving an MLDv2 Query (such warnings must be rate-limited). The Querier MUST also fill in the Maximum Response Delay in the Maximum Response Code field, i.e., the exponential algorithm described in section 5.1.3. is not used. [...] That means that we should not get queries from different versions of MLD. When there's a MLDv1 router present, MLDv2 enforces truncation and MRC == MRD (both fields are overlapping within the 24 octet range). Section 8.3.2. specifies behaviour in the presence of MLDv1 multicast address *listeners*: MLDv2 routers may be placed on a network where there are hosts that have not yet been upgraded to MLDv2. In order to be compatible with MLDv1 hosts, MLDv2 routers MUST operate in version 1 compatibility mode. MLDv2 routers keep a compatibility mode per multicast address record. The compatibility mode of a multicast address is determined from the Multicast Address Compatibility Mode variable, which can be in one of the two following states: MLDv1 or MLDv2. The Multicast Address Compatibility Mode of a multicast address record is set to MLDv1 whenever an MLDv1 Multicast Listener Report is *received* for that multicast address. At the same time, the Older Version Host Present timer for the multicast address is set to Older Version Host Present Timeout seconds. The timer is re-set whenever a new MLDv1 Report is received for that multicast address. If the Older Version Host Present timer expires, the router switches back to Multicast Address Compatibility Mode of MLDv2 for that multicast address. [...] That means, what can happen is the following scenario, that hosts can act in MLDv1 compatibility mode when they previously have received an MLDv1 query (or, simply operate in MLDv1 mode-only); and at the same time, an MLDv2 router could start up and transmits MLDv2 startup query messages while being unaware of the current operational mode. Given RFC2710, section 3.7 we would need to answer to that with an MLDv1 listener report, so that the router according to RFC3810, section 8.3.2. would receive that and internally switch to MLDv1 compatibility as well. Right now, I believe since the initial implementation of MLDv2, Linux hosts would just silently drop such MLDv2 queries instead of replying with an MLDv1 listener report, which would prevent a MLDv2 router going into fallback mode (until it receives other MLDv1 queries). Since the mapping of MRC to MRD in exactly such cases can make use of the exponential algorithm from 5.1.3, we cannot [strictly speaking] be aware in MLDv1 of the encoding in MRC, it seems also not mentioned by the RFC. Since encodings are the same up to 32767, assume in such a situation this value as a hard upper limit we would clamp. We have asked one of the RFC authors on that regard, and he mentioned that there seem not to be any implementations that make use of that exponential algorithm on startup messages. In any case, this patch fixes this MLD interoperability issue. Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: bpf: fix compiler warnings in test_bpfAlexei Starovoitov2014-09-221-2/+2
| | | | | | | | | | | | | | | | | old gcc 4.2 used by avr32 architecture produces warnings: lib/test_bpf.c:1741: warning: integer constant is too large for 'long' type lib/test_bpf.c:1741: warning: integer constant is too large for 'long' type lib/test_bpf.c: In function '__run_one': lib/test_bpf.c:1897: warning: 'ret' may be used uninitialized in this function silence these warnings. Fixes: 02ab695bb37e ("net: filter: add "load 64-bit immediate" eBPF instruction") Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com> Acked-by: Daniel Borkmann <dborkman@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: sched: cls_u32 changes to knode must appear atomic to readersJohn Fastabend2014-09-221-9/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changes to the cls_u32 classifier must appear atomic to the readers. Before this patch if a change is requested for both the exts and ifindex, first the ifindex is updated then the exts with tcf_exts_change(). This opens a small window where a reader can have a exts chain with an incorrect ifindex. This violates the the RCU semantics. Here we resolve this by always passing u32_set_parms() a copy of the tc_u_knode to work on and then inserting it into the hash table after the updates have been successfully applied. Tested with the following short script: #tc filter add dev p3p2 parent 8001:0 protocol ip prio 99 handle 1: \ u32 divisor 256 #tc filter add dev p3p2 parent 8001:0 protocol ip prio 99 \ u32 link 1: hashkey mask ffffff00 at 12 \ match ip src 192.168.8.0/2 #tc filter add dev p3p2 parent 8001:0 protocol ip prio 102 \ handle 1::10 u32 classid 1:2 ht 1: \ match ip src 192.168.8.0/8 match ip tos 0x0a 1e #tc filter change dev p3p2 parent 8001:0 protocol ip prio 102 \ handle 1::10 u32 classid 1:2 ht 1: \ match ip src 1.1.0.0/8 match ip tos 0x0b 1e CC: Eric Dumazet <edumazet@google.com> CC: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: cls_u32: fix missed pcpu_success free_percpuJohn Fastabend2014-09-221-0/+13
| | | | | | | | | This fixes a missed free_percpu in the unwind code path and when keys are destroyed. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bonding: remove the unnecessary notes for bond_xmit_broadcast()dingtianhong2014-09-221-1/+0
| | | | | Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bonding: slight optimization for bond_xmit_roundrobin()dingtianhong2014-09-221-1/+1
| | | | | | | | When the slave is the curr_active_slave, no need to check whether the slave is active or not, it is always active. Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* udp: Need to make ip6_udp_tunnel.c have GPL licenseTom Herbert2014-09-221-0/+2
| | | | | | | | | | | | | Unable to load various tunneling modules without this: [ 80.679049] fou: Unknown symbol udp_sock_create6 (err 0) [ 91.439939] ip6_udp_tunnel: Unknown symbol ip6_local_out (err 0) [ 91.439954] ip6_udp_tunnel: Unknown symbol __put_net (err 0) [ 91.457792] vxlan: Unknown symbol udp_sock_create6 (err 0) [ 91.457831] vxlan: Unknown symbol udp_tunnel6_xmit_skb (err 0) Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'be2net-next'David S. Miller2014-09-225-41/+90
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sathya Perla says: ==================== be2net: patch set Patches 1 and 2 fix sparse warnings (static declaration needed and endian declaration needed) introduced by the earlier patch set. Patches 3 and 4 add 20G/40G speed reporting via ethtool for the Skyhawk-R chip. Patches 5 to 12 fix various style issues and checkpatch warnings in the driver such as: - removing unnecessary return statements in void routines - adding needed blank lines after a declaration block - deleting multiple blank lines - inserting a blank line after a function/struct definition - removing space after typecast - fixing multiple assignments on a single line - fixing alignment on a line wrap ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * be2net: fix alignment on line wrapKalesh AP2014-09-223-10/+11
| | | | | | | | | | | | | | | | | | This patch fixes alignment whereever it doesn't match the open parenthesis alignment. Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * be2net: remove multiple assignments on a single lineKalesh AP2014-09-223-8/+12
| | | | | | | | | | | | | | | | | | This patch removes multiple assignments on a single line as warned by checkpatch. Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * be2net: remove space after typecastsKalesh AP2014-09-222-5/+5
| | | | | | | | | | | | | | This patch removes unnecessary spaces after typecasts as per checkpatch warnings. Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * be2net: remove unnecessary blank lines after an open braceKalesh AP2014-09-222-5/+0
| | | | | | | | | | | | | | | | This patch fixes checkpatch warnings about blank lines after an open brace '{'. Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * be2net: insert a blank line after function/struct//enum definitionsKalesh AP2014-09-222-0/+5
| | | | | | | | | | | | | | | | | | This patch inserts a blank line after function/struct/union/enum definitions as per checkpatch warnings. Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * be2net: remove multiple blank linesKalesh AP2014-09-223-4/+0
| | | | | | | | | | | | | | | | | | This patch removes multiple blank lines in the driver as per checkpatch warnings. Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * be2net: add blank line after declarationsKalesh AP2014-09-224-0/+38
| | | | | | | | | | | | | | | | | | This patch fixes checkpatch warnings in be2net by adding a blank line between declaration and code blocks. Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * be2net: remove return statements for void functionsKalesh AP2014-09-222-5/+0
| | | | | | | | | | | | Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * be2net: add speed reporting for 20G-KR interfaceVasundhara Volam2014-09-222-0/+8
| | | | | | | | | | | | | | | | | | This patch adds speed reporting via ethtool for 20G KR2 interface on the Skyhawk-R chip. Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * be2net: add speed reporting for 40G/KR interfaceKalesh AP2014-09-221-0/+7
| | | | | | | | | | | | | | | | | | This patch adds speed reporting via ethtool for 40Gbps KR4 interface on the Skyhawk-R chip. Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * be2net: fix sparse warnings in be_cmd_req_port_type{}Suresh Reddy2014-09-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | This patch fixes a sprase warnings regarding endian declarations introduced by the following commit: fixes: e36edd9 ("be2net: add ethtool "-m" option support") Signed-off-by: Suresh Reddy <Suresh.Reddy@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * be2net: fix a sparse warning in be_cmd_modify_eqd()Kalesh AP2014-09-221-2/+2
|/ | | | | | | | | | | This patch fixes a sparse warning about missing static declaration that was introduced by the following commit: fixes: 936767039cdf ("be2net: send a max of 8 EQs to be_cmd_modify_eqd() on Lancer") Signed-off-by: Kalesh AP <kalesh.purayil@emulex.com> Signed-off-by: Sathya Perla <sathya.perla@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: keep original skb which only needs header checking during software GSOJason Wang2014-09-221-3/+5
| | | | | | | | | | | | | | | | | | | Commit ce93718fb7cdbc064c3000ff59e4d3200bdfa744 ("net: Don't keep around original SKB when we software segment GSO frames") frees the original skb after software GSO even for dodgy gso skbs. This breaks the stream throughput from untrusted sources, since only header checking was done during software GSO instead of a true segmentation. This patch fixes this by freeing the original gso skb only when it was really segmented by software. Fixes ce93718fb7cdbc064c3000ff59e4d3200bdfa744 ("net: Don't keep around original SKB when we software segment GSO frames.") Cc: David S. Miller <davem@davemloft.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: fec: fix code identationNimrod Andy2014-09-221-1/+1
| | | | | | | | | There have extra identation before .skb_copy_to_linear_data_offset(), this patch just remove the identation. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Fugang Duan <B38611@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'dsa-suspend'David S. Miller2014-09-226-0/+296
|\ | | | | | | | | | | | | | | | | | | | | | | | | Florian Fainelli says: ==================== dsa: Broadcom SF2 suspend/resume and WoL This patch add supports for suspend/resume and configuring Wake-on-LAN for Broadcom Starfighter 2 switches. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: bcm_sf2: add support for Wake-on-LANFlorian Fainelli2014-09-222-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order for Wake-on-LAN to work properly, we query the parent network device Wake-on-LAN features and advertise those. Similarly, when configuring Wake-on-LAN on a per-port network interface, we make sure that we do not accept something the master network devices does not support. Finally, we need to maintain a bitmask of the ports enabled for Wake-on-LAN to prevent the suspend() callback from disabling a port that is used for waking up the system. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: add {get, set}_wol callbacks to slave devicesFlorian Fainelli2014-09-222-0/+31
| | | | | | | | | | | | | | | | Allow switch drivers to implement per-port Wake-on-LAN getter and setters. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: bcm_sf2: add suspend/resume callbacksFlorian Fainelli2014-09-221-0/+85
| | | | | | | | | | | | | | | | | | | | | | Implement the suspend/resume callbacks for the Broadcom Starfighter 2 switch driver. Suspending the switch requires masking interrupts and shutting down ports. Resuming the switch requires a software reset since we do not know which power-sate we might be coming from, and re-enabling the physical ports that are used. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: allow switch drivers to implement suspend/resume hooksFlorian Fainelli2014-09-224-0/+119
|/ | | | | | | | | | | | Add an abstraction layer to suspend/resume switch devices, doing the following split: - suspend/resume the slave network devices and their corresponding PHY devices - suspend/resume the switch hardware using switch driver callbacks Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'qlge'David S. Miller2014-09-222-5/+5
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Harish Patil says: ==================== qlge: Fix compilation warning and update maintainers This patch series includes the following set of patches: - Fix the below warning message: qlge_main.c:1754: warning: 'lbq_desc' may be used uninitialized in this function I have made changes according to your earlier feedback: "Please fix this differently. The problem is that the compiler can't see that you've done the !length check at the top of the function, so when it later sees the while (length > 0) loop, it doesn't know that this loop will always execute at least once. Just change that loop to a do { } while() loop and the compiler will be able to see everything." - Update qlge driver maintainers list ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * Update qlge driver maintainers listHarish Patil2014-09-221-3/+3
| | | | | | | | | | Signed-off-by: Harish Patil <harish.patil@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * qlge: Fix compilation warningHarish Patil2014-09-221-2/+2
|/ | | | | | | | Fix the below warning message: qlge_main.c:1754: warning: 'lbq_desc' may be used uninitialized in this function Signed-off-by: Harish Patil <harish.patil@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* am2150: Update nmclan_cs.c to use update PCMCIA APIJeff Kirsher2014-09-221-1/+1
| | | | | | | | | | | | | Resolves compile warning about use of a deprecated function call: drivers/net/ethernet/amd/nmclan_cs.c: In function ‘nmclan_config’: drivers/net/ethernet/amd/nmclan_cs.c:624:3: warning: ‘pcmcia_request_exclusive_irq’ is deprecated (declared at include/pcmcia/ds.h:213) [-Wdeprecated-declarations] ret = pcmcia_request_exclusive_irq(link, mace_interrupt); Updates pcmcia_request_exclusive_irq() to pcmcia_request_irq(). CC: Roger Pao <rpao@paonet.org> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* udp_tunnel: Only build ip6_udp_tunnel.c when IPV6 is selectedAndy Zhou2014-09-191-1/+4
| | | | | | | | | | | | | | | | | | | Functions supplied in ip6_udp_tunnel.c are only needed when IPV6 is selected. When IPV6 is not selected, those functions are stubbed out in udp_tunnel.h. ================================================================== net/ipv6/ip6_udp_tunnel.c:15:5: error: redefinition of 'udp_sock_create6' int udp_sock_create6(struct net *net, struct udp_port_cfg *cfg, In file included from net/ipv6/ip6_udp_tunnel.c:9:0: include/net/udp_tunnel.h:36:19: note: previous definition of 'udp_sock_create6' was here static inline int udp_sock_create6(struct net *net, struct udp_port_cfg *cfg, ================================================================== Fixes: fd384412e udp_tunnel: Seperate ipv6 functions into its own file Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Andy Zhou <azhou@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'master' of ↵David S. Miller2014-09-195-88/+83
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2014-09-18 This series contains updates to ixgbe and ixgbevf. Ethan Zhao cleans up ixgbe and ixgbevf by removing bd_number from the adapter struct because it is not longer useful. Mark fixes ixgbe where if a hardware transmit timestamp is requested, an uninitialized workqueue entry may be scheduled. Added a check for a PTP clock to avoid that. Jacob provides a number of cleanups for ixgbe. Since we may call ixgbe_acquire_msix_vectors() prior to registering our netdevice, we should not use the netdevice specific printk and use e_dev_warn() instead. Similar to how ixgbevf handles acquiring MSI-X vectors, we can return an error code instead of relying on the flag being set. This makes it more clear that we have failed to setup MSI-X mode and will make it easier to consolidate MSI-X related code into a single function. In the case of disabling DCB, it is not an error since we still can function, we just have to let the user know. So use e_dev_warn() instead of e_err(). Added warnings for other features that are disabled when we are without MSI-X support. Cleanup flags that are no longer used or needed. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * ixgbe: remove IXGBE_FLAG_MSI(X)_CAPABLE flagsJacob Keller2014-09-181-2/+0
| | | | | | | | | | | | | | | | | | They were not used, and we don't need them, so we shouldn't bother with keeping values in the flags field that could be misleading. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: add warnings for other disabled features without MSI-X supportJacob Keller2014-09-181-2/+5
| | | | | | | | | | | | | | | | | | When we can't get MSI-X vectors, we disable a few features which require MSI-X vectors. Print warnings just like we do when disabling DCB. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: use e_dev_warn instead of netif_printkJacob Keller2014-09-181-7/+5
| | | | | | | | | | | | | | | | | | | | | | Again, we should not be directly using netif_printk, as we have our own error print routines that we generate. In addition, instead of using an early return we can just use the else block of this one line if statement. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: use e_dev_warn instead of e_err for displaying warningJacob Keller2014-09-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | In this case, disabling DCB is not an error. We can still function, but we just have to let the user know. In addition, since we call this during probe before allocating our netdevice structure, we should use e_dev_warn instead of e_warn. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: determine vector count inside ixgbe_acquire_msix_vectorsJacob Keller2014-09-181-37/+37
| | | | | | | | | | | | | | | | | | | | | | Our calculated v_budget doesn't matter except if we allocate MSI-X vectors. We shouldn't need to calculate this outside of the function, so don't. Instead, only calculate it once we attempt to acquire MSI-X vectors. This helps collocate all of the MSI-X vector code together. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: move msix_entries allocation into ixgbe_acquire_msix_vectorsJacob Keller2014-09-181-11/+13
| | | | | | | | | | | | | | | | | | | | | | We already have to kfree this value if we fail, and this is only part of MSI-X mode, so we should simply allocate the value where we need it. This is cleaner, and makes it a lot more obvious why we are freeing it inside of ixgbe_acquire_msix_vectors. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: return integer from ixgbe_acquire_msix_vectorsJacob Keller2014-09-181-14/+18
| | | | | | | | | | | | | | | | | | | | | | Similar to how ixgbevf handles acquiring MSI-X vectors, we can return an error code instead of relying on the flag being set. This makes it more clear that we have failed to setup MSI-X mode, and also will make it easier to consolidate MSI-X related code all into the single function. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: use e_dev_warn instead of netif_printkJacob Keller2014-09-181-5/+5
| | | | | | | | | | | | | | | | | | | | The netif_printk relies on our netdevice structure to be registered already. We may call ixgbe_acquire_msix_vectors prior to registering our netdevice, so we should not use the netdevice specific printk. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: Do not schedule an uninitialized workqueue entryMark Rustad2014-09-181-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | If a hardware Tx timestamp is requested, an uninitialized workqueue entry may be scheduled, especially on an 82598 adapter. Add a check for a PTP clock to avoid that. Also only apply the unlikely to the first term of the conditional. That will make the rest of the checks be in the cold path. Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Acked-by: Matthew Vick <matthew.vick@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbe: remove useless bd_number from adapter structEthan Zhao2014-09-182-6/+0
| | | | | | | | | | | | | | | | | | | | Because bd_number is not useful anymore, so remove it from adapter struct, or if keep it, we have to fix the boards driven counter bug in ixgbe_remove() and ixgbe_probe() only for trivial debug purpose -- other output is enough. Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * ixgbevf: remove useless bd_number from struct ixgbevf_adapterEthan Zhao2014-09-182-5/+0
| | | | | | | | | | | | | | | | It is useless and buggy, just remove it. Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | Merge branch 'mlx4-next'David S. Miller2014-09-1910-22/+138
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Or Gerlitz says: ==================== mlx4: CQE/EQE stride support This series from Ido Shamay is intended for archs having cache line larger then 64 bytes. Since our CQE/EQEs are generally 64B in those systems, HW will write twice to the same cache line consecutively, causing pipe locks due to he hazard prevention mechanism. For elements in a cyclic buffer, writes are consecutive, so entries smaller than a cache line should be avoided, especially if they are written at a high rate. Reduce consecutive writes to same cache line in CQs/EQs, by allowing the driver to increase the distance between entries so that each will reside in a different cache line. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net/mlx4_en: Add mlx4_en_get_cqe helperIdo Shamay2014-09-194-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function derives the base address of the CQE from the CQE size, and calculates the real CQE context segment in it from the factor (this is like before). Before this change the code used the factor to calculate the base address of the CQE as well. The factor indicates in which segment of the cqe stride the cqe information is located. For 32-byte strides, the segment is 0, and for 64 byte strides, the segment is 1 (bytes 32..63). Using the factor was ok as long as we had only 32 and 64 byte strides. However, with larger strides, the factor is zero, and so cannot be used to calculate the base of the CQE. The helper uses the same method of CQE buffer pulling made by all other components that reads the CQE buffer (mlx4_ib driver and libmlx4). Signed-off-by: Ido Shamay <idos@mellanox.com> Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net/mlx4_core: Cache line EQE size supportIdo Shamay2014-09-191-11/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable mlx4 interrupt handler to work with EQE stride feature, The feature may be enabled when cache line is bigger than 64B. The EQE size will then be the cache line size, and the context segment resides in [0-31] offset. Signed-off-by: Ido Shamay <idos@mellanox.com> Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | net/mlx4_core: Enable CQE/EQE stride supportIdo Shamay2014-09-195-7/+108
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This feature is intended for archs having cache line larger then 64B. Since our CQE/EQEs are generally 64B in those systems, HW will write twice to the same cache line consecutively, causing pipe locks due to he hazard prevention mechanism. For elements in a cyclic buffer, writes are consecutive, so entries smaller than a cache line should be avoided, especially if they are written at a high rate. Reduce consecutive writes to same cache line in CQs/EQs, by allowing the driver to increase the distance between entries so that each will reside in a different cache line. Until the introduction of this feature, there were two types of CQE/EQE: 1. 32B stride and context in the [0-31] segment 2. 64B stride and context in the [32-63] segment This feature introduces two additional types: 3. 128B stride and context in the [0-31] segment (128B cache line) 4. 256B stride and context in the [0-31] segment (256B cache line) Modify the mlx4_core driver to query the device for the CQE/EQE cache line stride capability and to enable that capability when the host cache line size is larger than 64 bytes (supported cache lines are 128B and 256B). The mlx4 IB driver and libmlx4 need not be aware of this change. The PF context behaviour is changed to require this change in VF drivers running on such archs. Signed-off-by: Ido Shamay <idos@mellanox.com> Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: fix sparse warnings in SNMP_UPD_PO_STATS(_BH)Sabrina Dubroca2014-09-191-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ptr used to be a non __percpu pointer (result of a this_cpu_ptr assignment, 7d720c3e4f0c4 ("percpu: add __percpu sparse annotations to net")). Since d25398df59b56 ("net: avoid reloads in SNMP_UPD_PO_STATS"), that's no longer the case, SNMP_UPD_PO_STATS uses this_cpu_add and ptr is now __percpu. Silence sparse warnings by preserving the original type and annotation, and remove the out-of-date comment. warning: incorrect type in initializer (different address spaces) expected unsigned long long *ptr got unsigned long long [noderef] <asn:3>*<noident> warning: incorrect type in initializer (different address spaces) expected void const [noderef] <asn:3>*__vpp_verify got unsigned long long *<noident> warning: incorrect type in initializer (different address spaces) expected void const [noderef] <asn:3>*__vpp_verify got unsigned long long *<noident> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
OpenPOWER on IntegriCloud