commit acfaf47549491e5f804d30855c9055ebeb6ecc7b Author: Greg Kroah-Hartman Date: Wed Oct 15 12:05:43 2014 +0200 Linux 3.16.6 commit 09ee7b8b5bc19040533675a6b0dc5426eeedbab3 Author: Bryan O'Donoghue Date: Tue Sep 23 01:21:11 2014 +0100 serial: 8250: Add Quark X1000 to 8250_pci.c commit 1ede7dcca3c4fa15a518ab0473126f9c3e621e4c upstream. Quark X1000 contains two designware derived 8250 serial ports. Each port has a unique PCI configuration space consisting of BAR0:UART BAR1:DMA respectively. Unlike the standard 8250 the register width is 32 bits for RHR,IER etc The Quark UART has a fundamental clock @ 44.2368 MHz allowing for a bitrate of up to about 2.76 megabits per second. This patch enables standard 8250 mode Signed-off-by: Bryan O'Donoghue Reviewed-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman commit ceb0e516b853d814901731cc83fdfaeb7dd6941a Author: Yasuaki Ishimatsu Date: Fri Oct 3 19:06:03 2014 +0900 driver/base/node: remove unnecessary kfree of node struct from unregister_one_node commit 33ead538f642a33b1d658782a5d14a40b5014d1f upstream. Commit 92d585ef067d ("numa: fix NULL pointer access and memory leak in unregister_one_node()") added kfree() of node struct in unregister_one_node(). But node struct is freed by node_device_release() which is called in unregister_node(). So by adding the kfree(), node struct is freed two times. While hot removing memory, the commit leads the following BUG_ON(): kernel BUG at mm/slub.c:3346! invalid opcode: 0000 [#1] SMP [...] Call Trace: [...] unregister_one_node [...] try_offline_node [...] remove_memory [...] acpi_memory_device_remove [...] acpi_bus_trim [...] acpi_bus_trim [...] acpi_device_hotplug [...] acpi_hotplug_work_fn [...] process_one_work [...] worker_thread [...] ? rescuer_thread [...] kthread [...] ? kthread_create_on_node [...] ret_from_fork [...] ? kthread_create_on_node This patch removes unnecessary kfree() from unregister_one_node(). Signed-off-by: Yasuaki Ishimatsu Cc: Xishi Qiu Fixes: 92d585ef067d "numa: fix NULL pointer access and memory leak in unregister_one_node()" Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 776c2868cbe4494e76adad43e123e8cd1fd1657f Author: Cristian Stoica Date: Thu Aug 14 13:51:57 2014 +0300 crypto: caam - fix addressing of struct member commit 4451d494b1910bf7b7f8381a637d0fe6d2142467 upstream. buf_0 and buf_1 in caam_hash_state are not next to each other. Accessing buf_1 is incorrect from &buf_0 with an offset of only size_of(buf_0). The same issue is also with buflen_0 and buflen_1 Signed-off-by: Cristian Stoica Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit e8aa6c3914195a96346457c21320e5581d3a8ac0 Author: Felipe Balbi Date: Mon Sep 15 09:03:24 2014 -0500 usb: musb: dsps: kill OTG timer on suspend commit 468bcc2a2ca071f652009d2d20d97f2437630cae upstream. if we don't make sure to kill the timer, it could expire after we have already gated our clocks. That will trigger a Data Abort exception because we would try to access register while clock is gated. Fix that bug. Fixes 869c597 (usb: musb: dsps: add support for suspend and resume) Tested-by: Dave Gerlach Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit e5c8fe8e5fec15f1ae73ce2c395498645daa6214 Author: Andreas Bomholtz Date: Mon Sep 22 09:50:43 2014 +0200 USB: cp210x: add support for Seluxit USB dongle commit dee80ad12d2b1b304286a707fde7ab05d1fc7bab upstream. Added the Seluxit ApS USB Serial Dongle to cp210x driver. Signed-off-by: Andreas Bomholtz Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 56dca251bb6d8db694f365367bd553c15ec00351 Author: Joe Savage Date: Sat Sep 20 08:01:16 2014 -0500 USB: serial: cp210x: added Ketra N1 wireless interface support commit bfc2d7dfdd761ae3beccdb26abebe03cef042f46 upstream. Added support for Ketra N1 wireless interface, which uses the Silicon Labs' CP2104 USB to UART bridge with customized PID 8946. Signed-off-by: Joe Savage Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 37411c7265735d155e5225cc59def33b3580c853 Author: Lu Baolu Date: Fri Sep 19 10:13:50 2014 +0800 USB: Add device quirk for ASUS T100 Base Station keyboard commit ddbe1fca0bcb87ca8c199ea873a456ca8a948567 upstream. This full-speed USB device generates spurious remote wakeup event as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result, Linux can't enter system suspend and S0ix power saving modes once this keyboard is used. This patch tries to introduce USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk. With this quirk set, wakeup capability will be ignored during device configure. This patch could be back-ported to kernels as old as 2.6.39. Signed-off-by: Lu Baolu Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 54d95e003a1b6b0fbbeddb9a7cb081a1de1cec9d Author: Hans de Goede Date: Tue Sep 23 15:48:50 2014 +0200 uas: Add another ASM1051 usb-id to the uas blacklist commit 710f1bf16ab1b1558f099b62c5011c4cbba6a7bb upstream. As most ASM1051 based devices, this one has unfixable issues with uas too. Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 77d185882189230d572ecc13cac4170c710e2473 Author: Hans de Goede Date: Wed Sep 17 10:10:58 2014 +0200 uas: Add US_FL_NO_ATA_1X quirk for Seagate (0bc2:ab20) drives commit f9554a6b199360c2f888173fd600e1eb7ff165ef upstream. https://bbs.archlinux.org/viewtopic.php?pid=1457492 Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 46816a619d8365ebbcfedbd83f74bcd2f004d81e Author: Hans de Goede Date: Tue Sep 16 18:36:52 2014 +0200 uas: Add no-report-opcodes quirk commit 734016b00b50a3c6a0e1fc1b7b217e783f5123a1 upstream. Besides the ASM1051 (*) needing sdev->no_report_opcodes = 1, it turns out that the JMicron JMS567 also needs it to work properly with uas (usb-storage always sets it). Since some of the scsi devs were not to keen on the idea to outrightly set sdev->no_report_opcodes = 1 for all uas devices, so add a quirk for this, and set it for the JMS567. *) Which has become a non-issue since we've completely blacklisted uas on the ASM1051 for other reasons Reported-and-tested-by: Claudio Bizzarri Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit b1973083c479bb686fa44cb7aa0efa4312d6d2d8 Author: Hans de Goede Date: Mon Sep 15 16:04:12 2014 +0200 uas: Add a quirk for rejecting ATA_12 and ATA_16 commands commit 593078525c8b234a35a36ff551b8716464e86481 upstream. And set this quirk for the Seagate Expansion Desk (0bc2:2312), as that one seems to hang upon receiving an ATA_12 or ATA_16 command. https://bugzilla.kernel.org/show_bug.cgi?id=79511 https://bbs.archlinux.org/viewtopic.php?id=183190 While at it also add missing documentation for the u value for usb-storage quirks. Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 90bca55d47539bee593fa42ea659bd6e24e98ab4 Author: WANG Cong Date: Mon Oct 6 17:21:54 2014 -0700 net_sched: copy exts->type in tcf_exts_change() [ Upstream commit 5301e3e117d88ef0967ce278912e54757f1a31a2 ] We need to copy exts->type when committing the change, otherwise it would be always 0. This is a quick fix for -net and -stable, for net-next tcf_exts will be removed. Fixes: commit 33be627159913b094bb578e83 ("net_sched: act: use standard struct list_head") Reported-by: Jamal Hadi Salim Cc: Jamal Hadi Salim Cc: John Fastabend Signed-off-by: Cong Wang Acked-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 41e0f6de164ad24be47072665960f2022fea9950 Author: Vlad Yasevich Date: Fri Oct 3 18:16:20 2014 -0400 sctp: handle association restarts when the socket is closed. [ Upstream commit bdf6fa52f01b941d4a80372d56de465bdbbd1d23 ] Currently association restarts do not take into consideration the state of the socket. When a restart happens, the current assocation simply transitions into established state. This creates a condition where a remote system, through a the restart procedure, may create a local association that is no way reachable by user. The conditions to trigger this are as follows: 1) Remote does not acknoledge some data causing data to remain outstanding. 2) Local application calls close() on the socket. Since data is still outstanding, the association is placed in SHUTDOWN_PENDING state. However, the socket is closed. 3) The remote tries to create a new association, triggering a restart on the local system. The association moves from SHUTDOWN_PENDING to ESTABLISHED. At this point, it is no longer reachable by any socket on the local system. This patch addresses the above situation by moving the newly ESTABLISHED association into SHUTDOWN-SENT state and bundling a SHUTDOWN after the COOKIE-ACK chunk. This way, the restarted associate immidiately enters the shutdown procedure and forces the termination of the unreachable association. Reported-by: David Laight Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 26875bba869bd91a1d8fef9229a56a1e6d9fef2b Author: KY Srinivasan Date: Sun Oct 5 10:42:51 2014 -0700 hyperv: Fix a bug in netvsc_send() [ Upstream commit 3a67c9ccad926a168d8b7891537a452018368a5b ] After the packet is successfully sent, we should not touch the packet as it may have been freed. This patch is based on the work done by Long Li . David, please queue this up for stable. Signed-off-by: K. Y. Srinivasan Reported-by: Sitsofe Wheeler Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1f8649d07512f88a2f9a0e297e4616834e162857 Author: Joe Lawrence Date: Fri Oct 3 09:58:34 2014 -0400 team: avoid race condition in scheduling delayed work [ Upstream commit 47549650abd13d873fd2e5fc218db19e21031074 ] When team_notify_peers and team_mcast_rejoin are called, they both reset their respective .count_pending atomic variable. Then when the actual worker function is executed, the variable is atomically decremented. This pattern introduces a potential race condition where the .count_pending rolls over and the worker function keeps rescheduling until .count_pending decrements to zero again: THREAD 1 THREAD 2 ======== ======== team_notify_peers(teamX) atomic_set count_pending = 1 schedule_delayed_work team_notify_peers(teamX) atomic_set count_pending = 1 team_notify_peers_work atomic_dec_and_test count_pending = 0 (return) schedule_delayed_work team_notify_peers_work atomic_dec_and_test count_pending = -1 schedule_delayed_work (repeat until count_pending = 0) Instead of assigning a new value to .count_pending, use atomic_add to tack-on the additional desired worker function invocations. Signed-off-by: Joe Lawrence Acked-by: Jiri Pirko Fixes: fc423ff00df3a19554414ee ("team: add peer notification") Fixes: 492b200efdd20b8fcfdac87 ("team: add support for sending multicast rejoins") Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d24e8812d4fd0ef52abcb66df2bc23d310018caa Author: Florian Fainelli Date: Thu Oct 2 09:43:16 2014 -0700 net: systemport: fix bcm_sysport_insert_tsb() [ Upstream commit e87474a6e697857df21cff0707a2472abceca8b3 ] Similar to commit bc23333ba11fb7f959b7e87e121122f5a0fbbca8 ("net: bcmgenet: fix bcmgenet_put_tx_csum()"), we need to return the skb pointer in case we had to reallocate the SKB headroom. Fixes: 80105befdb4b8 ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c02b2427c2ec0ff8fe8cc85de08db0a70c632b03 Author: Nicolas Dichtel Date: Thu Oct 2 18:26:49 2014 +0200 ip6_gre: fix flowi6_proto value in xmit path [ Upstream commit 3be07244b7337760a3269d56b2f4a63e72218648 ] In xmit path, we build a flowi6 which will be used for the output route lookup. We are sending a GRE packet, neither IPv4 nor IPv6 encapsulated packet, thus the protocol should be IPPROTO_GRE. Fixes: c12b395a4664 ("gre: Support GRE over IPv6") Reported-by: Matthieu Ternisien d'Ouville Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b3e774263908a834c1c0d5abf3a7658280e42fc7 Author: KY Srinivasan Date: Sun Sep 28 22:16:43 2014 -0700 hyperv: Fix a bug in netvsc_start_xmit() [ Upstream commit dedb845ded56ded1c62f5398a94ffa8615d4592d ] After the packet is successfully sent, we should not touch the skb as it may have been freed. This patch is based on the work done by Long Li . In this version of the patch I have fixed issues pointed out by David. David, please queue this up for stable. Signed-off-by: K. Y. Srinivasan Tested-by: Long Li Tested-by: Sitsofe Wheeler Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 46e9e43eeef323df23a45d577ea2a360617068ed Author: Hannes Frederic Sowa Date: Sun Sep 28 00:46:06 2014 +0200 ipv6: remove rt6i_genid [ Upstream commit 705f1c869d577c8055736dd02501f26a2507dd5b ] Eric Dumazet noticed that all no-nonexthop or no-gateway routes which are already marked DST_HOST (e.g. input routes routes) will always be invalidated during sk_dst_check. Thus per-socket dst caching absolutely had no effect and early demuxing had no effect. Thus this patch removes rt6i_genid: fn_sernum already gets modified during add operations, so we only must ensure we mutate fn_sernum during ipv6 address remove operations. This is a fairly cost extensive operations, but address removal should not happen that often. Also our mtu update functions do the same and we heard no complains so far. xfrm policy changes also cause a call into fib6_flush_trees. Also plug a hole in rt6_info (no cacheline changes). I verified via tracing that this change has effect. Cc: Eric Dumazet Cc: YOSHIFUJI Hideaki Cc: Vlad Yasevich Cc: Nicolas Dichtel Cc: Martin Lau Signed-off-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 47a0965d9f9d263d2ab487f462f5d1827135cfdb Author: Eric Dumazet Date: Mon Sep 29 10:34:29 2014 -0700 gro: fix aggregation for skb using frag_list [ Upstream commit 73d3fe6d1c6d840763ceafa9afae0aaafa18c4b5 ] In commit 8a29111c7ca6 ("net: gro: allow to build full sized skb") I added a regression for linear skb that traditionally force GRO to use the frag_list fallback. Erez Shitrit found that at most two segments were aggregated and the "if (skb_gro_len(p) != pinfo->gso_size)" test was failing. This is because pinfo at this spot still points to the last skb in the chain, instead of the first one, where we find the correct gso_size information. Signed-off-by: Eric Dumazet Fixes: 8a29111c7ca6 ("net: gro: allow to build full sized skb") Reported-by: Erez Shitrit Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7197ff3f17a119d27eacdf5b90ba9053f94396fe Author: Matan Barak Date: Wed Sep 10 16:41:53 2014 +0300 net/mlx4: Correctly configure single ported VFs from the host [ Upstream commit a91c772fa0275163508e1078ff6d474d423244fb ] Single port VFs are seen PCI wise on both ports of the PF (we don't have single port PFs with ConnectX). With this in mind, it's possible for virtualization tools to try and configure a single ported VF through the "wrong" PF port. To handle that, we use the PF driver mapping of single port VFs to NIC ports and adjust the port value before calling into the low level code that does the actual VF configuration Fixes: 449fc48 ('net/mlx4: Adapt code for N-Port VF') Signed-off-by: Matan Barak Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 256ddc622fef20a10c675edc5e69c7c05cb82051 Author: Matan Barak Date: Tue Sep 23 16:05:59 2014 +0300 net/mlx4_core: Allow not to specify probe_vf in SRIOV IB mode [ Upstream commit effa4bc4e75a265105f4ccb55857057e5ad231ed ] When the HCA is configured in SRIOV IB mode (that is, at least one of the ports is IB) and the probe_vf module param isn't specified, mlx4_init_one() failed because of the following condition: if (ib_ports && (num_vfs_argc > 1 || probe_vfs_argc > 1)) { ..... } The root cause for that is a mistake in the initialization of num_vfs_argc and probe_vfs_argc. When num_vfs / probe_vf aren't given, their argument count counterpart should be 0, fix that. Fixes: dd41cc3bb90e ('net/mlx4: Adapt num_vfs/probed_vf params for single port VF') Signed-off-by: Matan Barak Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 897a8a7de5036d870f25887362cfda72bb031c18 Author: Soren Brinkmann Date: Mon Sep 22 16:49:08 2014 -0700 Revert "net/macb: add pinctrl consumer support" [ Upstream commit 9026968abe7ad102f4ac5c6d96d733643f75399c ] This reverts commit 8ef29f8aae524bd51298fb10ac6a5ce6c4c5a3d8. The driver core already calls pinctrl_get() and claims the default state. There is no need to replicate this in the driver. Acked-by: Nicolas Ferre Acked-by: Nicolas Ferre Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e92b35f587a884f4c10fa165c0dea32affe176b0 Author: Vlad Yasevich Date: Mon Sep 22 16:34:17 2014 -0400 macvtap: Fix race between device delete and open. [ Upstream commit 40b8fe45d1f094e3babe7b2dc2b71557ab71401d ] In macvtap device delete and open calls can race and this causes a list curruption of the vlan queue_list. The race intself is triggered by the idr accessors that located the vlan device. The device is stored into and removed from the idr under both an rtnl and a mutex. However, when attempting to locate the device in idr, only a mutex is taken. As a result, once cpu perfoming a delete may take an rtnl and wait for the mutex, while another cput doing an open() will take the idr mutex first to fetch the device pointer and later take an rtnl to add a queue for the device which may have just gotten deleted. With this patch, we now hold the rtnl for the duration of the macvtap_open() call thus making sure that open will not race with delete. CC: Michael S. Tsirkin CC: Jason Wang Signed-off-by: Vladislav Yasevich Acked-by: Jason Wang Acked-by: Michael S. Tsirkin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d7ea26ff57d0e65ed6072a95a2e0dc68bcca373b Author: Steffen Klassert Date: Mon Sep 22 09:11:08 2014 +0200 ip_tunnel: Don't allow to add the same tunnel multiple times. [ Upstream commit d61746b2e71bf612fb397b00242de5df5ba7f29a ] When we try to add an already existing tunnel, we don't return an error. Instead we continue and call ip_tunnel_update(). This means that we can change existing tunnels by adding the same tunnel multiple times. It is even possible to change the tunnel endpoints of the fallback device. We fix this by returning an error if we try to add an existing tunnel. Signed-off-by: Steffen Klassert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c4cb71c5dd4627c73f06a05ab0ea5963d1c90e4d Author: Steffen Klassert Date: Tue Sep 16 10:08:49 2014 +0200 xfrm: Generate queueing routes only from route lookup functions [ Upstream commit b8c203b2d2fc961bafd53b41d5396bbcdec55998 ] Currently we genarate a queueing route if we have matching policies but can not resolve the states and the sysctl xfrm_larval_drop is disabled. Here we assume that dst_output() is called to kill the queued packets. Unfortunately this assumption is not true in all cases, so it is possible that these packets leave the system unwanted. We fix this by generating queueing routes only from the route lookup functions, here we can guarantee a call to dst_output() afterwards. Fixes: a0073fe18e71 ("xfrm: Add a state resolution packet queue") Reported-by: Konstantinos Kolelis Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit de541d0ce196bc1bf04caefc5b8a55f25b165517 Author: Steffen Klassert Date: Tue Sep 16 10:08:40 2014 +0200 xfrm: Generate blackhole routes only from route lookup functions [ Upstream commit f92ee61982d6da15a9e49664ecd6405a15a2ee56 ] Currently we genarate a blackhole route route whenever we have matching policies but can not resolve the states. Here we assume that dst_output() is called to kill the balckholed packets. Unfortunately this assumption is not true in all cases, so it is possible that these packets leave the system unwanted. We fix this by generating blackhole routes only from the route lookup functions, here we can guarantee a call to dst_output() afterwards. Fixes: 2774c131b1d ("xfrm: Handle blackhole route creation via afinfo.") Reported-by: Konstantinos Kolelis Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 5fe8352975d6fbac9200c55ff66fd07aabb593e4 Author: Vlad Yasevich Date: Tue Sep 30 19:39:36 2014 -0400 tg3: Allow for recieve of full-size 8021AD frames [ Upstream commit 7d3083ee36b51e425b6abd76778a2046906b0fd3 ] When receiving a vlan-tagged frame that still contains a vlan header, the length of the packet will be greater then MTU+ETH_HLEN since it will account of the extra vlan header. TG3 checks this for the case for 802.1Q, but not for 802.1ad. As a result, full sized 802.1ad frames get dropped by the card. Add a check for 802.1ad protocol when receving full sized frames. Suggested-by: Prashant Sreedharan CC: Prashant Sreedharan CC: Michael Chan Signed-off-by: Vladislav Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b0ce10f71c27b97e880b5eb15471613f6facc11d Author: Vlad Yasevich Date: Thu Sep 18 10:31:17 2014 -0400 tg3: Work around HW/FW limitations with vlan encapsulated frames [ Upstream commit 476c18850c6cbaa3f2bb661ae9710645081563b9 ] TG3 appears to have an issue performing TSO and checksum offloading correclty when the frame has been vlan encapsulated (non-accelrated). In these cases, tcp checksum is not correctly updated. This patch attempts to work around this issue. After the patch, 802.1ad vlans start working correctly over tg3 devices. CC: Prashant Sreedharan CC: Michael Chan Signed-off-by: Vladislav Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 576642b935ca7509416a739c29923ab1cf5619a2 Author: Nicolas Dichtel Date: Wed Sep 17 10:08:08 2014 +0200 macvlan: allow to enqueue broadcast pkt on virtual device [ Upstream commit 07d92d5cc977a7fe1e683e1d4a6f723f7f2778cb ] Since commit 412ca1550cbe ("macvlan: Move broadcasts into a work queue"), the driver uses tx_queue_len of the master device as the limit of packets enqueuing. Problem is that virtual drivers have this value set to 0, thus all broadcast packets were rejected. Because tx_queue_len was arbitrarily chosen, I replace it with a static limit of 1000 (also arbitrarily chosen). CC: Herbert Xu Reported-by: Thibaut Collet Suggested-by: Thibaut Collet Tested-by: Thibaut Collet Signed-off-by: Nicolas Dichtel Acked-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 156c6b80756b5570528336015c75091157cdd765 Author: Francesco Ruggeri Date: Wed Sep 17 10:40:44 2014 -0700 net: allow macvlans to move to net namespace [ Upstream commit 0d0162e7a33d3710b9604e7c68c0f31f5c457428 ] I cannot move a macvlan interface created on top of a bonding interface to a different namespace: % ip netns add dummy0 % ip link add link bond0 mac0 type macvlan % ip link set mac0 netns dummy0 RTNETLINK answers: Invalid argument % The problem seems to be that commit f9399814927a ("bonding: Don't allow bond devices to change network namespaces.") sets NETIF_F_NETNS_LOCAL on bonding interfaces, and commit 797f87f83b60 ("macvlan: fix netdev feature propagation from lower device") causes macvlan interfaces to inherit its features from the lower device. NETIF_F_NETNS_LOCAL should not be inherited from the lower device by a macvlan. Patch tested on 3.16. Signed-off-by: Francesco Ruggeri Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c78abd1a9a6eb65ee73d6798d6a2708ba11195fa Author: Vlad Yasevich Date: Mon Sep 15 15:24:26 2014 -0400 bridge: Fix br_should_learn to check vlan_enabled [ Upstream commit c095f248e63ada504dd90c90baae673ae10ee3fe ] As Toshiaki Makita pointed out, the BRIDGE_INPUT_SKB_CB will not be initialized in br_should_learn() as that function is called only from br_handle_local_finish(). That is an input handler for link-local ethernet traffic so it perfectly correct to check br->vlan_enabled here. Reported-by: Toshiaki Makita Fixes: 20adfa1 bridge: Check if vlan filtering is enabled only once. Signed-off-by: Vladislav Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 84351f1abd0a4e53a739c8714a7584b52a0386f5 Author: Vlad Yasevich Date: Fri Sep 12 16:26:16 2014 -0400 bridge: Check if vlan filtering is enabled only once. [ Upstream commit 20adfa1a81af00bf2027644507ad4fa9cd2849cf ] The bridge code checks if vlan filtering is enabled on both ingress and egress. When the state flip happens, it is possible for the bridge to currently be forwarding packets and forwarding behavior becomes non-deterministic. Bridge may drop packets on some interfaces, but not others. This patch solves this by caching the filtered state of the packet into skb_cb on ingress. The skb_cb is guaranteed to not be over-written between the time packet entres bridge forwarding path and the time it leaves it. On egress, we can then check the cached state to see if we need to apply filtering information. Signed-off-by: Vladislav Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bcbfd0c0a36147834e337cb76357cadedc822f90 Author: Eric Dumazet Date: Thu Sep 11 20:27:37 2014 -0700 net: filter: fix possible use after free [ No appicable upstream commit, this bug has been subsequently been fixed as a side effect of other changes. ] If kmemdup() fails, we free fp->orig_prog and return -ENOMEM sk_attach_filter() -> sk_filter_uncharge(sk, fp) -> sk_filter_release(fp) -> call_rcu(&fp->rcu, sk_filter_release_rcu) -> sk_filter_release_rcu() -> sk_release_orig_filter() fprog = fp->orig_prog; // not NULL, but points to freed memory kfree(fprog->filter); // use after free, potential corruption kfree(fprog); // double free or corruption Note: This was fixed in 3.17+ with commit 278571baca2a ("net: filter: simplify socket charging") Found by AddressSanitizer Signed-off-by: Eric Dumazet Fixes: a3ea269b8bcdb ("net: filter: keep original BPF program around") Acked-by: Alexei Starovoitov Acked-by: Daniel Borkmann Signed-off-by: Greg Kroah-Hartman commit e39b8b0e9c277722801db9eeab00aa7a0f18dc60 Author: Nikolay Aleksandrov Date: Fri Sep 12 17:38:18 2014 +0200 bonding: fix div by zero while enslaving and transmitting [ Upstream commit 9a72c2da690d78e93cff24b9f616412508678dd5 ] The problem is that the slave is first linked and slave_cnt is incremented afterwards leading to a div by zero in the modes that use it as a modulus. What happens is that in bond_start_xmit() bond_has_slaves() is used to evaluate further transmission and it becomes true after the slave is linked in, but when slave_cnt is used in the xmit path it is still 0, so fetch it once and transmit based on that. Since it is used only in round-robin and XOR modes, the fix is only for them. Thanks to Eric Dumazet for pointing out the fault in my first try to fix this. Call trace (took it out of net-next kernel, but it's the same with net): [46934.330038] divide error: 0000 [#1] SMP [46934.330041] Modules linked in: bonding(O) 9p fscache snd_hda_codec_generic crct10dif_pclmul [46934.330041] bond0: Enslaving eth1 as an active interface with an up link [46934.330051] ppdev joydev crc32_pclmul crc32c_intel 9pnet_virtio ghash_clmulni_intel snd_hda_intel 9pnet snd_hda_controller parport_pc serio_raw pcspkr snd_hda_codec parport virtio_balloon virtio_console snd_hwdep snd_pcm pvpanic i2c_piix4 snd_timer i2ccore snd soundcore virtio_blk virtio_net virtio_pci virtio_ring virtio ata_generic pata_acpi floppy [last unloaded: bonding] [46934.330053] CPU: 1 PID: 3382 Comm: ping Tainted: G O 3.17.0-rc4+ #27 [46934.330053] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [46934.330054] task: ffff88005aebf2c0 ti: ffff88005b728000 task.ti: ffff88005b728000 [46934.330059] RIP: 0010:[] [] bond_start_xmit+0x1c3/0x450 [bonding] [46934.330060] RSP: 0018:ffff88005b72b7f8 EFLAGS: 00010246 [46934.330060] RAX: 0000000000000679 RBX: ffff88004b077000 RCX: 000000000000002a [46934.330061] RDX: 0000000000000000 RSI: ffff88004b3f0500 RDI: ffff88004b077940 [46934.330061] RBP: ffff88005b72b830 R08: 00000000000000c0 R09: ffff88004a83e000 [46934.330062] R10: 000000000000ffff R11: ffff88004b1f12c0 R12: ffff88004b3f0500 [46934.330062] R13: ffff88004b3f0500 R14: 000000000000002a R15: ffff88004b077940 [46934.330063] FS: 00007fbd91a4c740(0000) GS:ffff88005f080000(0000) knlGS:0000000000000000 [46934.330064] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [46934.330064] CR2: 00007f803a8bb000 CR3: 000000004b2c9000 CR4: 00000000000406e0 [46934.330069] Stack: [46934.330071] ffffffff811e6169 00000000e772fa05 ffff88004b077000 ffff88004b3f0500 [46934.330072] ffffffff81d17d18 000000000000002a 0000000000000000 ffff88005b72b8a0 [46934.330073] ffffffff81620108 ffffffff8161fe0e ffff88005b72b8c4 ffff88005b302000 [46934.330073] Call Trace: [46934.330077] [] ? __kmalloc_node_track_caller+0x119/0x300 [46934.330084] [] dev_hard_start_xmit+0x188/0x410 [46934.330086] [] ? harmonize_features+0x2e/0x90 [46934.330088] [] __dev_queue_xmit+0x456/0x590 [46934.330089] [] dev_queue_xmit+0x10/0x20 [46934.330090] [] arp_xmit+0x22/0x60 [46934.330091] [] arp_send.part.16+0x30/0x40 [46934.330092] [] arp_solicit+0x115/0x2b0 [46934.330094] [] ? copy_skb_header+0x17/0xa0 [46934.330096] [] neigh_probe+0x4a/0x70 [46934.330097] [] __neigh_event_send+0xac/0x230 [46934.330098] [] neigh_resolve_output+0x13b/0x220 [46934.330100] [] ? ip_forward_options+0x1c0/0x1c0 [46934.330101] [] ip_finish_output+0x1f8/0x860 [46934.330102] [] ip_output+0x58/0x90 [46934.330103] [] ? __ip_local_out+0xa2/0xb0 [46934.330104] [] ip_local_out_sk+0x30/0x40 [46934.330105] [] ip_send_skb+0x16/0x50 [46934.330106] [] ip_push_pending_frames+0x33/0x40 [46934.330107] [] raw_sendmsg+0x88c/0xa30 [46934.330110] [] ? skb_recv_datagram+0x41/0x60 [46934.330111] [] ? raw_recvmsg+0xa9/0x1f0 [46934.330113] [] inet_sendmsg+0x74/0xc0 [46934.330114] [] ? inet_recvmsg+0x8b/0xb0 [46934.330115] bond0: Adding slave eth2 [46934.330116] [] sock_sendmsg+0x9c/0xe0 [46934.330118] [] ? move_addr_to_kernel.part.20+0x28/0x80 [46934.330121] [] ? might_fault+0x47/0x50 [46934.330122] [] ___sys_sendmsg+0x3a9/0x3c0 [46934.330125] [] ? n_tty_write+0x3aa/0x530 [46934.330127] [] ? __wake_up+0x44/0x50 [46934.330129] [] ? fsnotify+0x238/0x310 [46934.330130] [] __sys_sendmsg+0x51/0x90 [46934.330131] [] SyS_sendmsg+0x12/0x20 [46934.330134] [] system_call_fastpath+0x16/0x1b [46934.330144] Code: 48 8b 10 4c 89 ee 4c 89 ff e8 aa bc ff ff 31 c0 e9 1a ff ff ff 0f 1f 00 4c 89 ee 4c 89 ff e8 65 fb ff ff 31 d2 4c 89 ee 4c 89 ff b3 64 09 00 00 e8 02 bd ff ff 31 c0 e9 f2 fe ff ff 0f 1f 00 [46934.330146] RIP [] bond_start_xmit+0x1c3/0x450 [bonding] [46934.330146] RSP CC: Eric Dumazet CC: Andy Gospodarek CC: Jay Vosburgh CC: Veaceslav Falico Fixes: 278b208375 ("bonding: initial RCU conversion") Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2022f408695b5b090cca9c76804e44e84215bfda Author: WANG Cong Date: Fri Sep 5 14:33:00 2014 -0700 ipv6: restore the behavior of ipv6_sock_ac_drop() [ Upstream commit de185ab46cb02df9738b0d898b0c3a89181c5526 ] It is possible that the interface is already gone after joining the list of anycast on this interface as we don't hold a refcount for the device, in this case we are safe to ignore the error. What's more important, for API compatibility we should not change this behavior for applications even if it were correct. Fixes: commit a9ed4a2986e13011 ("ipv6: fix rtnl locking in setsockopt for anycast and multicast") Cc: Sabrina Dubroca Cc: David S. Miller Signed-off-by: Cong Wang Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e9d3d9a67d94617c23e3fbafa3e580741634f6bd Author: Guillaume Nault Date: Wed Sep 3 14:12:55 2014 +0200 l2tp: fix race while getting PMTU on PPP pseudo-wire [ Upstream commit eed4d839b0cdf9d84b0a9bc63de90fd5e1e886fb ] Use dst_entry held by sk_dst_get() to retrieve tunnel's PMTU. The dst_mtu(__sk_dst_get(tunnel->sock)) call was racy. __sk_dst_get() could return NULL if tunnel->sock->sk_dst_cache was reset just before the call, thus making dst_mtu() dereference a NULL pointer: [ 1937.661598] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [ 1937.664005] IP: [] pppol2tp_connect+0x33d/0x41e [l2tp_ppp] [ 1937.664005] PGD daf0c067 PUD d9f93067 PMD 0 [ 1937.664005] Oops: 0000 [#1] SMP [ 1937.664005] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables udp_tunnel pppoe pppox ppp_generic slhc deflate ctr twofish_generic twofish_x86_64_3way xts lrw gf128mul glue_helper twofish_x86_64 twofish_common blowfish_generic blowfish_x86_64 blowfish_common des_generic cbc xcbc rmd160 sha512_generic hmac crypto_null af_key xfrm_algo 8021q garp bridge stp llc tun atmtcp clip atm ext3 mbcache jbd iTCO_wdt coretemp kvm_intel iTCO_vendor_support kvm pcspkr evdev ehci_pci lpc_ich mfd_core i5400_edac edac_core i5k_amb shpchp button processor thermal_sys xfs crc32c_generic libcrc32c dm_mod usbhid sg hid sr_mod sd_mod cdrom crc_t10dif crct10dif_common ata_generic ahci ata_piix tg3 libahci libata uhci_hcd ptp ehci_hcd pps_core usbcore scsi_mod libphy usb_common [last unloaded: l2tp_core] [ 1937.664005] CPU: 0 PID: 10022 Comm: l2tpstress Tainted: G O 3.17.0-rc1 #1 [ 1937.664005] Hardware name: HP ProLiant DL160 G5, BIOS O12 08/22/2008 [ 1937.664005] task: ffff8800d8fda790 ti: ffff8800c43c4000 task.ti: ffff8800c43c4000 [ 1937.664005] RIP: 0010:[] [] pppol2tp_connect+0x33d/0x41e [l2tp_ppp] [ 1937.664005] RSP: 0018:ffff8800c43c7de8 EFLAGS: 00010282 [ 1937.664005] RAX: ffff8800da8a7240 RBX: ffff8800d8c64600 RCX: 000001c325a137b5 [ 1937.664005] RDX: 8c6318c6318c6320 RSI: 000000000000010c RDI: 0000000000000000 [ 1937.664005] RBP: ffff8800c43c7ea8 R08: 0000000000000000 R09: 0000000000000000 [ 1937.664005] R10: ffffffffa048e2c0 R11: ffff8800d8c64600 R12: ffff8800ca7a5000 [ 1937.664005] R13: ffff8800c439bf40 R14: 000000000000000c R15: 0000000000000009 [ 1937.664005] FS: 00007fd7f610f700(0000) GS:ffff88011a600000(0000) knlGS:0000000000000000 [ 1937.664005] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1937.664005] CR2: 0000000000000020 CR3: 00000000d9d75000 CR4: 00000000000027e0 [ 1937.664005] Stack: [ 1937.664005] ffffffffa049da80 ffff8800d8fda790 000000000000005b ffff880000000009 [ 1937.664005] ffff8800daf3f200 0000000000000003 ffff8800c43c7e48 ffffffff81109b57 [ 1937.664005] ffffffff81109b0e ffffffff8114c566 0000000000000000 0000000000000000 [ 1937.664005] Call Trace: [ 1937.664005] [] ? pppol2tp_connect+0x235/0x41e [l2tp_ppp] [ 1937.664005] [] ? might_fault+0x9e/0xa5 [ 1937.664005] [] ? might_fault+0x55/0xa5 [ 1937.664005] [] ? rcu_read_unlock+0x1c/0x26 [ 1937.664005] [] SYSC_connect+0x87/0xb1 [ 1937.664005] [] ? sysret_check+0x1b/0x56 [ 1937.664005] [] ? trace_hardirqs_on_caller+0x145/0x1a1 [ 1937.664005] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 1937.664005] [] ? spin_lock+0x9/0xb [ 1937.664005] [] SyS_connect+0x9/0xb [ 1937.664005] [] system_call_fastpath+0x16/0x1b [ 1937.664005] Code: 10 2a 84 81 e8 65 76 bd e0 65 ff 0c 25 10 bb 00 00 4d 85 ed 74 37 48 8b 85 60 ff ff ff 48 8b 80 88 01 00 00 48 8b b8 10 02 00 00 <48> 8b 47 20 ff 50 20 85 c0 74 0f 83 e8 28 89 83 10 01 00 00 89 [ 1937.664005] RIP [] pppol2tp_connect+0x33d/0x41e [l2tp_ppp] [ 1937.664005] RSP [ 1937.664005] CR2: 0000000000000020 [ 1939.559375] ---[ end trace 82d44500f28f8708 ]--- Fixes: f34c4a35d879 ("l2tp: take PMTU from tunnel UDP socket") Signed-off-by: Guillaume Nault Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e06d2bcb5b9918e3674198c32fce1a4524d11d40 Author: Sabrina Dubroca Date: Tue Sep 2 10:29:29 2014 +0200 ipv6: fix rtnl locking in setsockopt for anycast and multicast [ Upstream commit a9ed4a2986e13011fcf4ed2d1a1647c53112f55b ] Calling setsockopt with IPV6_JOIN_ANYCAST or IPV6_LEAVE_ANYCAST triggers the assertion in addrconf_join_solict()/addrconf_leave_solict() ipv6_sock_ac_join(), ipv6_sock_ac_drop(), ipv6_sock_ac_close() need to take RTNL before calling ipv6_dev_ac_inc/dec. Same thing with ipv6_sock_mc_join(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before calling ipv6_dev_mc_inc/dec. This patch moves ASSERT_RTNL() up a level in the call stack. Signed-off-by: Cong Wang Signed-off-by: Sabrina Dubroca Reported-by: Tommi Rantala Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit af3e4e5dc0f46c876f99b0f8cc3987fac4741593 Author: Michal Kubeček Date: Mon Aug 25 15:16:22 2014 +0200 net: fix checksum features handling in netif_skb_features() [ Upstream commit db115037bb57cdfe97078b13da762213f7980e81 ] This is follow-up to da08143b8520 ("vlan: more careful checksum features handling") which introduced more careful feature intersection in vlan code, taking into account that HW_CSUM should be considered superset of IP_CSUM/IPV6_CSUM. The same is needed in netif_skb_features() in order to avoid offloading mismatch warning when vlan is created on top of a bond consisting of slaves supporting IP/IPv6 checksumming but not vlan Tx offloading. Signed-off-by: Michal Kubecek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cd80ab0c938e779d923342ae99e9d6050b2fc1bc Author: Gerhard Stenzel Date: Fri Aug 22 21:34:16 2014 +0200 vxlan: fix incorrect initializer in union vxlan_addr [ Upstream commit a45e92a599e77ee6a850eabdd0141633fde03915 ] The first initializer in the following union vxlan_addr ipa = { .sin.sin_addr.s_addr = tip, .sa.sa_family = AF_INET, }; is optimised away by the compiler, due to the second initializer, therefore initialising .sin.sin_addr.s_addr always to 0. This results in netlink messages indicating a L3 miss never contain the missed IP address. This was observed with GCC 4.8 and 4.9. I do not know about previous versions. The problem affects user space programs relying on an IP address being sent as part of a netlink message indicating a L3 miss. Changing .sa.sa_family = AF_INET, to .sin.sin_family = AF_INET, fixes the problem. Signed-off-by: Gerhard Stenzel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 18460f5f755d33d141bfe8eea325f80c0d01d26b Author: Jiri Benc Date: Thu Aug 21 21:33:44 2014 +0200 openvswitch: fix panic with multiple vlan headers [ Upstream commit 2ba5af42a7b59ef01f9081234d8855140738defd ] When there are multiple vlan headers present in a received frame, the first one is put into vlan_tci and protocol is set to ETH_P_8021Q. Anything in the skb beyond the VLAN TPID may be still non-linear, including the inner TCI and ethertype. While ovs_flow_extract takes care of IP and IPv6 headers, it does nothing with ETH_P_8021Q. Later, if OVS_ACTION_ATTR_POP_VLAN is executed, __pop_vlan_tci pulls the next vlan header into vlan_tci. This leads to two things: 1. Part of the resulting ethernet header is in the non-linear part of the skb. When eth_type_trans is called later as the result of OVS_ACTION_ATTR_OUTPUT, kernel BUGs in __skb_pull. Also, __pop_vlan_tci is in fact accessing random data when it reads past the TPID. 2. network_header points into the ethernet header instead of behind it. mac_len is set to a wrong value (10), too. Reported-by: Yulong Pei Signed-off-by: Jiri Benc Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3f719b11a33f06ace77cb0ef6e0b637968c81683 Author: Benjamin Block Date: Thu Aug 21 19:37:48 2014 +0200 net: ipv6: fib: don't sleep inside atomic lock [ Upstream commit 793c3b4000a1ef611ae7e5c89bd2a9c6b776cb5e ] The function fib6_commit_metrics() allocates a piece of memory in mode GFP_KERNEL while holding an atomic lock from higher up in the stack, in the function __ip6_ins_rt(). This produces the following BUG: > BUG: sleeping function called from invalid context at mm/slub.c:1250 > in_atomic(): 1, irqs_disabled(): 0, pid: 2909, name: dhcpcd > 2 locks held by dhcpcd/2909: > #0: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x20 > #1: (&tb->tb6_lock){++--+.}, at: [] ip6_route_add+0x65a/0x800 > CPU: 1 PID: 2909 Comm: dhcpcd Not tainted 3.17.0-rc1 #1 > Hardware name: ASUS All Series/Q87T, BIOS 0216 10/16/2013 > 0000000000000008 ffff8800c8f13858 ffffffff81af135a 0000000000000000 > ffff880212202430 ffff8800c8f13878 ffffffff810f8d3a ffff880212202c98 > 0000000000000010 ffff8800c8f138c8 ffffffff8121ad0e 0000000000000001 > Call Trace: > [] dump_stack+0x4e/0x68 > [] __might_sleep+0x10a/0x120 > [] kmem_cache_alloc_trace+0x4e/0x190 > [] ? fib6_commit_metrics+0x66/0x110 > [] fib6_commit_metrics+0x66/0x110 > [] fib6_add+0x883/0xa80 > [] ? ip6_route_add+0x65a/0x800 > [] ip6_route_add+0x675/0x800 > [] ? ip6_route_add+0x6a/0x800 > [] inet6_rtm_newroute+0x5c/0x80 > [] rtnetlink_rcv_msg+0x211/0x260 > [] ? rtnl_lock+0x17/0x20 > [] ? lock_release_holdtime+0x28/0x180 > [] ? rtnl_lock+0x17/0x20 > [] ? __rtnl_unlock+0x20/0x20 > [] netlink_rcv_skb+0x6e/0xd0 > [] rtnetlink_rcv+0x25/0x40 > [] netlink_unicast+0xd9/0x180 > [] netlink_sendmsg+0x700/0x770 > [] ? local_clock+0x25/0x30 > [] sock_sendmsg+0x6c/0x90 > [] ? might_fault+0xa3/0xb0 > [] ? verify_iovec+0x7d/0xf0 > [] ___sys_sendmsg+0x37e/0x3b0 > [] ? trace_hardirqs_on_caller+0x185/0x220 > [] ? mutex_unlock+0xe/0x10 > [] ? netlink_insert+0xbc/0xe0 > [] ? netlink_autobind.isra.30+0x125/0x150 > [] ? netlink_autobind.isra.30+0x60/0x150 > [] ? netlink_bind+0x159/0x230 > [] ? might_fault+0x5a/0xb0 > [] ? SYSC_bind+0x7e/0xd0 > [] __sys_sendmsg+0x4d/0x80 > [] SyS_sendmsg+0x12/0x20 > [] system_call_fastpath+0x16/0x1b Fixing this by replacing the mode GFP_KERNEL with GFP_ATOMIC. Signed-off-by: Benjamin Block Acked-by: David Rientjes Acked-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 39f5b1eb97a52c24118d04d2f889e48682476eaf Author: Yuval Mintz Date: Mon Aug 18 22:36:23 2014 +0300 bnx2x: Revert UNDI flushing mechanism [ Upstream commit 7c3afd85dc1610bb2fc049644cd1b52c7af96f98 ] Commit 91ebb929b6f8 ("bnx2x: Add support for Multi-Function UNDI") [which was later supposedly fixed by de682941eef3 ("bnx2x: Fix UNDI driver unload")] introduced a bug in which in some [yet-to-be-determined] scenarios the alternative flushing mechanism which was to guarantee the Rx buffers are empty before resetting them during device probe will fail. If this happens, when device will be loaded once more a fatal attention will occur; Since this most likely happens in boot from SAN scenarios, the machine will fail to load. Notice this may occur not only in the 'Multi-Function' scenario but in the regular scenario as well, i.e., this introduced a regression in the driver's ability to perform boot from SAN. The patch reverts the mechanism and applies the old scheme to multi-function devices as well as to single-function devices. Signed-off-by: Yuval Mintz Signed-off-by: Ariel Elior Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 29c755699db1ca0fb7c81324ed24255ecef3e97f Author: Eric Dumazet Date: Fri Aug 15 09:16:04 2014 -0700 packet: handle too big packets for PACKET_V3 [ Upstream commit dc808110bb62b64a448696ecac3938902c92e1ab ] af_packet can currently overwrite kernel memory by out of bound accesses, because it assumed a [new] block can always hold one frame. This is not generally the case, even if most existing tools do it right. This patch clamps too long frames as API permits, and issue a one time error on syslog. [ 394.357639] tpacket_rcv: packet too big, clamped from 5042 to 3966. macoff=82 In this example, packet header tp_snaplen was set to 3966, and tp_len was set to 5042 (skb->len) Signed-off-by: Eric Dumazet Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.") Acked-by: Daniel Borkmann Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8ef544dce03e2d04a0faf56917ceb07cf5112b31 Author: Erik Hugne Date: Fri Aug 15 16:44:35 2014 +0200 tipc: fix message importance range check [ Upstream commit ac32c7f705692b92fe12dcbe88fe87136fdfff6f ] Commit 3b4f302d8578 ("tipc: eliminate redundant locking") introduced a bug by removing the sanity check for message importance, allowing programs to assign any value to the msg_user field. This will mess up the packet reception logic and may cause random link resets. Signed-off-by: Erik Hugne Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4775bfac32c89bfca5ab19e7465b4d8d53353296 Author: Gwenhael Goavec-Merou Date: Fri Aug 15 15:00:38 2014 +0200 net: phy: smsc: move smsc_phy_config_init reset part in a soft_reset function [ Upstream commit 21009686662fd21412ca35def7cb3cc8346e1c3d ] On the one hand, phy_device.c provides a generic reset function if the phy driver does not provide a soft_reset pointer. This generic reset does not take into account the state of the phy, with a potential failure if the phy is in powerdown mode. On the other hand, smsc driver provides a function with both correct reset behaviour and configuration. This patch moves the reset part into a new smsc_phy_reset function and provides the soft_reset pointer to have a correct reset behaviour by default. Signed-off-by: Gwenhael Goavec-Merou Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 638228c589bb5021e160983e10dc296eee2703ce Author: Neal Cardwell Date: Thu Aug 14 16:13:07 2014 -0400 tcp: fix ssthresh and undo for consecutive short FRTO episodes [ Upstream commit 0c9ab09223fe9922baeb22546c9a90d774a4bde6 ] Fix TCP FRTO logic so that it always notices when snd_una advances, indicating that any RTO after that point will be a new and distinct loss episode. Previously there was a very specific sequence that could cause FRTO to fail to notice a new loss episode had started: (1) RTO timer fires, enter FRTO and retransmit packet 1 in write queue (2) receiver ACKs packet 1 (3) FRTO sends 2 more packets (4) RTO timer fires again (should start a new loss episode) The problem was in step (3) above, where tcp_process_loss() returned early (in the spot marked "Step 2.b"), so that it never got to the logic to clear icsk_retransmits. Thus icsk_retransmits stayed non-zero. Thus in step (4) tcp_enter_loss() would see the non-zero icsk_retransmits, decide that this RTO is not a new episode, and decide not to cut ssthresh and remember the current cwnd and ssthresh for undo. There were two main consequences to the bug that we have observed. First, ssthresh was not decreased in step (4). Second, when there was a series of such FRTO (1-4) sequences that happened to be followed by an FRTO undo, we would restore the cwnd and ssthresh from before the entire series started (instead of the cwnd and ssthresh from before the most recent RTO). This could result in cwnd and ssthresh being restored to values much bigger than the proper values. Signed-off-by: Neal Cardwell Signed-off-by: Yuchung Cheng Fixes: e33099f96d99c ("tcp: implement RFC5682 F-RTO") Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 72dcbec4fce2c3e60f3a09f042076844386ee1b6 Author: Neal Cardwell Date: Thu Aug 14 12:40:05 2014 -0400 tcp: fix tcp_release_cb() to dispatch via address family for mtu_reduced() [ Upstream commit 4fab9071950c2021d846e18351e0f46a1cffd67b ] Make sure we use the correct address-family-specific function for handling MTU reductions from within tcp_release_cb(). Previously AF_INET6 sockets were incorrectly always using the IPv6 code path when sometimes they were handling IPv4 traffic and thus had an IPv4 dst. Signed-off-by: Neal Cardwell Signed-off-by: Eric Dumazet Diagnosed-by: Willem de Bruijn Fixes: 563d34d057862 ("tcp: dont drop MTU reduction indications") Reviewed-by: Hannes Frederic Sowa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e72790ed87c2c9f7b4aaf825b0f33b10e576a374 Author: Shmulik Ladkani Date: Thu Aug 14 15:27:20 2014 +0300 sit: Fix ipip6_tunnel_lookup device matching criteria [ Upstream commit bc8fc7b8f825ef17a0fb9e68c18ce94fa66ab337 ] As of 4fddbf5d78 ("sit: strictly restrict incoming traffic to tunnel link device"), when looking up a tunnel, tunnel's underlying interface (t->parms.link) is verified to match incoming traffic's ingress device. However the comparison was incorrectly based on skb->dev->iflink. Instead, dev->ifindex should be used, which correctly represents the interface from which the IP stack hands the ipip6 packets. This allows setting up sit tunnels bound to vlan interfaces (otherwise incoming ipip6 traffic on the vlan interface was dropped due to ipip6_tunnel_lookup match failure). Signed-off-by: Shmulik Ladkani Acked-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 485181129a34abde9ebd08c25fba2a55bd62ce52 Author: Andrey Vagin Date: Wed Aug 13 16:03:10 2014 +0400 tcp: don't use timestamp from repaired skb-s to calculate RTT (v2) [ Upstream commit 9d186cac7ffb1831e9f34cb4a3a8b22abb9dd9d4 ] We don't know right timestamp for repaired skb-s. Wrong RTT estimations isn't good, because some congestion modules heavily depends on it. This patch adds the TCPCB_REPAIRED flag, which is included in TCPCB_RETRANS. Thanks to Eric for the advice how to fix this issue. This patch fixes the warning: [ 879.562947] WARNING: CPU: 0 PID: 2825 at net/ipv4/tcp_input.c:3078 tcp_ack+0x11f5/0x1380() [ 879.567253] CPU: 0 PID: 2825 Comm: socket-tcpbuf-l Not tainted 3.16.0-next-20140811 #1 [ 879.567829] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 879.568177] 0000000000000000 00000000c532680c ffff880039643d00 ffffffff817aa2d2 [ 879.568776] 0000000000000000 ffff880039643d38 ffffffff8109afbd ffff880039d6ba80 [ 879.569386] ffff88003a449800 000000002983d6bd 0000000000000000 000000002983d6bc [ 879.569982] Call Trace: [ 879.570264] [] dump_stack+0x4d/0x66 [ 879.570599] [] warn_slowpath_common+0x7d/0xa0 [ 879.570935] [] warn_slowpath_null+0x1a/0x20 [ 879.571292] [] tcp_ack+0x11f5/0x1380 [ 879.571614] [] tcp_rcv_established+0x1ed/0x710 [ 879.571958] [] tcp_v4_do_rcv+0x10a/0x370 [ 879.572315] [] release_sock+0x89/0x1d0 [ 879.572642] [] do_tcp_setsockopt.isra.36+0x120/0x860 [ 879.573000] [] ? rcu_read_lock_held+0x6e/0x80 [ 879.573352] [] tcp_setsockopt+0x32/0x40 [ 879.573678] [] sock_common_setsockopt+0x14/0x20 [ 879.574031] [] SyS_setsockopt+0x80/0xf0 [ 879.574393] [] system_call_fastpath+0x16/0x1b [ 879.574730] ---[ end trace a17cbc38eb8c5c00 ]--- v2: moving setting of skb->when for repaired skb-s in tcp_write_xmit, where it's set for other skb-s. Fixes: 431a91242d8d ("tcp: timestamp SYN+DATA messages") Fixes: 740b0f1841f6 ("tcp: switch rtt estimations to usec resolution") Cc: Eric Dumazet Cc: Pavel Emelyanov Cc: "David S. Miller" Signed-off-by: Andrey Vagin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit de25adff9abb0f09462d5786232c496c2d7c5f55 Author: David S. Miller Date: Thu Aug 14 14:32:49 2014 -0700 Revert "macvlan: simplify the structure port" [ Upstream commit 5e3c516b512c0f8f18359413b04918f6347f67e7 ] This reverts commit a188a54d11629bef2169052297e61f3767ca8ce5. It causes crashes ==================== [ 80.643286] BUG: unable to handle kernel NULL pointer dereference at 0000000000000878 [ 80.670103] IP: [] try_to_grab_pending+0x64/0x1f0 [ 80.691289] PGD 22c102067 PUD 235bf0067 PMD 0 [ 80.706611] Oops: 0002 [#1] SMP [ 80.717836] Modules linked in: macvlan nfsd lockd nfs_acl exportfs auth_rpcgss sunrpc oid_registry ioatdma ixgbe(-) mdio igb dca [ 80.757935] CPU: 37 PID: 6724 Comm: rmmod Not tainted 3.16.0-net-next-08-12-2014-FCoE+ #1 [ 80.785688] Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.03.0003.041920141333 04/19/2014 [ 80.820310] task: ffff880235a9eae0 ti: ffff88022e844000 task.ti: ffff88022e844000 [ 80.845770] RIP: 0010:[] [] try_to_grab_pending+0x64/0x1f0 [ 80.875326] RSP: 0018:ffff88022e847b28 EFLAGS: 00010046 [ 80.893251] RAX: 0000000000037a6a RBX: 0000000000000878 RCX: 0000000000000000 [ 80.917187] RDX: ffff880235a9eae0 RSI: 0000000000000001 RDI: ffffffff810832db [ 80.941125] RBP: ffff88022e847b58 R08: 0000000000000000 R09: 0000000000000000 [ 80.965056] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88022e847b70 [ 80.988994] R13: 0000000000000000 R14: ffff88022e847be8 R15: ffffffff81ebe440 [ 81.012929] FS: 00007fab90b07700(0000) GS:ffff88043f7a0000(0000) knlGS:0000000000000000 [ 81.040400] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 81.059757] CR2: 0000000000000878 CR3: 0000000235a42000 CR4: 00000000001407e0 [ 81.083689] Stack: [ 81.090739] ffff880235a9eae0 0000000000000878 ffff88022e847b70 0000000000000000 [ 81.116253] ffff88022e847be8 ffffffff81ebe440 ffff88022e847b98 ffffffff810847f1 [ 81.141766] ffff88022e847b78 0000000000000286 ffff880234200000 0000000000000000 [ 81.167282] Call Trace: [ 81.175768] [] __cancel_work_timer+0x31/0x170 [ 81.195985] [] cancel_work_sync+0xb/0x10 [ 81.214769] [] macvlan_port_destroy+0x28/0x60 [macvlan] [ 81.237844] [] macvlan_uninit+0x40/0x50 [macvlan] [ 81.259209] [] rollback_registered_many+0x1a2/0x2c0 [ 81.281140] [] unregister_netdevice_many+0x1a/0xb0 [ 81.302786] [] macvlan_device_event+0x1ef/0x240 [macvlan] [ 81.326439] [] notifier_call_chain+0x4d/0x70 [ 81.346366] [] raw_notifier_call_chain+0x11/0x20 [ 81.367439] [] call_netdevice_notifiers_info+0x3b/0x70 [ 81.390228] [] call_netdevice_notifiers+0x11/0x20 [ 81.411587] [] rollback_registered_many+0x17d/0x2c0 [ 81.433518] [] unregister_netdevice_queue+0x75/0x110 [ 81.455735] [] unregister_netdev+0x1b/0x30 [ 81.475094] [] ixgbe_remove+0x170/0x1d0 [ixgbe] [ 81.495886] [] pci_device_remove+0x32/0x60 [ 81.515246] [] __device_release_driver+0x64/0xd0 [ 81.536321] [] driver_detach+0xc8/0xd0 [ 81.554530] [] bus_remove_driver+0x4e/0xa0 [ 81.573888] [] driver_unregister+0x2b/0x60 [ 81.593246] [] pci_unregister_driver+0x1e/0xa0 [ 81.613749] [] ixgbe_exit_module+0x1c/0x2e [ixgbe] [ 81.635401] [] SyS_delete_module+0x15b/0x1e0 [ 81.655334] [] ? sysret_check+0x22/0x5d [ 81.673833] [] ? trace_hardirqs_on_caller+0x11d/0x1e0 [ 81.696339] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 81.717985] [] system_call_fastpath+0x16/0x1b [ 81.738199] Code: 00 48 83 3d 6e bb da 00 00 48 89 c2 0f 84 67 01 00 00 fa 66 0f 1f 44 00 00 49 89 14 24 e8 b5 4b 02 00 45 84 ed 0f 85 ac 00 00 00 0f ba 2b 00 72 1d 31 c0 48 8b 5d d8 4c 8b 65 e0 4c 8b 6d e8 [ 81.807026] RIP [] try_to_grab_pending+0x64/0x1f0 [ 81.828468] RSP [ 81.840384] CR2: 0000000000000878 [ 81.851731] ---[ end trace 9f6c7232e3464e11 ]--- ==================== This bug could be triggered by these steps: modprobe ixgbe ; modprobe macvlan ip link add link p96p1 address 00:1B:21:6E:06:00 macvlan0 type macvlan ip link add link p96p1 address 00:1B:21:6E:06:01 macvlan1 type macvlan ip link add link p96p1 address 00:1B:21:6E:06:02 macvlan2 type macvlan ip link add link p96p1 address 00:1B:21:6E:06:03 macvlan3 type macvlan rmmod ixgbe Reported-by: "Keller, Jacob E" Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a378b94234254d4c18f7ee9518fce44947bc4f68 Author: Stanislaw Gruszka Date: Tue Aug 12 10:35:19 2014 +0200 myri10ge: check for DMA mapping errors [ Upstream commit 10545937e866ccdbb7ab583031dbdcc6b14e4eb4 ] On IOMMU systems DMA mapping can fail, we need to check for that possibility. Signed-off-by: Stanislaw Gruszka Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 84beb1a9999475ea1d25629345119da137474853 Author: Vlad Yasevich Date: Fri Aug 8 14:42:13 2014 -0400 net: Always untag vlan-tagged traffic on input. [ Upstream commit 0d5501c1c828fb97d02af50aa9d2b1a5498b94e4 ] Currently the functionality to untag traffic on input resides as part of the vlan module and is build only when VLAN support is enabled in the kernel. When VLAN is disabled, the function vlan_untag() turns into a stub and doesn't really untag the packets. This seems to create an interesting interaction between VMs supporting checksum offloading and some network drivers. There are some drivers that do not allow the user to change tx-vlan-offload feature of the driver. These drivers also seem to assume that any VLAN-tagged traffic they transmit will have the vlan information in the vlan_tci and not in the vlan header already in the skb. When transmitting skbs that already have tagged data with partial checksum set, the checksum doesn't appear to be updated correctly by the card thus resulting in a failure to establish TCP connections. The following is a packet trace taken on the receiver where a sender is a VM with a VLAN configued. The host VM is running on doest not have VLAN support and the outging interface on the host is tg3: 10:12:43.503055 52:54:00:ae:42:3f > 28:d2:44:7d:c2:de, ethertype 802.1Q (0x8100), length 78: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 27243, offset 0, flags [DF], proto TCP (6), length 60) 10.0.100.1.58545 > 10.0.100.10.ircu-2: Flags [S], cksum 0xdc39 (incorrect -> 0x48d9), seq 1069378582, win 29200, options [mss 1460,sackOK,TS val 4294837885 ecr 0,nop,wscale 7], length 0 10:12:44.505556 52:54:00:ae:42:3f > 28:d2:44:7d:c2:de, ethertype 802.1Q (0x8100), length 78: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 27244, offset 0, flags [DF], proto TCP (6), length 60) 10.0.100.1.58545 > 10.0.100.10.ircu-2: Flags [S], cksum 0xdc39 (incorrect -> 0x44ee), seq 1069378582, win 29200, options [mss 1460,sackOK,TS val 4294838888 ecr 0,nop,wscale 7], length 0 This connection finally times out. I've only access to the TG3 hardware in this configuration thus have only tested this with TG3 driver. There are a lot of other drivers that do not permit user changes to vlan acceleration features, and I don't know if they all suffere from a similar issue. The patch attempt to fix this another way. It moves the vlan header stipping code out of the vlan module and always builds it into the kernel network core. This way, even if vlan is not supported on a virtualizatoin host, the virtual machines running on top of such host will still work with VLANs enabled. CC: Patrick McHardy CC: Nithin Nayak Sujir CC: Michael Chan CC: Jiri Pirko Signed-off-by: Vladislav Yasevich Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 53f8c7d24b35eecf20831e0b557a142a4d64e256 Author: Jiri Benc Date: Fri Aug 8 16:44:32 2014 +0200 rtnetlink: fix VF info size [ Upstream commit 945a36761fd7877660f630bbdeb4ff9ff80d1935 ] Commit 1d8faf48c74b8 ("net/core: Add VF link state control") added new attribute to IFLA_VF_INFO group in rtnl_fill_ifinfo but did not adjust size of the allocated memory in if_nlmsg_size/rtnl_vfinfo_size. As the result, we may trigger warnings in rtnl_getlink and similar functions when many VF links are enabled, as the information does not fit into the allocated skb. Fixes: 1d8faf48c74b8 ("net/core: Add VF link state control") Reported-by: Yulong Pei Signed-off-by: Jiri Benc Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 47a0ff6c6d10ad4479a0d056bc02c69b0fc55729 Author: Daniel Borkmann Date: Thu Aug 7 22:22:47 2014 +0200 netlink: reset network header before passing to taps [ Upstream commit 4e48ed883c72e78c5a910f8831ffe90c9b18f0ec ] netlink doesn't set any network header offset thus when the skb is being passed to tap devices via dev_queue_xmit_nit(), it emits klog false positives due to it being unset like: ... [ 124.990397] protocol 0000 is buggy, dev nlmon0 [ 124.990411] protocol 0000 is buggy, dev nlmon0 ... So just reset the network header before passing to the device; for packet sockets that just means nothing will change - mac and net offset hold the same value just as before. Reported-by: Marcel Holtmann Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman