commit d9ea51a9bea4ed29f8fd9c59a8122c7aabcc5562 Author: Greg Kroah-Hartman Date: Sun Jan 15 13:41:49 2017 +0100 Linux 4.4.43 commit e21901d7a5eb2d41109847dc0ae08c97bba933d7 Author: Oliver O'Halloran Date: Tue Jul 26 15:22:17 2016 -0700 mm/init: fix zone boundary creation commit 90cae1fe1c3540f791d5b8e025985fa5e699b2bb upstream. As a part of memory initialisation the architecture passes an array to free_area_init_nodes() which specifies the max PFN of each memory zone. This array is not necessarily monotonic (due to unused zones) so this array is parsed to build monotonic lists of the min and max PFN for each zone. ZONE_MOVABLE is special cased here as its limits are managed by the mm subsystem rather than the architecture. Unfortunately, this special casing is broken when ZONE_MOVABLE is the not the last zone in the zone list. The core of the issue is: if (i == ZONE_MOVABLE) continue; arch_zone_lowest_possible_pfn[i] = arch_zone_highest_possible_pfn[i-1]; As ZONE_MOVABLE is skipped the lowest_possible_pfn of the next zone will be set to zero. This patch fixes this bug by adding explicitly tracking where the next zone should start rather than relying on the contents arch_zone_highest_possible_pfn[]. Thie is low priority. To get bitten by this you need to enable a zone that appears after ZONE_MOVABLE in the zone_type enum. As far as I can tell this means running a kernel with ZONE_DEVICE or ZONE_CMA enabled, so I can't see this affecting too many people. I only noticed this because I've been fiddling with ZONE_DEVICE on powerpc and 4.6 broke my test kernel. This bug, in conjunction with the changes in Taku Izumi's kernelcore=mirror patch (d91749c1dda71) and powerpc being the odd architecture which initialises max_zone_pfn[] to ~0ul instead of 0 caused all of system memory to be placed into ZONE_DEVICE at boot, followed a panic since device memory cannot be used for kernel allocations. I've already submitted a patch to fix the powerpc specific bits, but I figured this should be fixed too. Link: http://lkml.kernel.org/r/1462435033-15601-1-git-send-email-oohall@gmail.com Signed-off-by: Oliver O'Halloran Cc: Anton Blanchard Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit e3f77bb158f9cc18c5fae6b09523fb7ce05934a5 Author: Dennis Kadioglu Date: Mon Jan 9 17:10:46 2017 +0100 ALSA: usb-audio: Add a quirk for Plantronics BT600 commit 2e40795c3bf344cfb5220d94566205796e3ef19a upstream. Plantronics BT600 does not support reading the sample rate which leads to many lines of "cannot get freq at ep 0x1" and "cannot get freq at ep 0x82". This patch adds the USB ID of the BT600 to quirks.c and avoids those error messages. Signed-off-by: Dennis Kadioglu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a1c81f839c6fbd73592be089106cceab948e6770 Author: Uwe Kleine-König Date: Thu Dec 8 17:37:08 2016 +0100 spi: mvebu: fix baudrate calculation for armada variant commit 7243e0b20729d372e97763617a7a9c89f29b33e1 upstream. The calculation of SPR and SPPR doesn't round correctly at several places which might result in baud rates that are too big. For example with tclk_hz = 250000001 and target rate 25000000 it determined a divider of 10 which is wrong. Instead of fixing all the corner cases replace the calculation by an algorithm without a loop which should even be quicker to execute apart from being correct. Fixes: df59fa7f4bca ("spi: orion: support armada extended baud rates") Signed-off-by: Uwe Kleine-König Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit dfd64d112a020c42e9fb9f42ff0c15dac961e070 Author: Tony Lindgren Date: Mon Nov 7 16:50:11 2016 -0700 ARM: OMAP4+: Fix bad fallthrough for cpuidle commit cbf2642872333547b56b8c4d943f5ed04ac9a4ee upstream. We don't want to fall through to a bunch of errors for retention if PM_OMAP4_CPU_OSWR_DISABLE is not configured for a SoC. Fixes: 6099dd37c669 ("ARM: OMAP5 / DRA7: Enable CPU RET on suspend") Acked-by: Santosh Shilimkar Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit 04dc1be104fee1df74c34a067c45d0e953a1d324 Author: Kyle Roeschley Date: Mon Oct 31 11:26:17 2016 -0500 ARM: zynq: Reserve correct amount of non-DMA RAM commit 7a3cc2a7b2c723aa552028f4e66841cec183756d upstream. On Zynq, we haven't been reserving the correct amount of DMA-incapable RAM to keep DMA away from it (per the Zynq TRM Section 4.1, it should be the first 512k). In older kernels, this was masked by the memblock_reserve call in arm_memblock_init(). Now, reserve the correct amount excplicitly rather than relying on swapper_pg_dir, which is an address and not a size anyway. Fixes: 46f5b96 ("ARM: zynq: Reserve not DMAable space in front of the kernel") Signed-off-by: Kyle Roeschley Tested-by: Nathan Rossi Signed-off-by: Michal Simek Signed-off-by: Greg Kroah-Hartman commit bed280bbc995d0dc94e26f4935d35c3f257bdc7e Author: Larry Finger Date: Thu Dec 22 21:06:53 2016 -0600 powerpc: Fix build warning on 32-bit PPC commit 8ae679c4bc2ea2d16d92620da8e3e9332fa4039f upstream. I am getting the following warning when I build kernel 4.9-git on my PowerBook G4 with a 32-bit PPC processor: AS arch/powerpc/kernel/misc_32.o arch/powerpc/kernel/misc_32.S:299:7: warning: "CONFIG_FSL_BOOKE" is not defined [-Wundef] This problem is evident after commit 989cea5c14be ("kbuild: prevent lib-ksyms.o rebuilds"); however, this change in kbuild only exposes an error that has been in the code since 2005 when this source file was created. That was with commit 9994a33865f4 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, systbl.S"). The offending line does not make a lot of sense. This error does not seem to cause any errors in the executable, thus I am not recommending that it be applied to any stable versions. Thanks to Nicholas Piggin for suggesting this solution. Fixes: 9994a33865f4 ("powerpc: Introduce entry_{32,64}.S, misc_{32,64}.S, systbl.S") Signed-off-by: Larry Finger Cc: Nicholas Piggin Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fa48a16075809542225f703a5d01598c914d2502 Author: Takashi Sakamoto Date: Tue Jan 3 11:58:33 2017 +0900 ALSA: firewire-tascam: Fix to handle error from initialization of stream data commit 6a2a2f45560a9cb7bc49820883b042e44f83726c upstream. This module has a bug not to return error code in a case that data structure for transmitted packets fails to be initialized. This commit fixes the bug. Fixes: 35efa5c489de ("ALSA: firewire-tascam: add streaming functionality") Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a2f727149ee4e746da55d209a0179b68d31d3915 Author: Greg Kroah-Hartman Date: Fri Jan 6 15:33:36 2017 +0100 HID: hid-cypress: validate length of report commit 1ebb71143758f45dc0fa76e2f48429e13b16d110 upstream. Make sure we have enough of a report structure to validate before looking at it. Reported-by: Benoit Camredon Tested-by: Benoit Camredon Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Kosina commit 70e05a9f2f4fa19e5fad71ed990dd72f41638a1a Author: David Ahern Date: Tue Jan 10 15:22:25 2017 -0800 net: vrf: do not allow table id 0 [ Upstream commit 24c63bbc18e25d5d8439422aa5fd2d66390b88eb ] Frank reported that vrf devices can be created with a table id of 0. This breaks many of the run time table id checks and should not be allowed. Detect this condition at create time and fail with EINVAL. Fixes: 193125dbd8eb ("net: Introduce VRF device driver") Reported-by: Frank Kellermann Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c177d491a9483a29fa6c58943e39a2f0a1c7b802 Author: David Ahern Date: Tue Jan 10 14:37:35 2017 -0800 net: ipv4: Fix multipath selection with vrf [ Upstream commit 7a18c5b9fb31a999afc62b0e60978aa896fc89e9 ] fib_select_path does not call fib_select_multipath if oif is set in the flow struct. For VRF use cases oif is always set, so multipath route selection is bypassed. Use the FLOWI_FLAG_SKIP_NH_OIF to skip the oif check similar to what is done in fib_table_lookup. Add saddr and proto to the flow struct for the fib lookup done by the VRF driver to better match hash computation for a flow. Fixes: 613d09b30f8b ("net: Use VRF device index for lookups on TX") Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 67b21973ecf4775a5761a9d4ecc0fc9c7994ea78 Author: Herbert Xu Date: Tue Jan 10 12:24:15 2017 -0800 gro: Disable frag0 optimization on IPv6 ext headers [ Upstream commit 57ea52a865144aedbcd619ee0081155e658b6f7d ] The GRO fast path caches the frag0 address. This address becomes invalid if frag0 is modified by pskb_may_pull or its variants. So whenever that happens we must disable the frag0 optimization. This is usually done through the combination of gro_header_hard and gro_header_slow, however, the IPv6 extension header path did the pulling directly and would continue to use the GRO fast path incorrectly. This patch fixes it by disabling the fast path when we enter the IPv6 extension header path. Fixes: 78a478d0efd9 ("gro: Inline skb_gro_header and cache frag0 virtual address") Reported-by: Slava Shwartsman Signed-off-by: Herbert Xu Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit db7119eaacf4653101723d1ff162f30f98267c23 Author: Eric Dumazet Date: Tue Jan 10 19:52:43 2017 -0800 gro: use min_t() in skb_gro_reset_offset() [ Upstream commit 7cfd5fd5a9813f1430290d20c0fead9b4582a307 ] On 32bit arches, (skb->end - skb->data) is not 'unsigned int', so we shall use min_t() instead of min() to avoid a compiler error. Fixes: 1272ce87fa01 ("gro: Enter slow-path if there is no tailroom") Reported-by: kernel test robot Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5169043e972246aeeadb1c6a0b0298548616fe56 Author: Herbert Xu Date: Tue Jan 10 12:24:01 2017 -0800 gro: Enter slow-path if there is no tailroom [ Upstream commit 1272ce87fa017ca4cf32920764d879656b7a005a ] The GRO path has a fast-path where we avoid calling pskb_may_pull and pskb_expand by directly accessing frag0. However, this should only be done if we have enough tailroom in the skb as otherwise we'll have to expand it later anyway. This patch adds the check by capping frag0_len with the skb tailroom. Fixes: cb18978cbf45 ("gro: Open-code final pskb_may_pull") Reported-by: Slava Shwartsman Signed-off-by: Herbert Xu Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0d3b9c2746d34a701f21c143c8f09a0887f5e203 Author: hayeswang Date: Tue Jan 10 17:04:07 2017 +0800 r8152: fix rx issue for runtime suspend [ Upstream commit 75dc692eda114cb234a46cb11893a9c3ea520934 ] Pause the rx and make sure the rx fifo is empty when the autosuspend occurs. If the rx data comes when the driver is canceling the rx urb, the host controller would stop getting the data from the device and continue it after next rx urb is submitted. That is, one continuing data is split into two different urb buffers. That let the driver take the data as a rx descriptor, and unexpected behavior happens. Signed-off-by: Hayes Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c31a3c79928bee12a42f997c2f597d9fd68b1170 Author: hayeswang Date: Tue Jan 10 17:04:06 2017 +0800 r8152: split rtl8152_suspend function [ Upstream commit 8fb280616878b81c0790a0c33acbeec59c5711f4 ] Split rtl8152_suspend() into rtl8152_system_suspend() and rtl8152_rumtime_suspend(). Signed-off-by: Hayes Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 807cac887d958250874bde823bae90ddcd35cefb Author: Alexander Duyck Date: Mon Jan 2 13:32:54 2017 -0800 ipv4: Do not allow MAIN to be alias for new LOCAL w/ custom rules [ Upstream commit 5350d54f6cd12eaff623e890744c79b700bd3f17 ] In the case of custom rules being present we need to handle the case of the LOCAL table being intialized after the new rule has been added. To address that I am adding a new check so that we can make certain we don't use an alias of MAIN for LOCAL when allocating a new table. Fixes: 0ddcf43d5d4a ("ipv4: FIB Local/MAIN table collapse") Reported-by: Oliver Brunel Signed-off-by: Alexander Duyck Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0d431f94c1815aee201238c1b0cb5e337241abbe Author: Michal Tesar Date: Mon Jan 2 14:38:36 2017 +0100 igmp: Make igmp group member RFC 3376 compliant [ Upstream commit 7ababb782690e03b78657e27bd051e20163af2d6 ] 5.2. Action on Reception of a Query When a system receives a Query, it does not respond immediately. Instead, it delays its response by a random amount of time, bounded by the Max Resp Time value derived from the Max Resp Code in the received Query message. A system may receive a variety of Queries on different interfaces and of different kinds (e.g., General Queries, Group-Specific Queries, and Group-and-Source-Specific Queries), each of which may require its own delayed response. Before scheduling a response to a Query, the system must first consider previously scheduled pending responses and in many cases schedule a combined response. Therefore, the system must be able to maintain the following state: o A timer per interface for scheduling responses to General Queries. o A per-group and interface timer for scheduling responses to Group- Specific and Group-and-Source-Specific Queries. o A per-group and interface list of sources to be reported in the response to a Group-and-Source-Specific Query. When a new Query with the Router-Alert option arrives on an interface, provided the system has state to report, a delay for a response is randomly selected in the range (0, [Max Resp Time]) where Max Resp Time is derived from Max Resp Code in the received Query message. The following rules are then used to determine if a Report needs to be scheduled and the type of Report to schedule. The rules are considered in order and only the first matching rule is applied. 1. If there is a pending response to a previous General Query scheduled sooner than the selected delay, no additional response needs to be scheduled. 2. If the received Query is a General Query, the interface timer is used to schedule a response to the General Query after the selected delay. Any previously pending response to a General Query is canceled. --8<-- Currently the timer is rearmed with new random expiration time for every incoming query regardless of possibly already pending report. Which is not aligned with the above RFE. It also might happen that higher rate of incoming queries can postpone the report after the expiration time of the first query causing group membership loss. Now the per interface general query timer is rearmed only when there is no pending report already scheduled on that interface or the newly selected expiration time is before the already pending scheduled report. Signed-off-by: Michal Tesar Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 14e8d568f14fff5adc899f6ba867bcc9e255a5a9 Author: Reiter Wolfgang Date: Tue Jan 3 01:39:10 2017 +0100 drop_monitor: consider inserted data in genlmsg_end [ Upstream commit 3b48ab2248e61408910e792fe84d6ec466084c1a ] Final nlmsg_len field update must reflect inserted net_dm_drop_point data. This patch depends on previous patch: "drop_monitor: add missing call to genlmsg_end" Signed-off-by: Reiter Wolfgang Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 81e7916476caa0c68c9442adeef90fe41cf0493b Author: Reiter Wolfgang Date: Sat Dec 31 21:11:57 2016 +0100 drop_monitor: add missing call to genlmsg_end [ Upstream commit 4200462d88f47f3759bdf4705f87e207b0f5b2e4 ] Update nlmsg_len field with genlmsg_end to enable userspace processing using nlmsg_next helper. Also adds error handling. Signed-off-by: Reiter Wolfgang Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1ff0308f33ce35e9b347d4ce0bdb04fbb6cc6645 Author: Eli Cohen Date: Wed Dec 28 14:58:34 2016 +0200 net/mlx5: Avoid shadowing numa_node [ Upstream commit d151d73dcc99de87c63bdefebcc4cb69de1cdc40 ] Avoid using a local variable named numa_node to avoid shadowing a public one. Fixes: db058a186f98 ('net/mlx5_core: Set irq affinity hints') Signed-off-by: Eli Cohen Signed-off-by: Saeed Mahameed Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 18d971f84c849fff0c51b95b6661b1fd836d8711 Author: Noa Osherovich Date: Wed Dec 28 14:58:32 2016 +0200 net/mlx5: Check FW limitations on log_max_qp before setting it [ Upstream commit 883371c453b937f9eb581fb4915210865982736f ] When setting HCA capabilities, set log_max_qp to be the minimum between the selected profile's value and the HCA limitation. Fixes: 938fe83c8dcb ('net/mlx5_core: New device capabilities...') Signed-off-by: Noa Osherovich Signed-off-by: Saeed Mahameed Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3f2847608cb9fc710bc43a9715334d3f32a808c3 Author: Florian Fainelli Date: Tue Dec 27 18:23:06 2016 -0800 net: stmmac: Fix race between stmmac_drv_probe and stmmac_open [ Upstream commit 5701659004d68085182d2fd4199c79172165fa65 ] There is currently a small window during which the network device registered by stmmac can be made visible, yet all resources, including and clock and MDIO bus have not had a chance to be set up, this can lead to the following error to occur: [ 473.919358] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized): stmmac_dvr_probe: warning: cannot get CSR clock [ 473.919382] stmmaceth 0000:01:00.0: no reset control found [ 473.919412] stmmac - user ID: 0x10, Synopsys ID: 0x42 [ 473.919429] stmmaceth 0000:01:00.0: DMA HW capability register supported [ 473.919436] stmmaceth 0000:01:00.0: RX Checksum Offload Engine supported [ 473.919443] stmmaceth 0000:01:00.0: TX Checksum insertion supported [ 473.919451] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized): Enable RX Mitigation via HW Watchdog Timer [ 473.921395] libphy: PHY stmmac-1:00 not found [ 473.921417] stmmaceth 0000:01:00.0 eth0: Could not attach to PHY [ 473.921427] stmmaceth 0000:01:00.0 eth0: stmmac_open: Cannot attach to PHY (error: -19) [ 473.959710] libphy: stmmac: probed [ 473.959724] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 0 IRQ POLL (stmmac-1:00) active [ 473.959728] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 1 IRQ POLL (stmmac-1:01) [ 473.959731] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 2 IRQ POLL (stmmac-1:02) [ 473.959734] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 3 IRQ POLL (stmmac-1:03) Fix this by making sure that register_netdev() is the last thing being done, which guarantees that the clock and the MDIO bus are available. Fixes: 4bfcbd7abce2 ("stmmac: Move the mdio_register/_unregister in probe/remove") Reported-by: Kweh, Hock Leong Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 67bce5821c9ac8ea52d83061434b029f7a00d93e Author: Daniel Borkmann Date: Wed Dec 21 18:04:11 2016 +0100 net, sched: fix soft lockup in tc_classify [ Upstream commit 628185cfddf1dfb701c4efe2cfd72cf5b09f5702 ] Shahar reported a soft lockup in tc_classify(), where we run into an endless loop when walking the classifier chain due to tp->next == tp which is a state we should never run into. The issue only seems to trigger under load in the tc control path. What happens is that in tc_ctl_tfilter(), thread A allocates a new tp, initializes it, sets tp_created to 1, and calls into tp->ops->change() with it. In that classifier callback we had to unlock/lock the rtnl mutex and returned with -EAGAIN. One reason why we need to drop there is, for example, that we need to request an action module to be loaded. This happens via tcf_exts_validate() -> tcf_action_init/_1() meaning after we loaded and found the requested action, we need to redo the whole request so we don't race against others. While we had to unlock rtnl in that time, thread B's request was processed next on that CPU. Thread B added a new tp instance successfully to the classifier chain. When thread A returned grabbing the rtnl mutex again, propagating -EAGAIN and destroying its tp instance which never got linked, we goto replay and redo A's request. This time when walking the classifier chain in tc_ctl_tfilter() for checking for existing tp instances we had a priority match and found the tp instance that was created and linked by thread B. Now calling again into tp->ops->change() with that tp was successful and returned without error. tp_created was never cleared in the second round, thus kernel thinks that we need to link it into the classifier chain (once again). tp and *back point to the same object due to the match we had earlier on. Thus for thread B's already public tp, we reset tp->next to tp itself and link it into the chain, which eventually causes the mentioned endless loop in tc_classify() once a packet hits the data path. Fix is to clear tp_created at the beginning of each request, also when we replay it. On the paths that can cause -EAGAIN we already destroy the original tp instance we had and on replay we really need to start from scratch. It seems that this issue was first introduced in commit 12186be7d2e1 ("net_cls: fix unconfigured struct tcf_proto keeps chaining and avoid kernel panic when we use cls_cgroup"). Fixes: 12186be7d2e1 ("net_cls: fix unconfigured struct tcf_proto keeps chaining and avoid kernel panic when we use cls_cgroup") Reported-by: Shahar Klein Signed-off-by: Daniel Borkmann Cc: Cong Wang Acked-by: Eric Dumazet Tested-by: Shahar Klein Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 58d0d7a45ef8ae3ebc78314d2bb0bd0203c83769 Author: Dave Jones Date: Thu Dec 22 11:16:22 2016 -0500 ipv6: handle -EFAULT from skb_copy_bits [ Upstream commit a98f91758995cb59611e61318dddd8a6956b52c3 ] By setting certain socket options on ipv6 raw sockets, we can confuse the length calculation in rawv6_push_pending_frames triggering a BUG_ON. RIP: 0010:[] [] rawv6_sendmsg+0xc30/0xc40 RSP: 0018:ffff881f6c4a7c18 EFLAGS: 00010282 RAX: 00000000fffffff2 RBX: ffff881f6c681680 RCX: 0000000000000002 RDX: ffff881f6c4a7cf8 RSI: 0000000000000030 RDI: ffff881fed0f6a00 RBP: ffff881f6c4a7da8 R08: 0000000000000000 R09: 0000000000000009 R10: ffff881fed0f6a00 R11: 0000000000000009 R12: 0000000000000030 R13: ffff881fed0f6a00 R14: ffff881fee39ba00 R15: ffff881fefa93a80 Call Trace: [] ? unmap_page_range+0x693/0x830 [] inet_sendmsg+0x67/0xa0 [] sock_sendmsg+0x38/0x50 [] SYSC_sendto+0xef/0x170 [] SyS_sendto+0xe/0x10 [] do_syscall_64+0x50/0xa0 [] entry_SYSCALL64_slow_path+0x25/0x25 Handle by jumping to the failure path if skb_copy_bits gets an EFAULT. Reproducer: #include #include #include #include #include #include #include #define LEN 504 int main(int argc, char* argv[]) { int fd; int zero = 0; char buf[LEN]; memset(buf, 0, LEN); fd = socket(AF_INET6, SOCK_RAW, 7); setsockopt(fd, SOL_IPV6, IPV6_CHECKSUM, &zero, 4); setsockopt(fd, SOL_IPV6, IPV6_DSTOPTS, &buf, LEN); sendto(fd, buf, 1, 0, (struct sockaddr *) buf, 110); } Signed-off-by: Dave Jones Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6ac0b3810cdc518decf2609577af1b3ae8becefe Author: David Ahern Date: Wed Dec 14 14:31:11 2016 -0800 net: vrf: Drop conntrack data after pass through VRF device on Tx [ Upstream commit eb63ecc1706b3e094d0f57438b6c2067cfc299f2 ] Locally originated traffic in a VRF fails in the presence of a POSTROUTING rule. For example, $ iptables -t nat -A POSTROUTING -s 11.1.1.0/24 -j MASQUERADE $ ping -I red -c1 11.1.1.3 ping: Warning: source address might be selected on device other than red. PING 11.1.1.3 (11.1.1.3) from 11.1.1.2 red: 56(84) bytes of data. ping: sendmsg: Operation not permitted Worse, the above causes random corruption resulting in a panic in random places (I have not seen a consistent backtrace). Call nf_reset to drop the conntrack info following the pass through the VRF device. The nf_reset is needed on Tx but not Rx because of the order in which NF_HOOK's are hit: on Rx the VRF device is after the real ingress device and on Tx it is is before the real egress device. Connection tracking should be tied to the real egress device and not the VRF device. Fixes: 8f58336d3f78a ("net: Add ethernet header for pass through VRF device") Fixes: 35402e3136634 ("net: Add IPv6 support to VRF device") Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1e5298d4c82be7ff1bc29e14298cb2366a28bc9d Author: Dan Carpenter Date: Wed Dec 7 14:22:03 2016 +0300 ser_gigaset: return -ENOMEM on error instead of success [ Upstream commit 93a97c50cbf1c007caf12db5cc23e0d5b9c8473c ] If we can't allocate the resources in gigaset_initdriver() then we should return -ENOMEM instead of zero. Fixes: 2869b23e4b95 ("[PATCH] drivers/isdn/gigaset: new M101 driver (v2)") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 33c7b0f74c57d1a3c0a623ce794d7f61e097d09c Author: stephen hemminger Date: Tue Dec 6 13:43:54 2016 -0800 netvsc: reduce maximum GSO size [ Upstream commit a50af86dd49ee1851d1ccf06dd0019c05b95e297 ] Hyper-V (and Azure) support using NVGRE which requires some extra space for encapsulation headers. Because of this the largest allowed TSO packet is reduced. For older releases, hard code a fixed reduced value. For next release, there is a better solution which uses result of host offload negotiation. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman