1. 11 Aug, 2017 33 commits
    • Xin Long's avatar
      dccp: fix a memleak that dccp_ipv4 doesn't put reqsk properly · adcc8785
      Xin Long authored
      
      [ Upstream commit b7953d3c ]
      
      The patch "dccp: fix a memleak that dccp_ipv6 doesn't put reqsk
      properly" fixed reqsk refcnt leak for dccp_ipv6. The same issue
      exists on dccp_ipv4.
      
      This patch is to fix it for dccp_ipv4.
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      adcc8785
    • Xin Long's avatar
      dccp: fix a memleak that dccp_ipv6 doesn't put reqsk properly · c3278ed3
      Xin Long authored
      
      [ Upstream commit 0c2232b0 ]
      
      In dccp_v6_conn_request, after reqsk gets alloced and hashed into
      ehash table, reqsk's refcnt is set 3. one is for req->rsk_timer,
      one is for hlist, and the other one is for current using.
      
      The problem is when dccp_v6_conn_request returns and finishes using
      reqsk, it doesn't put reqsk. This will cause reqsk refcnt leaks and
      reqsk obj never gets freed.
      
      Jianlin found this issue when running dccp_memleak.c in a loop, the
      system memory would run out.
      
      dccp_memleak.c:
        int s1 = socket(PF_INET6, 6, IPPROTO_IP);
        bind(s1, &sa1, 0x20);
        listen(s1, 0x9);
        int s2 = socket(PF_INET6, 6, IPPROTO_IP);
        connect(s2, &sa1, 0x20);
        close(s1);
        close(s2);
      
      This patch is to put the reqsk before dccp_v6_conn_request returns,
      just as what tcp_conn_request does.
      Reported-by: default avatarJianlin Shi <jishi@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c3278ed3
    • Marc Gonzalez's avatar
      net: ethernet: nb8800: Handle all 4 RGMII modes identically · 91c5aa7e
      Marc Gonzalez authored
      
      [ Upstream commit 4813497b ]
      
      Before commit bf8f6952 ("Add blurb about RGMII") it was unclear
      whose responsibility it was to insert the required clock skew, and
      in hindsight, some PHY drivers got it wrong. The solution forward
      is to introduce a new property, explicitly requiring skew from the
      node to which it is attached. In the interim, this driver will handle
      all 4 RGMII modes identically (no skew).
      
      Fixes: 52dfc830 ("net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller")
      Signed-off-by: default avatarMarc Gonzalez <marc_gonzalez@sigmadesigns.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      91c5aa7e
    • Stefano Brivio's avatar
      ipv6: Don't increase IPSTATS_MIB_FRAGFAILS twice in ip6_fragment() · d1ed1f8a
      Stefano Brivio authored
      
      [ Upstream commit afce615a ]
      
      RFC 2465 defines ipv6IfStatsOutFragFails as:
      
      	"The number of IPv6 datagrams that have been discarded
      	 because they needed to be fragmented at this output
      	 interface but could not be."
      
      The existing implementation, instead, would increase the counter
      twice in case we fail to allocate room for single fragments:
      once for the fragment, once for the datagram.
      
      This didn't look intentional though. In one of the two affected
      affected failure paths, the double increase was simply a result
      of a new 'goto fail' statement, introduced to avoid a skb leak.
      The other path appears to be affected since at least 2.6.12-rc2.
      Reported-by: default avatarSabrina Dubroca <sdubroca@redhat.com>
      Fixes: 1d325d21 ("ipv6: ip6_fragment: fix headroom tests and skb leak")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1ed1f8a
    • WANG Cong's avatar
      packet: fix use-after-free in prb_retire_rx_blk_timer_expired() · 49933896
      WANG Cong authored
      
      [ Upstream commit c800aaf8 ]
      
      There are multiple reports showing we have a use-after-free in
      the timer prb_retire_rx_blk_timer_expired(), where we use struct
      tpacket_kbdq_core::pkbdq, a pg_vec, after it gets freed by
      free_pg_vec().
      
      The interesting part is it is not freed via packet_release() but
      via packet_setsockopt(), which means we are not closing the socket.
      Looking into the big and fat function packet_set_ring(), this could
      happen if we satisfy the following conditions:
      
      1. closing == 0, not on packet_release() path
      2. req->tp_block_nr == 0, we don't allocate a new pg_vec
      3. rx_ring->pg_vec is already set as V3, which means we already called
         packet_set_ring() wtih req->tp_block_nr > 0 previously
      4. req->tp_frame_nr == 0, pass sanity check
      5. po->mapped == 0, never called mmap()
      
      In this scenario we are clearing the old rx_ring->pg_vec, so we need
      to free this pg_vec, but we don't stop the timer on this path because
      of closing==0.
      
      The timer has to be stopped as long as we need to free pg_vec, therefore
      the check on closing!=0 is wrong, we should check pg_vec!=NULL instead.
      
      Thanks to liujian for testing different fixes.
      
      Reported-by: alexander.levin@verizon.com
      Reported-by: default avatarDave Jones <davej@codemonkey.org.uk>
      Reported-by: default avatarliujian (CE) <liujian56@huawei.com>
      Tested-by: default avatarliujian (CE) <liujian56@huawei.com>
      Cc: Ding Tianhong <dingtianhong@huawei.com>
      Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      49933896
    • Liping Zhang's avatar
      openvswitch: fix potential out of bound access in parse_ct · 23f787ce
      Liping Zhang authored
      
      [ Upstream commit 69ec932e ]
      
      Before the 'type' is validated, we shouldn't use it to fetch the
      ovs_ct_attr_lens's minlen and maxlen, else, out of bound access
      may happen.
      
      Fixes: 7f8a436e ("openvswitch: Add conntrack action")
      Signed-off-by: default avatarLiping Zhang <zlpnobody@gmail.com>
      Acked-by: default avatarPravin B Shelar <pshelar@ovn.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      23f787ce
    • Thomas Jarosch's avatar
      mcs7780: Fix initialization when CONFIG_VMAP_STACK is enabled · 6d1e34ee
      Thomas Jarosch authored
      
      [ Upstream commit 9476d393 ]
      
      DMA transfers are not allowed to buffers that are on the stack.
      Therefore allocate a buffer to store the result of usb_control_message().
      
      Fixes these bugreports:
      https://bugzilla.kernel.org/show_bug.cgi?id=195217
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1421387
      https://bugzilla.redhat.com/show_bug.cgi?id=1427398
      
      Shortened kernel backtrace from 4.11.9-200.fc25.x86_64:
      kernel: ------------[ cut here ]------------
      kernel: WARNING: CPU: 3 PID: 2957 at drivers/usb/core/hcd.c:1587
      kernel: transfer buffer not dma capable
      kernel: Call Trace:
      kernel: dump_stack+0x63/0x86
      kernel: __warn+0xcb/0xf0
      kernel: warn_slowpath_fmt+0x5a/0x80
      kernel: usb_hcd_map_urb_for_dma+0x37f/0x570
      kernel: ? try_to_del_timer_sync+0x53/0x80
      kernel: usb_hcd_submit_urb+0x34e/0xb90
      kernel: ? schedule_timeout+0x17e/0x300
      kernel: ? del_timer_sync+0x50/0x50
      kernel: ? __slab_free+0xa9/0x300
      kernel: usb_submit_urb+0x2f4/0x560
      kernel: ? urb_destroy+0x24/0x30
      kernel: usb_start_wait_urb+0x6e/0x170
      kernel: usb_control_msg+0xdc/0x120
      kernel: mcs_get_reg+0x36/0x40 [mcs7780]
      kernel: mcs_net_open+0xb5/0x5c0 [mcs7780]
      ...
      
      Regression goes back to 4.9, so it's a good candidate for -stable.
      Though it's the decision of the maintainer.
      
      Thanks to Dan Williams for adding the "transfer buffer not dma capable"
      warning in the first place. It instantly pointed me in the right direction.
      
      Patch has been tested with transferring data from a Polar watch.
      Signed-off-by: default avatarThomas Jarosch <thomas.jarosch@intra2net.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d1e34ee
    • WANG Cong's avatar
      rtnetlink: allocate more memory for dev_set_mac_address() · d0594690
      WANG Cong authored
      
      [ Upstream commit 153711f9 ]
      
      virtnet_set_mac_address() interprets mac address as struct
      sockaddr, but upper layer only allocates dev->addr_len
      which is ETH_ALEN + sizeof(sa_family_t) in this case.
      
      We lack a unified definition for mac address, so just fix
      the upper layer, this also allows drivers to interpret it
      to struct sockaddr freely.
      Reported-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d0594690
    • Mahesh Bandewar's avatar
      ipv4: initialize fib_trie prior to register_netdev_notifier call. · 31afa8b5
      Mahesh Bandewar authored
      
      [ Upstream commit 8799a221 ]
      
      Net stack initialization currently initializes fib-trie after the
      first call to netdevice_notifier() call. In fact fib_trie initialization
      needs to happen before first rtnl_register(). It does not cause any problem
      since there are no devices UP at this moment, but trying to bring 'lo'
      UP at initialization would make this assumption wrong and exposes the issue.
      
      Fixes following crash
      
       Call Trace:
        ? alternate_node_alloc+0x76/0xa0
        fib_table_insert+0x1b7/0x4b0
        fib_magic.isra.17+0xea/0x120
        fib_add_ifaddr+0x7b/0x190
        fib_netdev_event+0xc0/0x130
        register_netdevice_notifier+0x1c1/0x1d0
        ip_fib_init+0x72/0x85
        ip_rt_init+0x187/0x1e9
        ip_init+0xe/0x1a
        inet_init+0x171/0x26c
        ? ipv4_offload_init+0x66/0x66
        do_one_initcall+0x43/0x160
        kernel_init_freeable+0x191/0x219
        ? rest_init+0x80/0x80
        kernel_init+0xe/0x150
        ret_from_fork+0x22/0x30
       Code: f6 46 23 04 74 86 4c 89 f7 e8 ae 45 01 00 49 89 c7 4d 85 ff 0f 85 7b ff ff ff 31 db eb 08 4c 89 ff e8 16 47 01 00 48 8b 44 24 38 <45> 8b 6e 14 4d 63 76 74 48 89 04 24 0f 1f 44 00 00 48 83 c4 08
       RIP: kmem_cache_alloc+0xcf/0x1c0 RSP: ffff9b1500017c28
       CR2: 0000000000000014
      
      Fixes: 7b1a74fd ("[NETNS]: Refactor fib initialization so it can handle multiple namespaces.")
      Fixes: 7f9b8052 ("[IPV4]: fib hash|trie initialization")
      Signed-off-by: default avatarMahesh Bandewar <maheshb@google.com>
      Acked-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      31afa8b5
    • Sabrina Dubroca's avatar
      ipv6: avoid overflow of offset in ip6_find_1stfragopt · f09db755
      Sabrina Dubroca authored
      
      [ Upstream commit 6399f1fa ]
      
      In some cases, offset can overflow and can cause an infinite loop in
      ip6_find_1stfragopt(). Make it unsigned int to prevent the overflow, and
      cap it at IPV6_MAXPLEN, since packets larger than that should be invalid.
      
      This problem has been here since before the beginning of git history.
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f09db755
    • David S. Miller's avatar
      net: Zero terminate ifr_name in dev_ifname(). · e9b2f461
      David S. Miller authored
      
      [ Upstream commit 63679112 ]
      
      The ifr.ifr_name is passed around and assumed to be NULL terminated.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e9b2f461
    • Alexander Potapenko's avatar
      ipv4: ipv6: initialize treq->txhash in cookie_v[46]_check() · c10e874b
      Alexander Potapenko authored
      
      [ Upstream commit 18bcf290 ]
      
      KMSAN reported use of uninitialized memory in skb_set_hash_from_sk(),
      which originated from the TCP request socket created in
      cookie_v6_check():
      
       ==================================================================
       BUG: KMSAN: use of uninitialized memory in tcp_transmit_skb+0xf77/0x3ec0
       CPU: 1 PID: 2949 Comm: syz-execprog Not tainted 4.11.0-rc5+ #2931
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
       TCP: request_sock_TCPv6: Possible SYN flooding on port 20028. Sending cookies.  Check SNMP counters.
       Call Trace:
        <IRQ>
        __dump_stack lib/dump_stack.c:16
        dump_stack+0x172/0x1c0 lib/dump_stack.c:52
        kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:927
        __msan_warning_32+0x61/0xb0 mm/kmsan/kmsan_instr.c:469
        skb_set_hash_from_sk ./include/net/sock.h:2011
        tcp_transmit_skb+0xf77/0x3ec0 net/ipv4/tcp_output.c:983
        tcp_send_ack+0x75b/0x830 net/ipv4/tcp_output.c:3493
        tcp_delack_timer_handler+0x9a6/0xb90 net/ipv4/tcp_timer.c:284
        tcp_delack_timer+0x1b0/0x310 net/ipv4/tcp_timer.c:309
        call_timer_fn+0x240/0x520 kernel/time/timer.c:1268
        expire_timers kernel/time/timer.c:1307
        __run_timers+0xc13/0xf10 kernel/time/timer.c:1601
        run_timer_softirq+0x36/0xa0 kernel/time/timer.c:1614
        __do_softirq+0x485/0x942 kernel/softirq.c:284
        invoke_softirq kernel/softirq.c:364
        irq_exit+0x1fa/0x230 kernel/softirq.c:405
        exiting_irq+0xe/0x10 ./arch/x86/include/asm/apic.h:657
        smp_apic_timer_interrupt+0x5a/0x80 arch/x86/kernel/apic/apic.c:966
        apic_timer_interrupt+0x86/0x90 arch/x86/entry/entry_64.S:489
       RIP: 0010:native_restore_fl ./arch/x86/include/asm/irqflags.h:36
       RIP: 0010:arch_local_irq_restore ./arch/x86/include/asm/irqflags.h:77
       RIP: 0010:__msan_poison_alloca+0xed/0x120 mm/kmsan/kmsan_instr.c:440
       RSP: 0018:ffff880024917cd8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
       RAX: 0000000000000246 RBX: ffff8800224c0000 RCX: 0000000000000005
       RDX: 0000000000000004 RSI: ffff880000000000 RDI: ffffea0000b6d770
       RBP: ffff880024917d58 R08: 0000000000000dd8 R09: 0000000000000004
       R10: 0000160000000000 R11: 0000000000000000 R12: ffffffff85abf810
       R13: ffff880024917dd8 R14: 0000000000000010 R15: ffffffff81cabde4
        </IRQ>
        poll_select_copy_remaining+0xac/0x6b0 fs/select.c:293
        SYSC_select+0x4b4/0x4e0 fs/select.c:653
        SyS_select+0x76/0xa0 fs/select.c:634
        entry_SYSCALL_64_fastpath+0x13/0x94 arch/x86/entry/entry_64.S:204
       RIP: 0033:0x4597e7
       RSP: 002b:000000c420037ee0 EFLAGS: 00000246 ORIG_RAX: 0000000000000017
       RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004597e7
       RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
       RBP: 000000c420037ef0 R08: 000000c420037ee0 R09: 0000000000000059
       R10: 0000000000000000 R11: 0000000000000246 R12: 000000000042dc20
       R13: 00000000000000f3 R14: 0000000000000030 R15: 0000000000000003
       chained origin:
        save_stack_trace+0x37/0x40 arch/x86/kernel/stacktrace.c:59
        kmsan_save_stack_with_flags mm/kmsan/kmsan.c:302
        kmsan_save_stack mm/kmsan/kmsan.c:317
        kmsan_internal_chain_origin+0x12a/0x1f0 mm/kmsan/kmsan.c:547
        __msan_store_shadow_origin_4+0xac/0x110 mm/kmsan/kmsan_instr.c:259
        tcp_create_openreq_child+0x709/0x1ae0 net/ipv4/tcp_minisocks.c:472
        tcp_v6_syn_recv_sock+0x7eb/0x2a30 net/ipv6/tcp_ipv6.c:1103
        tcp_get_cookie_sock+0x136/0x5f0 net/ipv4/syncookies.c:212
        cookie_v6_check+0x17a9/0x1b50 net/ipv6/syncookies.c:245
        tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:989
        tcp_v6_do_rcv+0xdd8/0x1c60 net/ipv6/tcp_ipv6.c:1298
        tcp_v6_rcv+0x41a3/0x4f00 net/ipv6/tcp_ipv6.c:1487
        ip6_input_finish+0x82f/0x1ee0 net/ipv6/ip6_input.c:279
        NF_HOOK ./include/linux/netfilter.h:257
        ip6_input+0x239/0x290 net/ipv6/ip6_input.c:322
        dst_input ./include/net/dst.h:492
        ip6_rcv_finish net/ipv6/ip6_input.c:69
        NF_HOOK ./include/linux/netfilter.h:257
        ipv6_rcv+0x1dbd/0x22e0 net/ipv6/ip6_input.c:203
        __netif_receive_skb_core+0x2f6f/0x3a20 net/core/dev.c:4208
        __netif_receive_skb net/core/dev.c:4246
        process_backlog+0x667/0xba0 net/core/dev.c:4866
        napi_poll net/core/dev.c:5268
        net_rx_action+0xc95/0x1590 net/core/dev.c:5333
        __do_softirq+0x485/0x942 kernel/softirq.c:284
       origin:
        save_stack_trace+0x37/0x40 arch/x86/kernel/stacktrace.c:59
        kmsan_save_stack_with_flags mm/kmsan/kmsan.c:302
        kmsan_internal_poison_shadow+0xb1/0x1a0 mm/kmsan/kmsan.c:198
        kmsan_kmalloc+0x7f/0xe0 mm/kmsan/kmsan.c:337
        kmem_cache_alloc+0x1c2/0x1e0 mm/slub.c:2766
        reqsk_alloc ./include/net/request_sock.h:87
        inet_reqsk_alloc+0xa4/0x5b0 net/ipv4/tcp_input.c:6200
        cookie_v6_check+0x4f4/0x1b50 net/ipv6/syncookies.c:169
        tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:989
        tcp_v6_do_rcv+0xdd8/0x1c60 net/ipv6/tcp_ipv6.c:1298
        tcp_v6_rcv+0x41a3/0x4f00 net/ipv6/tcp_ipv6.c:1487
        ip6_input_finish+0x82f/0x1ee0 net/ipv6/ip6_input.c:279
        NF_HOOK ./include/linux/netfilter.h:257
        ip6_input+0x239/0x290 net/ipv6/ip6_input.c:322
        dst_input ./include/net/dst.h:492
        ip6_rcv_finish net/ipv6/ip6_input.c:69
        NF_HOOK ./include/linux/netfilter.h:257
        ipv6_rcv+0x1dbd/0x22e0 net/ipv6/ip6_input.c:203
        __netif_receive_skb_core+0x2f6f/0x3a20 net/core/dev.c:4208
        __netif_receive_skb net/core/dev.c:4246
        process_backlog+0x667/0xba0 net/core/dev.c:4866
        napi_poll net/core/dev.c:5268
        net_rx_action+0xc95/0x1590 net/core/dev.c:5333
        __do_softirq+0x485/0x942 kernel/softirq.c:284
       ==================================================================
      
      Similar error is reported for cookie_v4_check().
      
      Fixes: 58d607d3 ("tcp: provide skb->hash to synack packets")
      Signed-off-by: default avatarAlexander Potapenko <glider@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c10e874b
    • Steven Toth's avatar
      saa7164: fix double fetch PCIe access condition · deae9956
      Steven Toth authored
      commit 6fb05e0d upstream.
      
      Avoid a double fetch by reusing the values from the prior transfer.
      
      Originally reported via https://bugzilla.kernel.org/show_bug.cgi?id=195559
      
      Thanks to Pengfei Wang <wpengfeinudt@gmail.com> for reporting.
      Signed-off-by: default avatarSteven Toth <stoth@kernellabs.com>
      Reported-by: default avatarPengfei Wang <wpengfeinudt@gmail.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Cc: Eduardo Valentin <eduval@amazon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      deae9956
    • Greg Kroah-Hartman's avatar
      drm: rcar-du: fix backport bug · e0f39019
      Greg Kroah-Hartman authored
      In the backport of commit 4f7b0d26 ("drm: rcar-du: Simplify and fix
      probe error handling"), which is commit 8255d263 in this tree, the
      error handling path was incorrect.  This patch fixes it up.
      Reported-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Cc: thongsyho <thong.ho.px@rvc.renesas.com>
      Cc: Nhan Nguyen <nhan.nguyen.yb@renesas.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e0f39019
    • Jin Qian's avatar
      f2fs: sanity check checkpoint segno and blkoff · 76517ed2
      Jin Qian authored
      commit 15d3042a upstream.
      
      Make sure segno and blkoff read from raw image are valid.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJin Qian <jinqian@google.com>
      [Jaegeuk Kim: adjust minor coding style]
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      [AmitP: Found in Android Security bulletin for Aug'17, fixes CVE-2017-10663]
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      76517ed2
    • Sean Young's avatar
      media: lirc: LIRC_GET_REC_RESOLUTION should return microseconds · c7c6f63d
      Sean Young authored
      commit 9f5039ba upstream.
      
      Since commit e8f48188 ("[media] lirc: advertise
      LIRC_CAN_GET_REC_RESOLUTION and improve") lircd uses the ioctl
      LIRC_GET_REC_RESOLUTION to determine the shortest pulse or space that
      the hardware can detect. This breaks decoding in lirc because lircd
      expects the answer in microseconds, but nanoseconds is returned.
      Reported-by: default avatarDerek <user.vdr@gmail.com>
      Tested-by: default avatarDerek <user.vdr@gmail.com>
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      c7c6f63d
    • Mel Gorman's avatar
      mm, mprotect: flush TLB if potentially racing with a parallel reclaim leaving stale TLB entries · f1181047
      Mel Gorman authored
      commit 3ea27719 upstream.
      
      Stable note for 4.4: The upstream patch patches madvise(MADV_FREE) but 4.4
      	does not have support for that feature. The changelog is left
      	as-is but the hunk related to madvise is omitted from the backport.
      
      Nadav Amit identified a theoritical race between page reclaim and
      mprotect due to TLB flushes being batched outside of the PTL being held.
      
      He described the race as follows:
      
              CPU0                            CPU1
              ----                            ----
                                              user accesses memory using RW PTE
                                              [PTE now cached in TLB]
              try_to_unmap_one()
              ==> ptep_get_and_clear()
              ==> set_tlb_ubc_flush_pending()
                                              mprotect(addr, PROT_READ)
                                              ==> change_pte_range()
                                              ==> [ PTE non-present - no flush ]
      
                                              user writes using cached RW PTE
              ...
      
              try_to_unmap_flush()
      
      The same type of race exists for reads when protecting for PROT_NONE and
      also exists for operations that can leave an old TLB entry behind such
      as munmap, mremap and madvise.
      
      For some operations like mprotect, it's not necessarily a data integrity
      issue but it is a correctness issue as there is a window where an
      mprotect that limits access still allows access.  For munmap, it's
      potentially a data integrity issue although the race is massive as an
      munmap, mmap and return to userspace must all complete between the
      window when reclaim drops the PTL and flushes the TLB.  However, it's
      theoritically possible so handle this issue by flushing the mm if
      reclaim is potentially currently batching TLB flushes.
      
      Other instances where a flush is required for a present pte should be ok
      as either the page lock is held preventing parallel reclaim or a page
      reference count is elevated preventing a parallel free leading to
      corruption.  In the case of page_mkclean there isn't an obvious path
      that userspace could take advantage of without using the operations that
      are guarded by this patch.  Other users such as gup as a race with
      reclaim looks just at PTEs.  huge page variants should be ok as they
      don't race with reclaim.  mincore only looks at PTEs.  userfault also
      should be ok as if a parallel reclaim takes place, it will either fault
      the page back in or read some of the data before the flush occurs
      triggering a fault.
      
      Note that a variant of this patch was acked by Andy Lutomirski but this
      was for the x86 parts on top of his PCID work which didn't make the 4.13
      merge window as expected.  His ack is dropped from this version and
      there will be a follow-on patch on top of PCID that will include his
      ack.
      
      [akpm@linux-foundation.org: tweak comments]
      [akpm@linux-foundation.org: fix spello]
      Link: http://lkml.kernel.org/r/20170717155523.emckq2esjro6hf3z@suse.deReported-by: default avatarNadav Amit <nadav.amit@gmail.com>
      Signed-off-by: default avatarMel Gorman <mgorman@suse.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f1181047
    • Nicholas Bellinger's avatar
      iser-target: Avoid isert_conn->cm_id dereference in isert_login_recv_done · 9745cbec
      Nicholas Bellinger authored
      commit fce50a2f upstream.
      
      This patch fixes a NULL pointer dereference in isert_login_recv_done()
      of isert_conn->cm_id due to isert_cma_handler() -> isert_connect_error()
      resetting isert_conn->cm_id = NULL during a failed login attempt.
      
      As per Sagi, we will always see the completion of all recv wrs posted
      on the qp (given that we assigned a ->done handler), this is a FLUSH
      error completion, we just don't get to verify that because we deref
      NULL before.
      
      The issue here, was the assumption that dereferencing the connection
      cm_id is always safe, which is not true since:
      
          commit 4a579da2
          Author: Sagi Grimberg <sagig@mellanox.com>
          Date:   Sun Mar 29 15:52:04 2015 +0300
      
               iser-target: Fix possible deadlock in RDMA_CM connection error
      
      As I see it, we have a direct reference to the isert_device from
      isert_conn which is the one-liner fix that we actually need like
      we do in isert_rdma_read_done() and isert_rdma_write_done().
      Reported-by: default avatarAndrea Righi <righi.andrea@gmail.com>
      Tested-by: default avatarAndrea Righi <righi.andrea@gmail.com>
      Reviewed-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9745cbec
    • Nicholas Bellinger's avatar
      iscsi-target: Fix delayed logout processing greater than SECONDS_FOR_LOGOUT_COMP · ae059833
      Nicholas Bellinger authored
      commit 105fa2f4 upstream.
      
      This patch fixes a BUG() in iscsit_close_session() that could be
      triggered when iscsit_logout_post_handler() execution from within
      tx thread context was not run for more than SECONDS_FOR_LOGOUT_COMP
      (15 seconds), and the TCP connection didn't already close before
      then forcing tx thread context to automatically exit.
      
      This would manifest itself during explicit logout as:
      
      [33206.974254] 1 connection(s) still exist for iSCSI session to iqn.1993-08.org.debian:01:3f5523242179
      [33206.980184] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 2100.772 msecs
      [33209.078643] ------------[ cut here ]------------
      [33209.078646] kernel BUG at drivers/target/iscsi/iscsi_target.c:4346!
      
      Normally when explicit logout attempt fails, the tx thread context
      exits and iscsit_close_connection() from rx thread context does the
      extra cleanup once it detects conn->conn_logout_remove has not been
      cleared by the logout type specific post handlers.
      
      To address this special case, if the logout post handler in tx thread
      context detects conn->tx_thread_active has already been cleared, simply
      return and exit in order for existing iscsit_close_connection()
      logic from rx thread context do failed logout cleanup.
      Reported-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Tested-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Mike Christie <mchristi@redhat.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Tested-by: default avatarGary Guo <ghg@datera.io>
      Tested-by: default avatarChu Yuan Lin <cyl@datera.io>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      ae059833
    • Nicholas Bellinger's avatar
      iscsi-target: Fix initial login PDU asynchronous socket close OOPs · bf54cf1e
      Nicholas Bellinger authored
      commit 25cdda95 upstream.
      
      This patch fixes a OOPs originally introduced by:
      
         commit bb048357
         Author: Nicholas Bellinger <nab@linux-iscsi.org>
         Date:   Thu Sep 5 14:54:04 2013 -0700
      
         iscsi-target: Add sk->sk_state_change to cleanup after TCP failure
      
      which would trigger a NULL pointer dereference when a TCP connection
      was closed asynchronously via iscsi_target_sk_state_change(), but only
      when the initial PDU processing in iscsi_target_do_login() from iscsi_np
      process context was blocked waiting for backend I/O to complete.
      
      To address this issue, this patch makes the following changes.
      
      First, it introduces some common helper functions used for checking
      socket closing state, checking login_flags, and atomically checking
      socket closing state + setting login_flags.
      
      Second, it introduces a LOGIN_FLAGS_INITIAL_PDU bit to know when a TCP
      connection has dropped via iscsi_target_sk_state_change(), but the
      initial PDU processing within iscsi_target_do_login() in iscsi_np
      context is still running.  For this case, it sets LOGIN_FLAGS_CLOSED,
      but doesn't invoke schedule_delayed_work().
      
      The original NULL pointer dereference case reported by MNC is now handled
      by iscsi_target_do_login() doing a iscsi_target_sk_check_close() before
      transitioning to FFP to determine when the socket has already closed,
      or iscsi_target_start_negotiation() if the login needs to exchange
      more PDUs (eg: iscsi_target_do_login returned 0) but the socket has
      closed.  For both of these cases, the cleanup up of remaining connection
      resources will occur in iscsi_target_start_negotiation() from iscsi_np
      process context once the failure is detected.
      
      Finally, to handle to case where iscsi_target_sk_state_change() is
      called after the initial PDU procesing is complete, it now invokes
      conn->login_work -> iscsi_target_do_login_rx() to perform cleanup once
      existing iscsi_target_sk_check_close() checks detect connection failure.
      For this case, the cleanup of remaining connection resources will occur
      in iscsi_target_do_login_rx() from delayed workqueue process context
      once the failure is detected.
      Reported-by: default avatarMike Christie <mchristi@redhat.com>
      Reviewed-by: default avatarMike Christie <mchristi@redhat.com>
      Tested-by: default avatarMike Christie <mchristi@redhat.com>
      Cc: Mike Christie <mchristi@redhat.com>
      Reported-by: default avatarHannes Reinecke <hare@suse.com>
      Cc: Hannes Reinecke <hare@suse.com>
      Cc: Sagi Grimberg <sagi@grimberg.me>
      Cc: Varun Prakash <varun@chelsio.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      bf54cf1e
    • Nicholas Bellinger's avatar
      iscsi-target: Fix early sk_data_ready LOGIN_FLAGS_READY race · cf4ab9d5
      Nicholas Bellinger authored
      commit 8f0dfb3d upstream.
      
      There is a iscsi-target/tcp login race in LOGIN_FLAGS_READY
      state assignment that can result in frequent errors during
      iscsi discovery:
      
            "iSCSI Login negotiation failed."
      
      To address this bug, move the initial LOGIN_FLAGS_READY
      assignment ahead of iscsi_target_do_login() when handling
      the initial iscsi_target_start_negotiation() request PDU
      during connection login.
      
      As iscsi_target_do_login_rx() work_struct callback is
      clearing LOGIN_FLAGS_READ_ACTIVE after subsequent calls
      to iscsi_target_do_login(), the early sk_data_ready
      ahead of the first iscsi_target_do_login() expects
      LOGIN_FLAGS_READY to also be set for the initial
      login request PDU.
      
      As reported by Maged, this was first obsered using an
      MSFT initiator running across multiple VMWare host
      virtual machines with iscsi-target/tcp.
      Reported-by: default avatarMaged Mokhtar <mmokhtar@binarykinetics.com>
      Tested-by: default avatarMaged Mokhtar <mmokhtar@binarykinetics.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      cf4ab9d5
    • Jiang Yi's avatar
      iscsi-target: Always wait for kthread_should_stop() before kthread exit · 119903dc
      Jiang Yi authored
      commit 5e0cf5e6 upstream.
      
      There are three timing problems in the kthread usages of iscsi_target_mod:
      
       - np_thread of struct iscsi_np
       - rx_thread and tx_thread of struct iscsi_conn
      
      In iscsit_close_connection(), it calls
      
       send_sig(SIGINT, conn->tx_thread, 1);
       kthread_stop(conn->tx_thread);
      
      In conn->tx_thread, which is iscsi_target_tx_thread(), when it receive
      SIGINT the kthread will exit without checking the return value of
      kthread_should_stop().
      
      So if iscsi_target_tx_thread() exit right between send_sig(SIGINT...)
      and kthread_stop(...), the kthread_stop() will try to stop an already
      stopped kthread.
      
      This is invalid according to the documentation of kthread_stop().
      
      (Fix -ECONNRESET logout handling in iscsi_target_tx_thread and
       early iscsi_target_rx_thread failure case - nab)
      Signed-off-by: default avatarJiang Yi <jiangyilism@gmail.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      119903dc
    • Nicholas Bellinger's avatar
      target: Avoid mappedlun symlink creation during lun shutdown · 2bf7791c
      Nicholas Bellinger authored
      commit 49cb77e2 upstream.
      
      This patch closes a race between se_lun deletion during configfs
      unlink in target_fabric_port_unlink() -> core_dev_del_lun()
      -> core_tpg_remove_lun(), when transport_clear_lun_ref() blocks
      waiting for percpu_ref RCU grace period to finish, but a new
      NodeACL mappedlun is added before the RCU grace period has
      completed.
      
      This can happen in target_fabric_mappedlun_link() because it
      only checks for se_lun->lun_se_dev, which is not cleared until
      after transport_clear_lun_ref() percpu_ref RCU grace period
      finishes.
      
      This bug originally manifested as NULL pointer dereference
      OOPsen in target_stat_scsi_att_intr_port_show_attr_dev() on
      v4.1.y code, because it dereferences lun->lun_se_dev without
      a explicit NULL pointer check.
      
      In post v4.1 code with target-core RCU conversion, the code
      in target_stat_scsi_att_intr_port_show_attr_dev() no longer
      uses se_lun->lun_se_dev, but the same race still exists.
      
      To address the bug, go ahead and set se_lun>lun_shutdown as
      early as possible in core_tpg_remove_lun(), and ensure new
      NodeACL mappedlun creation in target_fabric_mappedlun_link()
      fails during se_lun shutdown.
      Reported-by: default avatarJames Shen <jcs@datera.io>
      Cc: James Shen <jcs@datera.io>
      Tested-by: default avatarJames Shen <jcs@datera.io>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2bf7791c
    • Prabhakar Lad's avatar
      media: platform: davinci: return -EINVAL for VPFE_CMD_S_CCDC_RAW_PARAMS ioctl · fa95dfc7
      Prabhakar Lad authored
      commit da05d52d upstream.
      
      this patch makes sure VPFE_CMD_S_CCDC_RAW_PARAMS ioctl no longer works
      for vpfe_capture driver with a minimal patch suitable for backporting.
      
      - This ioctl was never in public api and was only defined in kernel header.
      - The function set_params constantly mixes up pointers and phys_addr_t
        numbers.
      - This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
        described as an 'experimental ioctl that will change in future kernels'.
      - The code to allocate the table never gets called after we copy_from_user
        the user input over the kernel settings, and then compare them
        for inequality.
      - We then go on to use an address provided by user space as both the
        __user pointer for input and pass it through phys_to_virt to come up
        with a kernel pointer to copy the data to. This looks like a trivially
        exploitable root hole.
      
      Due to these reasons we make sure this ioctl now returns -EINVAL and backport
      this patch as far as possible.
      
      Fixes: 5f15fbb6 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture driver")
      Signed-off-by: default avatarLad, Prabhakar <prabhakar.csengg@gmail.com>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa95dfc7
    • Gregory CLEMENT's avatar
      ARM: dts: armada-38x: Fix irq type for pca955 · 3c2bf2bd
      Gregory CLEMENT authored
      commit 8d451417 upstream.
      
      As written in the datasheet the PCA955 can only handle low level irq and
      not edge irq.
      
      Without this fix the interrupt is not usable for pca955: the gpio-pca953x
      driver already set the irq type as low level which is incompatible with
      edge type, then the kernel prevents using the interrupt:
      
      "irq: type mismatch, failed to map hwirq-18 for
      /soc/internal-regs/gpio@18100!"
      
      Fixes: 928413bd ("ARM: mvebu: Add Armada 388 General Purpose
      Development Board support")
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c2bf2bd
    • Jerry Lee's avatar
      ext4: fix overflow caused by missing cast in ext4_resize_fs() · 31cd127c
      Jerry Lee authored
      commit aec51758 upstream.
      
      On a 32-bit platform, the value of n_blcoks_count may be wrong during
      the file system is resized to size larger than 2^32 blocks.  This may
      caused the superblock being corrupted with zero blocks count.
      
      Fixes: 1c6bd717Signed-off-by: default avatarJerry Lee <jerrylee@qnap.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      31cd127c
    • Jan Kara's avatar
      ext4: fix SEEK_HOLE/SEEK_DATA for blocksize < pagesize · bad9f614
      Jan Kara authored
      commit fcf5ea10 upstream.
      
      ext4_find_unwritten_pgoff() does not properly handle a situation when
      starting index is in the middle of a page and blocksize < pagesize. The
      following command shows the bug on filesystem with 1k blocksize:
      
        xfs_io -f -c "falloc 0 4k" \
                  -c "pwrite 1k 1k" \
                  -c "pwrite 3k 1k" \
                  -c "seek -a -r 0" foo
      
      In this example, neither lseek(fd, 1024, SEEK_HOLE) nor lseek(fd, 2048,
      SEEK_DATA) will return the correct result.
      
      Fix the problem by neglecting buffers in a page before starting offset.
      Reported-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bad9f614
    • Josh Poimboeuf's avatar
      mm/page_alloc: Remove kernel address exposure in free_reserved_area() · 12f60018
      Josh Poimboeuf authored
      commit adb1fe9a upstream.
      
      Linus suggested we try to remove some of the low-hanging fruit related
      to kernel address exposure in dmesg.  The only leaks I see on my local
      system are:
      
        Freeing SMP alternatives memory: 32K (ffffffff9e309000 - ffffffff9e311000)
        Freeing initrd memory: 10588K (ffffa0b736b42000 - ffffa0b737599000)
        Freeing unused kernel memory: 3592K (ffffffff9df87000 - ffffffff9e309000)
        Freeing unused kernel memory: 1352K (ffffa0b7288ae000 - ffffa0b728a00000)
        Freeing unused kernel memory: 632K (ffffa0b728d62000 - ffffa0b728e00000)
      
      Linus says:
      
        "I suspect we should just remove [the addresses in the 'Freeing'
         messages]. I'm sure they are useful in theory, but I suspect they
         were more useful back when the whole "free init memory" was
         originally done.
      
         These days, if we have a use-after-free, I suspect the init-mem
         situation is the easiest situation by far. Compared to all the dynamic
         allocations which are much more likely to show it anyway. So having
         debug output for that case is likely not all that productive."
      
      With this patch the freeing messages now look like this:
      
        Freeing SMP alternatives memory: 32K
        Freeing initrd memory: 10588K
        Freeing unused kernel memory: 3592K
        Freeing unused kernel memory: 1352K
        Freeing unused kernel memory: 632K
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/6836ff90c45b71d38e5d4405aec56fa9e5d1d4b2.1477405374.git.jpoimboe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Kees Cook <keescook@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      12f60018
    • Wanpeng Li's avatar
      KVM: async_pf: make rcu irq exit if not triggered from idle task · bbccdb1e
      Wanpeng Li authored
      commit 337c017c upstream.
      
       WARNING: CPU: 5 PID: 1242 at kernel/rcu/tree_plugin.h:323 rcu_note_context_switch+0x207/0x6b0
       CPU: 5 PID: 1242 Comm: unity-settings- Not tainted 4.13.0-rc2+ #1
       RIP: 0010:rcu_note_context_switch+0x207/0x6b0
       Call Trace:
        __schedule+0xda/0xba0
        ? kvm_async_pf_task_wait+0x1b2/0x270
        schedule+0x40/0x90
        kvm_async_pf_task_wait+0x1cc/0x270
        ? prepare_to_swait+0x22/0x70
        do_async_page_fault+0x77/0xb0
        ? do_async_page_fault+0x77/0xb0
        async_page_fault+0x28/0x30
       RIP: 0010:__d_lookup_rcu+0x90/0x1e0
      
      I encounter this when trying to stress the async page fault in L1 guest w/
      L2 guests running.
      
      Commit 9b132fbe (Add rcu user eqs exception hooks for async page
      fault) adds rcu_irq_enter/exit() to kvm_async_pf_task_wait() to exit cpu
      idle eqs when needed, to protect the code that needs use rcu.  However,
      we need to call the pair even if the function calls schedule(), as seen
      from the above backtrace.
      
      This patch fixes it by informing the RCU subsystem exit/enter the irq
      towards/away from idle for both n.halted and !n.halted.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarWanpeng Li <wanpeng.li@hotmail.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bbccdb1e
    • Banajit Goswami's avatar
      ASoC: do not close shared backend dailink · 7de8d0c0
      Banajit Goswami authored
      commit b1cd2e34 upstream.
      
      Multiple frontend dailinks may be connected to a backend
      dailink at the same time. When one of frontend dailinks is
      closed, the associated backend dailink should not be closed
      if it is connected to other active frontend dailinks. Change
      ensures that backend dailink is closed only after all
      connected frontend dailinks are closed.
      Signed-off-by: default avatarGopikrishnaiah Anandan <agopik@codeaurora.org>
      Signed-off-by: default avatarBanajit Goswami <bgoswami@codeaurora.org>
      Signed-off-by: default avatarPatrick Lai <plai@codeaurora.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7de8d0c0
    • Sergei A. Trusov's avatar
      ALSA: hda - Fix speaker output from VAIO VPCL14M1R · 458c8be4
      Sergei A. Trusov authored
      commit 3f3c3714 upstream.
      
      Sony VAIO VPCL14M1R needs the quirk to make the speaker working properly.
      Tested-by: default avatarDmitriy <mexx400@yandex.ru>
      Signed-off-by: default avatarSergei A. Trusov <sergei.a.trusov@ya.ru>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      458c8be4
    • Tejun Heo's avatar
      workqueue: restore WQ_UNBOUND/max_active==1 to be ordered · c59eec4d
      Tejun Heo authored
      commit 5c0338c6 upstream.
      
      The combination of WQ_UNBOUND and max_active == 1 used to imply
      ordered execution.  After NUMA affinity 4c16bd32 ("workqueue:
      implement NUMA affinity for unbound workqueues"), this is no longer
      true due to per-node worker pools.
      
      While the right way to create an ordered workqueue is
      alloc_ordered_workqueue(), the documentation has been misleading for a
      long time and people do use WQ_UNBOUND and max_active == 1 for ordered
      workqueues which can lead to subtle bugs which are very difficult to
      trigger.
      
      It's unlikely that we'd see noticeable performance impact by enforcing
      ordering on WQ_UNBOUND / max_active == 1 workqueues.  Let's
      automatically set __WQ_ORDERED for those workqueues.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarChristoph Hellwig <hch@infradead.org>
      Reported-by: default avatarAlexei Potashnik <alexei@purestorage.com>
      Fixes: 4c16bd32 ("workqueue: implement NUMA affinity for unbound workqueues")
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c59eec4d
    • Dan Carpenter's avatar
      libata: array underflow in ata_find_dev() · 8ecd8cff
      Dan Carpenter authored
      commit 59a5e266 upstream.
      
      My static checker complains that "devno" can be negative, meaning that
      we read before the start of the loop.  I've looked at the code, and I
      think the warning is right.  This come from /proc so it's root only or
      it would be quite a quite a serious bug.  The call tree looks like this:
      
      proc_scsi_write() <- gets id and channel from simple_strtoul()
      -> scsi_add_single_device() <- calls shost->transportt->user_scan()
         -> ata_scsi_user_scan()
            -> ata_find_dev()
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ecd8cff
  2. 07 Aug, 2017 7 commits