- 08 Nov, 2016 2 commits
-
-
Sven Eckelmann authored
No caller of batadv_send_skb_to_orig is expecting the results to be -1 (-EPERM) anymore when the skbuff was not consumed. They will instead expect that the skbuff is always consumed. Having such return code filter is therefore not needed anymore. Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
Simon Wunderlich <sw@simonwunderlich.de>
-
Sven Eckelmann authored
Receiving functions in Linux consume the supplied skbuff. Doing the same in the batadv_rx_handler functions makes the behavior more similar to the rest of the Linux network code. Signed-off-by:
-
- 30 Oct, 2016 12 commits
-
-
Sven Eckelmann authored
Sending functions in Linux consume the supplied skbuff. Doing the same in batadv_send_skb_to_orig avoids the hack of returning -1 (-EPERM) to signal the caller that he is responsible for cleaning up the skb. Signed-off-by:
-
Sven Eckelmann authored
Sending functions in Linux consume the supplied skbuff. Doing the same in batadv_frag_send_packet avoids the hack of returning -1 (-EPERM) to signal the caller that he is responsible for cleaning up the skb. Signed-off-by:
-
Sven Eckelmann authored
A failure during the submission also causes dropped packets. batadv_interface_tx should therefore also increase the DROPPED counter for these returns. Signed-off-by:
-
Sven Eckelmann authored
kfree_skb assumes that an skb is dropped after an failure and notes that. consume_skb should be used in non-failure situations. Such information is important for dropmonitor netlink which tells how many packets were dropped and where this drop happened. Signed-off-by:
-
Linus Lüssing authored
With this patch, (re)broadcasting on a specific interfaces is avoided: * No neighbor: There is no need to broadcast on an interface if there is no node behind it. * Single neighbor is source: If there is just one neighbor on an interface and if this neighbor is the one we actually got this broadcast packet from, then we do not need to echo it back. * Single neighbor is originator: If there is just one neighbor on an interface and if this neighbor is the originator of this broadcast packet, then we do not need to echo it back. Goodies for BATMAN V: ("Upgrade your BATMAN IV network to V now to get these for free!") Thanks to the split of OGMv1 into two packet types, OGMv2 and ELP that is, we can now apply the same optimizations stated above to OGMv2 packets, too. Furthermore, with BATMAN V, rebroadcasts can be reduced in certain multi interface cases, too, where BATMAN IV cannot. This is thanks to the removal of the "secondary interface originator" concept in BATMAN V. Signed-off-by:Linus Lüssing <linus.luessing@c0d3.blue> Signed-off-by:
-
Linus Lüssing authored
Instead of latching onto the OGM period, this patch introduces a worker dedicated to multicast TT and TVLV updates. The reasoning is, that upon roaming especially the translation table should be updated timely to minimize connectivity issues. With BATMAN V, the idea is to greatly increase the OGM interval to reduce overhead. Unfortunately, right now this could lead to a bad user experience if multicast traffic is involved. Therefore this patch introduces a fixed 500ms update interval for multicast TT entries and the multicast TVLV. Signed-off-by:
-
Linus Lüssing authored
During broadcast queueing, the skb_reset_mac_header() sets the skb to a place invalid for a MAC header, pointing right into the batman-adv broadcast packet. Luckily, no one seems to actually use eth_hdr(skb) afterwards until batadv_send_skb_packet() resets the header to a valid position again. Therefore removing this unnecessary, weird skb_reset_mac_header() call. Signed-off-by:
-
Linus Lüssing authored
batadv_mcast_mla_list_free() just frees some leftovers of a local feast in batadv_mcast_mla_update(). No lockdep needed as it has nothing to do with bat_priv->mcast.mla_list. Signed-off-by:
-
Linus Lüssing authored
Removing duplicate code. Signed-off-by:
-
Sven Eckelmann authored
Signed-off-by:
Sven Eckelmann <sven.eckelmann@open-mesh.com> Signed-off-by:
-
Sven Eckelmann authored
The genl_ops don't need to be written by anyone and thus can be moved in a ro memory range. Signed-off-by:
-
Sven Eckelmann authored
Fixes: 56989f6d ("genetlink: mark families as __ro_after_init") Fixes: 2ae0f17d ("genetlink: use idr to track families") Signed-off-by:
-
- 29 Oct, 2016 26 commits
-
-
git://git.open-mesh.org/linux-mergeDavid S. Miller authored
Simon Wunderlich says: ==================== This code cleanup patchset includes the following changes (chronological order): - bump version strings, by Simon Wunderlich - README updates/clean up, by Sven Eckelmann (4 patches) - Code clean up and restructuring by Sven Eckelmann (2 patches) - Kerneldoc fix in forw_packet structure, by Linus Luessing - Remove unused argument in dbg_arp, by Antonio Quartulli - Add support to build batman-adv without wireless, by Linus Luessing - Restructure error handling for is_ap_isolated, by Markus Elfring - Remove unused initialization in various functions, by Sven Eckelmann - Use better names for fragment and gateway list heads, by Sven Eckelmann (2 patches) - Convert to octal permissions for files, by Sven Eckelmann - Avoid precedence issues for some macros, by Sven Eckelmann ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 40GbE Intel Wired LAN Driver Updates 2016-10-28 This series contains updates to i40e and i40evf only. Carolyn provides a couple of fixes, first resolving a problem in the client interface that was causing random stack traces in the RDMA driver which was due to a timing related NULL pointer dereference. Fixed a problem where it could take a very long time to print the link down notification, by changing how often we update link info from firmware. Alex provides a number of changes, first is a re-write of the bust wait loop in the Flow Director transmit function to reduce code size. Cleans up unused code in favor of the same functionality which can be inlined. Dropped the functionality for SCTP since we cannot currently support it. Cleans up redundant code in the receive clean-up path. Finally cleaned up the convoluted configuration for how the driver handled the debug flags contained in msg_level. Filip fixes an incorrect bit mask which was being used for testing the "get link status". Cleaned up a workaround that is no longer needed for production NICs and was causing frames to pass while disregarding the VLAN tagging. Mitch brings another fix for the client interface supporting the VF RDMA driver to allow clients to recover from reset by re-opening existing clients. Alan fixes a bug in which a "perfect storm" can occur and cause interrupts to fail to be correctly affinitized. Lihong fixes a confusing dmesg reported when users were using ethtool -L option. ==================== Signed-off-by: -
Thomas Graf authored
The verifier currently prints raw function ids when printing CALL instructions or when complaining: 5: (85) call 23 unknown func 23 print a meaningful function name instead: 5: (85) call bpf_redirect#23 unknown func bpf_redirect#23 Moves the function documentation to a single comment and renames all helpers names in the list to conform to the bpf_ prefix notation so they can be greped in the kernel source. Signed-off-by:
Thomas Graf <tgraf@suug.ch> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
David Ahern authored
netdev_walk_all_lower_dev is not properly walking the lower device list. Commit 1a3f060c made netdev_walk_all_lower_dev similar to netdev_walk_all_upper_dev_rcu and netdev_walk_all_lower_dev_rcu but failed to update its netdev_next_lower_dev iterator. This patch fixes that. Fixes: 1a3f060c ("net: Introduce new api for walking upper and lower devices") Reported-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Tested-by:
-
Florian Westphal authored
Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Eric Dumazet authored
Per listen(fd, backlog) rules, there is really no point accepting a SYN, sending a SYNACK, and dropping the following ACK packet if accept queue is full, because application is not draining accept queue fast enough. This behavior is fooling TCP clients that believe they established a flow, while there is nothing at server side. They might then send about 10 MSS (if using IW10) that will be dropped anyway while server is under stress. Signed-off-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Acked-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
-
Fabio Estevam authored
Add a definition for PHY ID mask for improving code readability. Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
-
Ido Schimmel authored
Instead of storing return value in 'err' and returning, just return directly. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Thomas Graf authored
Wrap several common instances of: kmemdup(nla_data(attr), nla_len(attr), GFP_KERNEL); Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Acked-by:
-
Arnd Bergmann authored
The newly added raw_diag.c fails to build in some configurations unless we include this header: In file included from net/ipv4/raw_diag.c:6:0: include/net/raw.h:71:21: error: field 'inet' has incomplete type net/ipv4/raw_diag.c: In function 'raw_diag_dump': net/ipv4/raw_diag.c:166:29: error: implicit declaration of function 'inet_sk' Fixes: 432490f9 ("net: ip, diag -- Add diag interface for raw sockets") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Gao Feng authored
When cmd is TUNSETIFF and tun is not null, the original codes go ahead, then reach the default case of switch(cmd) and set the ret is -EINVAL. It is not clear for readers. Now move the tun check into the block of TUNSETIFF condition check, and return -EEXIST instead of -EINVAL when the tfile already owns one tun. Signed-off-by:
Gao Feng <fgao@ikuai8.com> Signed-off-by:
-
Aaron Conole authored
The virtio committee recently ratified a change, VIRTIO-152, which defines the mtu field to be 'max' MTU, not simply desired MTU. This commit brings the virtio-net device in compliance with VIRTIO-152. Additionally, drop the max_mtu branch - it cannot be taken since the u16 returned by virtio_cread16 will never exceed the initial value of max_mtu. Signed-off-by:
Aaron Conole <aconole@redhat.com> Acked-by:
"Michael S. Tsirkin" <mst@redhat.com> Acked-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
-
Alexander Duyck authored
So the i40e driver had a really convoluted configuration for how to handle the debug flags contained in msg_level. Part of the issue is that the driver has its own 32 bit mask that it was using to track a separate set of debug features. From what I can tell it was trying to use the upper 4 bits to determine if the value was meant to represent a bit-mask or the numeric value provided by debug level. What this patch does is clean this up by compressing those 4 bits into bit 31, as a result we just have to perform a check against the value being negative to determine if we are looking at a debug level (positive), or a debug mask (negative). The debug level will populate the msg_level, and the debug mask will populate the debug_mask in the hardware struct. I added similar logic for ethtool. If the value being provided has bit 31 set we assume the value being provided is a debug mask, otherwise we assume it is a msg_enable mask. For displaying we only provide the msg_enable, and if debug_mask is in use we will print it to the dmesg log. Lastly I removed the debugfs interface. It is redundant with what we already have in ethtool and really doesn't belong anyway. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
David Ertman authored
Patch a036244c "i40e: Fix kernel panic on enable/disable LLDP" introduced an error in bit logic. Originally this bit manipulation was meant to clear two bits to indicate that DCB was not enabled or capable. An "&" was incorrectly used instead of an "|" bit operator to combine the two bitmasks into one. This also created a static checker error since the resultant code was a no-op. This patch fixes the error by using the correct bit-wise operator. Signed-off-by:
Dave Ertman <david.m.ertman@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Tested-by:
-
Bimmy Pujari authored
Signed-off-by:
Bimmy Pujari <bimmy.pujari@intel.com> Tested-by:
-
Filip Sadowski authored
This is code refactoring. This patch removes the workaround which deleted a default MAC filter added by the firmware when the interface was brought up. This filter caused frames to pass disregarding the VLAN tagging. It used to be automatically applied after reset in pre-SRA FW versions. This workaround is not needed in production NICs and hence can be removed. Change-ID: I129fe1aae1f17b5a224c9b29a996d916aa1be1ec Signed-off-by:
Filip Sadowski <filip.sadowski@intel.com> Tested-by:
-
Carolyn Wyborny authored
This patch fixes a problem where it could take a very long time (>100 msec) to print the link down notification. This problem is fixed by changing how often we update link info from fw, when link is down. Without this patch, it can take over 100msec to notify user link is down. Change-ID: Ib876eb30834c7080792becd13ee093b9cbb35d78 Signed-off-by:
Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by:
-
Alexander Duyck authored
This patch cleans up several pieces of redundant code in the Rx clean-up paths. The first bit is that hdr_addr and the status_err_len portions of the Rx descriptor represent the same value. As such there is no point in setting them to 0 before setting them to 0. I'm dropping the second spot where we are updating the value to 0 so that we only have 1 write for this value instead of 2. The second piece is the checking for the DD bit in the packet. We only need to check for a non-zero value for the status_err_len because if the device is done with the descriptor it will have written something back and the DD is just one piece of it. In addition I have moved the reading of the Rx descriptor bits related to rx_ptype down so that they are actually below the dma_rmb() call so that we are guaranteed that we don't have any funky 64b on 32b calls causing any ordering issues. Change-ID: I256e44a025d3c64a7224aaaec37c852bfcb1871b Signed-off-by:
-
Lihong Yang authored
Ethtool -L option with the combined parameter is for changing the number of multi-purpose channels of the specified network device. The pre-set maximum for the combined channels is cpu dependent. Currently, for an i40e device, when the user sets a value between 64 and the maximum that the cpu can support for the combined parameter, the i40e driver displays the confusing info in dmesg to only show 64 as the RSS count regardless of what the accepted user input is as long as it is larger than 64. This patch fixes the message in the i40e driver when the user uses ethtool -L to change the number of the combined channels to consistently display the user requested value if it is valid and accepted by ethtool. Change-ID: Ia80a68bc844b779a49e0f76e7d3dcc915032d9af Signed-off-by:
Lihong Yang <lihong.yang@intel.com> Tested-by:
-
Joe Perches authored
Move some data to text $ size drivers/net/ethernet/intel/i40e/i40e_ethtool.o* text data bss dec hex filename 25012 0 32 25044 61d4 drivers/net/ethernet/intel/i40e/i40e_ethtool.o.new 22868 2120 32 25020 61bc drivers/net/ethernet/intel/i40e/i40e_ethtool.o.old Signed-off-by:
Joe Perches <joe@perches.com> Tested-by:
-
Bimmy Pujari authored
Signed-off-by:
-
Alan Brady authored
There exists a bug in which a 'perfect storm' can occur and cause interrupts to fail to be correctly affinitized. This causes unexpected behavior and has a substantial impact on performance when it happens. The bug occurs if there is heavy traffic, any number of CPUs that have an i40e interrupt are pegged at 100%, and the interrupt afffinity for those CPUs is changed. Instead of moving to the new CPU, the interrupt continues to be polled while there is heavy traffic. The bug is most readily realized as the driver is first brought up and all interrupts start on CPU0. If there is heavy traffic and the interrupt starts polling before the interrupt is affinitized, the interrupt will be stuck on CPU0 until traffic stops. The bug, however, can also be wrought out more simply by affinitizing all the interrupts to a single CPU and then attempting to move any of those interrupts off while there is heavy traffic. This patch fixes the bug by registering for update notifications from the kernel when the interrupt affinity changes. When that fires, we cache the intended affinity mask. Then, while polling, if the cpu is pegged at 100% and we failed to clean the rings, we check to make sure we have the correct affinity and stop polling if we're firing on the wrong CPU. When the kernel successfully moves the interrupt, it will start polling on the correct CPU. The performance impact is minimal since the only time this section gets executed is when performance is already compromised by the CPU. Change-ID: I4410a880159b9dba1f8297aa72bef36dca34e830 Signed-off-by:
Alan Brady <alan.brady@intel.com> Tested-by:
-
Preethi Banala authored
Group together the minimum set of offload capabilities that are always supported by VF in base mode. This define would be used by PF to make sure VF in base mode gets minimum of base capabilities . Change-ID: Id5e8f22ba169c8f0a38d22fc36b2cb531c02582c Signed-off-by:
Preethi Banala <preethi.banala@intel.com> Tested-by:
-
Mitch Williams authored
Allow the client interface to reopen existing clients if they were closed. This allows clients to recover from reset, which is essential for supporting VF RDMA. In one instance, the driver was not clearing the open bit when the client was closed. Add the code to clear this bit so that the state is accurate and the driver will not attempt to reopen already-open clients. Remove the ref_cnt variable; it was just getting in the way and was not being used consistently. Change-ID: Ic71af4553b096963ac0c56a997f887c9a4ed162d Signed-off-by:
Mitch Williams <mitch.a.williams@intel.com> Signed-off-by:
-
Alexander Duyck authored
We cannot currently support SCTP in the hardware, and IPV4_FLOW is not used anywhere by the software so we can go through and drop the functionality related to these two flow types. In addition we cannot support masking based on the protocol value so if the user is expecting a value other than TCP or UDP we should simply return an error rather then trying to allocate a filter for a rule that will only partially match what the user requested. Change-ID: I10d52bb97d8104d76255fe244551814ff9531a63 Signed-off-by:
-
Alexander Duyck authored
The function is not used so there is no need to carry it forward. I have plans to add a slightly different function that can be inlined to handle the same kind of functionality. Change-ID: Ie2dfcb189dc75e5fbc156bac23003e3b4210ae0f Signed-off-by:
-
