- 27 Oct, 2015 2 commits
-
-
Sergei Shtylyov authored
The RX buffer size calulation failed to account for the length granularity (which is now 32 bytes)... Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sergei Shtylyov authored
Both Renesas R-Car and RZ/A1 manuals state that RX buffer length must be a multiple of 32 bytes, while the driver only uses 16 byte granularity... Signed-off-by:
-
- 26 Oct, 2015 10 commits
-
-
David S. Miller authored
Claudiu Manoil says: ==================== gianfar: Misc. fixes and updates Various fixes for some older issues, including having a MAINTAINERS entry for this driver. I'd recommend applying them on top of net, thanks. ==================== Signed-off-by: -
Claudiu Manoil authored
Signed-off-by:
Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by:
-
Claudiu Manoil authored
The Rx BSY error interrupt indicates that a frame was received and discarded due to lack of buffers, so it's a rx ring overflow condition and has nothing to do with with bad rx packets. Use the right counter. BSY conditions happen when the SoC is under performance stress. Doing *more* work in stress situations by trying to schedule NAPI is not a good idea as the stressed system becomes still more stressed. The Rx interrupt is already at work making sure the NAPI is scheduled. So calling gfar_receive() here does not help. This issue was present since day 1. Signed-off-by:
-
Claudiu Manoil authored
Under one unusual circumstance it's possible to wrongly set FILREN without enabling PRSDEP as well in the RCTRL register, against the hardware specifications. With the default config this does not happen because the default Rx offloads (Rx csum and Rx VLAN) properly enable PRSDEP. But if anyone disables all these offloads (via ethtool), we get a wrong configuration were the Rx flow classification and hashing, and other Filer based features (e.g. wake-on-filer interrupt) won't work. This patch fixes the issue. Also, account for Rx FCB insertion which happens every time PRSDEP is set. Signed-off-by:
-
Claudiu Manoil authored
RQFCR_AND is duplicated. Add missing space as well. Signed-off-by:
-
David S. Miller authored
David Daney says: ==================== net: thunderx: Support pass-2 revision hardware. With the availability of a new revision of the ThunderX NIC hardware a few changes to the driver are required. With these, the driver works on all currently available hardware revisions. ==================== Signed-off-by: -
Thanneeru Srinivasulu authored
Add support for ThunderX pass2 CPI and MPI configuration changes. MPI_ALG is not enabled i.e MCAM parsing is disabled. Signed-off-by:
Thanneeru Srinivasulu <tsrinivasulu@caviumnetworks.com> Signed-off-by:
Sunil Goutham <sgoutham@cavium.com> Signed-off-by:
David Daney <david.daney@cavium.com> Signed-off-by:
-
David Daney authored
The test for pass-1 silicon was incorrect, it should be for all revisions less than 8. Also the revision is already present in the pci_dev, so there is no need to read and keep a private copy. Remove rev_id and code to read it from struct nicpf. Create new static inline function pass1_silicon() to be used to testing the silicon version. Use pass1_silicon() for revision checks, this will be more widely used in follow on patches. Signed-off-by:
-
Sunil Goutham authored
Signed-off-by:
-
Sunil Goutham authored
In some silicon revisions, the soft reset clobbers PCI config space, so quit doing the reset. Signed-off-by:
-
- 23 Oct, 2015 16 commits
-
-
Li RongQing authored
the returned buffer of register_sysctl() is stored into net_header variable, but net_header is not used after, and compiler maybe optimise the variable out, and lead kmemleak reported the below warning comm "swapper/0", pid 1, jiffies 4294937448 (age 267.270s) hex dump (first 32 bytes): 90 38 8b 01 c0 ff ff ff 00 00 00 00 01 00 00 00 .8.............. 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffc00020f134>] create_object+0x10c/0x2a0 [<ffffffc00070ff44>] kmemleak_alloc+0x54/0xa0 [<ffffffc0001fe378>] __kmalloc+0x1f8/0x4f8 [<ffffffc00028e984>] __register_sysctl_table+0x64/0x5a0 [<ffffffc00028eef0>] register_sysctl+0x30/0x40 [<ffffffc00099c304>] net_sysctl_init+0x20/0x58 [<ffffffc000994dd8>] sock_init+0x10/0xb0 [<ffffffc0000842e0>] do_one_initcall+0x90/0x1b8 [<ffffffc000966bac>] kernel_init_freeable+0x218/0x2f0 [<ffffffc00070ed6c>] kernel_init+0x1c/0xe8 [<ffffffc000083bfc>] ret_from_fork+0xc/0x50 [<ffffffffffffffff>] 0xffffffffffffffff <<end check kmemleak>> Before fix, the objdump result on ARM64: 0000000000000000 <net_sysctl_init>: 0: a9be7bfd stp x29, x30, [sp,#-32]! 4: 90000001 adrp x1, 0 <net_sysctl_init> 8: 90000000 adrp x0, 0 <net_sysctl_init> c: 910003fd mov x29, sp 10: 91000021 add x1, x1, #0x0 14: 91000000 add x0, x0, #0x0 18: a90153f3 stp x19, x20, [sp,#16] 1c: 12800174 mov w20, #0xfffffff4 // #-12 20: 94000000 bl 0 <register_sysctl> 24: b4000120 cbz x0, 48 <net_sysctl_init+0x48> 28: 90000013 adrp x19, 0 <net_sysctl_init> 2c: 91000273 add x19, x19, #0x0 30: 9101a260 add x0, x19, #0x68 34: 94000000 bl 0 <register_pernet_subsys> 38: 2a0003f4 mov w20, w0 3c: 35000060 cbnz w0, 48 <net_sysctl_init+0x48> 40: aa1303e0 mov x0, x19 44: 94000000 bl 0 <register_sysctl_root> 48: 2a1403e0 mov w0, w20 4c: a94153f3 ldp x19, x20, [sp,#16] 50: a8c27bfd ldp x29, x30, [sp],#32 54: d65f03c0 ret After: 0000000000000000 <net_sysctl_init>: 0: a9bd7bfd stp x29, x30, [sp,#-48]! 4: 90000000 adrp x0, 0 <net_sysctl_init> 8: 910003fd mov x29, sp c: a90153f3 stp x19, x20, [sp,#16] 10: 90000013 adrp x19, 0 <net_sysctl_init> 14: 91000000 add x0, x0, #0x0 18: 91000273 add x19, x19, #0x0 1c: f90013f5 str x21, [sp,#32] 20: aa1303e1 mov x1, x19 24: 12800175 mov w21, #0xfffffff4 // #-12 28: 94000000 bl 0 <register_sysctl> 2c: f9002260 str x0, [x19,#64] 30: b40001a0 cbz x0, 64 <net_sysctl_init+0x64> 34: 90000014 adrp x20, 0 <net_sysctl_init> 38: 91000294 add x20, x20, #0x0 3c: 9101a280 add x0, x20, #0x68 40: 94000000 bl 0 <register_pernet_subsys> 44: 2a0003f5 mov w21, w0 48: 35000080 cbnz w0, 58 <net_sysctl_init+0x58> 4c: aa1403e0 mov x0, x20 50: 94000000 bl 0 <register_sysctl_root> 54: 14000004 b 64 <net_sysctl_init+0x64> 58: f9402260 ldr x0, [x19,#64] 5c: 94000000 bl 0 <unregister_sysctl_table> 60: f900227f str xzr, [x19,#64] 64: 2a1503e0 mov w0, w21 68: f94013f5 ldr x21, [sp,#32] 6c: a94153f3 ldp x19, x20, [sp,#16] 70: a8c37bfd ldp x29, x30, [sp],#48 74: d65f03c0 ret Add the possible error handle to free the net_header to remove the kmemleak warning Signed-off-by:
Li RongQing <roy.qing.li@gmail.com> Signed-off-by:
-
Guillaume Nault authored
We can't rely on PPPOX_ZOMBIE to decide whether to clear po->pppoe_dev. PPPOX_ZOMBIE can be set by pppoe_disc_rcv() even when po->pppoe_dev is NULL. So we have no guarantee that (sk->sk_state & PPPOX_ZOMBIE) implies (po->pppoe_dev != NULL). Since we're releasing a PPPoE socket, we want to release the pppoe_dev if it exists and reset sk_state to PPPOX_DEAD, no matter the previous value of sk_state. So we can just check for po->pppoe_dev and avoid any assumption on sk->sk_state. Fixes: 2b018d57 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release") Signed-off-by:
Guillaume Nault <g.nault@alphalink.fr> Signed-off-by:
-
Li RongQing authored
Signed-off-by:
-
Lendacky, Thomas authored
The code currently uses the lightweight dma_wmb barrier before updating the current descriptor count. Under heavy load, the Tx cleanup routine was seeing the updated current descriptor count before the updated descriptor information. As a result, the Tx descriptor was being cleaned up before it was used because it was not "owned" by the hardware yet, resulting in a Tx queue hang. Using the wmb barrier insures that the descriptor is updated before the descriptor counter preventing the Tx queue hang. For extra insurance, the Tx cleanup routine is changed to grab the current decriptor count on entry and uses that initial value in the processing loop rather than trying to chase the current value. Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Tested-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
-
Nathan Sullivan authored
Very rarely, the KSZ9031 will appear to complete autonegotiation, but will drop all traffic afterwards. When this happens, the idle error count will read 0xFF after autonegotiation completes. Reset the PHY when in that state. Signed-off-by:
Nathan Sullivan <nathan.sullivan@ni.com> Signed-off-by:
-
David S. Miller authored
Hannes Frederic Sowa says: ==================== overflow-arith: begin to add support for overflow builtins functions I add a new header, linux/overflow-arith.h, as the central place to add overflow and wrap-around checking functions. The reason I am doing so is that it can make use of compiler supported builtin functions which can leverage hardware. As I need this for a fix in the ipv6 stack, which is also included in this series, I propose to add it sooner than later over Davem's net tree. This is also the reason why I start slowly with only the one function I need at this time. ==================== Signed-off-by: -
Hannes Frederic Sowa authored
Raw sockets with hdrincl enabled can insert ipv6 extension headers right into the data stream. In case we need to fragment those packets, we reparse the options header to find the place where we can insert the fragment header. If the extension headers exceed the link's MTU we actually cannot make progress in such a case. Instead of ending up in broken arithmetic or rounding towards 0 and entering an endless loop in ip6_fragment, just prevent those cases by aborting early and signal -EMSGSIZE to user space. Reported-by:
Dmitry Vyukov <dvyukov@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Hannes Frederic Sowa authored
The idea of the overflow-arith.h header is to collect overflow checking functions in one central place. If gcc compiler supports the __builtin_overflow_* builtins we use them because they might give better performance, otherwise the code falls back to normal overflow checking functions. The builtin_overflow functions are supported by gcc-5 and clang. The matter of supporting clang is to just provide a corresponding CC_HAVE_BUILTIN_OVERFLOW, because the specific overflow checking builtins don't differ between gcc and clang. I just provide overflow_usub function here as I intend this to get merged into net, more functions will definitely follow as they are needed. Signed-off-by:
-
Andrew Shewmaker authored
If alpha is strictly reduced by alpha >> dctcp_shift_g and if alpha is less than 1 << dctcp_shift_g, then alpha may never reach zero. For example, given shift_g=4 and alpha=15, alpha >> dctcp_shift_g yields 0 and alpha remains 15. The effect isn't noticeable in this case below cwnd=137, but could gradually drive uncongested flows with leftover alpha down to cwnd=137. A larger dctcp_shift_g would have a greater effect. This change causes alpha=15 to drop to 0 instead of being decrementing by 1 as it would when alpha=16. However, it requires one less conditional to implement since it doesn't have to guard against subtracting 1 from 0U. A decay of 15 is not unreasonable since an equal or greater amount occurs at alpha >= 240. Signed-off-by:
Andrew G. Shewmaker <agshew@gmail.com> Acked-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
lucien authored
The error condition -EAGAIN, which is signaled by throw routes, tells the rules framework to walk on searching for next matches. If the walk ends and we stop walking the rules with the result of a throw route we have to translate the error conditions to -ENETUNREACH. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Jason Wang authored
We don't have fraglist support in TAP_FEATURES. This will lead software segmentation of gro skb with frag list. Fixes by having frag list support in TAP_FEATURES. With this patch single session of netperf receiving were restored from about 5Gb/s to about 12Gb/s on mlx4. Fixes a567dd62 ("macvtap: simplify usage of tap_features") Cc: Vlad Yasevich <vyasevic@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Pravin B Shelar authored
While transitioning to netdev based vport we broke OVS feature which allows user to retrieve tunnel packet egress information for lwtunnel devices. Following patch fixes it by introducing ndo operation to get the tunnel egress info. Same ndo operation can be used for lwtunnel devices and compat ovs-tnl-vport devices. So after adding such device operation we can remove similar operation from ovs-vport. Fixes: 614732ea ("openvswitch: Use regular VXLAN net_device device"). Signed-off-by:
Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queueDavid S. Miller authored
Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2015-10-22 This series contains fixes to i40e only. Jesse provides two small fixes for i40e, first fixes counters that were being displayed incorrectly due to indexing beyond the array of strings when printing stats. Then fixed the fact that the driver was printing a message about not being able to assign VMDq because a lack of MSI-X vectors, when it was not true. It was due to a line missing that initialized a variable. ==================== Signed-off-by: -
Jorgen Hansen authored
The recent fix for the vsock sock_put issue used the wrong initializer for the transport spin_lock causing an issue when running with lockdep checking. Testing: Verified fix on kernel with lockdep enabled. Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
Jorgen Hansen <jhansen@vmware.com> Signed-off-by:
-
Jesse Brandeburg authored
The driver was printing a message about not being able to assign VMDq because of a lack of MSI-X vectors. This was because a line was missing that initialized a variable, simply a merge error. Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Jesse Brandeburg authored
The code was setting up stats that were not being initialized. This caused several counters to be displayed incorrectly, due to indexing beyond the array of strings when printing stats. Signed-off-by:
-
- 22 Oct, 2015 12 commits
-
-
Bjørn Mork authored
New device IDs shamelessly lifted from the vendor driver. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsecDavid S. Miller authored
Steffen Klassert says: ==================== pull request (net): ipsec 2015-10-22 1) Fix IPsec pre-encap fragmentation for GSO packets. From Herbert Xu. 2) Fix some header checks in _decode_session6. We skip the header informations if the data pointer points already behind the header in question for some protocols. This is because we call pskb_may_pull with a negative value converted to unsigened int from pskb_may_pull in this case. Skipping the header informations can lead to incorrect policy lookups. From Mathias Krause. 3) Allow to change the replay threshold and expiry timer of a state without having to set other attributes like replay counter and byte lifetime. Changing these other attributes may break the SA. From Michael Rossberg. 4) Fix pmtu discovery for local generated packets. We may fail dispatch to the inner address family. As a reault, the local error handler is not called and the mtu value is not reported back to userspace. Please pull or let me know if there are problems. ==================== Signed-off-by: -
David Ahern authored
741a11d9 ("net: ipv6: Add RT6_LOOKUP_F_IFACE flag if oif is set") adds the RT6_LOOKUP_F_IFACE flag to make device index mismatch fatal if oif is given. Hajime reported that this change breaks the Mobile IPv6 use case that wants to force the message through one interface yet use the source address from another interface. Handle this case by only adding the flag if oif is set and saddr is not set. Fixes: 741a11d9 ("net: ipv6: Add RT6_LOOKUP_F_IFACE flag if oif is set") Cc: Hajime Tazaki <thehajime@gmail.com> Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
-
David S. Miller authored
Karsten Keil says: ==================== Fix potential NULL pointer access and memory leak in ISDN layer2 functions Insu Yun did brinup the issue with not checking the skb_clone() return value in the layer2 I-frame ull functions. This series fix the issue in a way which avoid protocol violations/data loss on a temporary memory shortage. ==================== Signed-off-by: -
Karsten Keil authored
The old code did not check the return value of skb_clone(). The extra skb_clone() is not needed at all, if using skb_realloc_headroom() instead, which gives us a private copy with enough headroom as well. We need to requeue the original skb if the call failed, because we cannot inform upper layers about the data loss. Restructure the code to minimise rollback effort if it happens. This fix kernel bug #86091 Thanks to Insu Yun <wuninsu@gmail.com> to remind me on this issue. Signed-off-by:
Karsten Keil <keil@b1-systems.de> Signed-off-by:
-
Karsten Keil authored
The skb_clone() return value was not checked and the skb_realloc_headroom() usage was wrong, the old skb was not freed. It turned out, that the skb_clone is not needed at all, the skb_realloc_headroom() will create a private copy with enough headroom and the original SKB can be used for the ACK queue. We need to requeue the original skb if the call failed, since the upper layer cannot be informed about memory shortage. Thanks to Insu Yun <wuninsu@gmail.com> to remind me on this issue. Signed-off-by:
-
Jorgen Hansen authored
In the vsock vmci_transport driver, sock_put wasn't safe to call in interrupt context, since that may call the vsock destructor which in turn calls several functions that should only be called from process context. This change defers the callling of these functions to a worker thread. All these functions were deallocation of resources related to the transport itself. Furthermore, an unused callback was removed to simplify the cleanup. Multiple customers have been hitting this issue when using VMware tools on vSphere 2015. Also added a version to the vmci transport module (starting from 1.0.2.0-k since up until now it appears that this module was sharing version with vsock that is currently at 1.0.1.0-k). Reviewed-by:
Aditya Asarwade <asarwade@vmware.com> Reviewed-by:
-
David Herrmann authored
Currently, NETLINK_LIST_MEMBERSHIPS grabs the netlink table while copying the membership state to user-space. However, grabing the netlink table is effectively a write_lock_irq(), and as such we should not be triggering page-faults in the critical section. This can be easily reproduced by the following snippet: int s = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE); void *p = mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0); int r = getsockopt(s, 0x10e, 9, p, (void*)((char*)p + 4092)); This should work just fine, but currently triggers EFAULT and a possible WARN_ON below handle_mm_fault(). Fix this by reducing locking of NETLINK_LIST_MEMBERSHIPS to a read-side lock. The write-lock was overkill in the first place, and the read-lock allows page-faults just fine. Reported-by:David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
Andrew F. Davis authored
Add support for the TI DP83848 Ethernet PHY device. The DP83848 is a highly reliable, feature rich, IEEE 802.3 compliant single port 10/100 Mb/s Ethernet Physical Layer Transceiver supporting the MII and RMII interfaces. Signed-off-by:
Andrew F. Davis <afd@ti.com> Signed-off-by:
Dan Murphy <dmurphy@ti.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Acked-by:
-
Hans de Goede authored
Fix sun4i-emac not releasing the following resources: -iomapped memory not released on probe-failure nor on remove -clock not getting disabled on probe-failure nor on remove -sram not being released on remove And while at it also add error checking to the clk_prepare_enable call done on probe. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Joe Stringer authored
If userspace provides a ct action with no nested mark or label, then the storage for these fields is zeroed. Later when actions are requested, such zeroed fields are serialized even though userspace didn't originally specify them. Fix the behaviour by ensuring that no action is serialized in this case, and reject actions where userspace attempts to set these fields with mask=0. This should make netlink marshalling consistent across deserialization/reserialization. Reported-by:
Jarno Rajahalme <jrajahalme@nicira.com> Signed-off-by:
Joe Stringer <joestringer@nicira.com> Acked-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
Joe Stringer authored
New, related connections are marked as such as part of ovs_ct_lookup(), but they are not marked as "new" if the commit flag is used. Make this consistent by setting the "new" flag whenever !nf_ct_is_confirmed(ct). Reported-by:
-
