1. 13 Apr, 2018 40 commits
    • Eric Dumazet's avatar
      net: fool proof dev_valid_name() · 0d1c057d
      Eric Dumazet authored
      
      [ Upstream commit a9d48205 ]
      
      We want to use dev_valid_name() to validate tunnel names,
      so better use strnlen(name, IFNAMSIZ) than strlen(name) to make
      sure to not upset KASAN.
      Signed-off-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>
      0d1c057d
    • Xin Long's avatar
      bonding: process the err returned by dev_set_allmulti properly in bond_enslave · 359d6e35
      Xin Long authored
      
      [ Upstream commit 9f5a90c1 ]
      
      When dev_set_promiscuity(1) succeeds but dev_set_allmulti(1) fails,
      dev_set_promiscuity(-1) should be done before going to the err path.
      Otherwise, dev->promiscuity will leak.
      
      Fixes: 7e1a1ac1 ("bonding: Check return of dev_set_promiscuity/allmulti")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      359d6e35
    • Xin Long's avatar
      bonding: move dev_mc_sync after master_upper_dev_link in bond_enslave · d6d65b4c
      Xin Long authored
      
      [ Upstream commit ae42cc62 ]
      
      Beniamino found a crash when adding vlan as slave of bond which is also
      the parent link:
      
        ip link add bond1 type bond
        ip link set bond1 up
        ip link add link bond1 vlan1 type vlan id 80
        ip link set vlan1 master bond1
      
      The call trace is as below:
      
        [<ffffffffa850842a>] queued_spin_lock_slowpath+0xb/0xf
        [<ffffffffa8515680>] _raw_spin_lock+0x20/0x30
        [<ffffffffa83f6f07>] dev_mc_sync+0x37/0x80
        [<ffffffffc08687dc>] vlan_dev_set_rx_mode+0x1c/0x30 [8021q]
        [<ffffffffa83efd2a>] __dev_set_rx_mode+0x5a/0xa0
        [<ffffffffa83f7138>] dev_mc_sync_multiple+0x78/0x80
        [<ffffffffc084127c>] bond_enslave+0x67c/0x1190 [bonding]
        [<ffffffffa8401909>] do_setlink+0x9c9/0xe50
        [<ffffffffa8403bf2>] rtnl_newlink+0x522/0x880
        [<ffffffffa8403ff7>] rtnetlink_rcv_msg+0xa7/0x260
        [<ffffffffa8424ecb>] netlink_rcv_skb+0xab/0xc0
        [<ffffffffa83fe498>] rtnetlink_rcv+0x28/0x30
        [<ffffffffa8424850>] netlink_unicast+0x170/0x210
        [<ffffffffa8424bf8>] netlink_sendmsg+0x308/0x420
        [<ffffffffa83cc396>] sock_sendmsg+0xb6/0xf0
      
      This is actually a dead lock caused by sync slave hwaddr from master when
      the master is the slave's 'slave'. This dead loop check is actually done
      by netdev_master_upper_dev_link. However, Commit 1f718f0f ("bonding:
      populate neighbour's private on enslave") moved it after dev_mc_sync.
      
      This patch is to fix it by moving dev_mc_sync after master_upper_dev_link,
      so that this loop check would be earlier than dev_mc_sync. It also moves
      if (mode == BOND_MODE_8023AD) into if (!bond_uses_primary) clause as an
      improvement.
      
      Note team driver also has this issue, I will fix it in another patch.
      
      Fixes: 1f718f0f ("bonding: populate neighbour's private on enslave")
      Reported-by: default avatarBeniamino Galvani <bgalvani@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d6d65b4c
    • Xin Long's avatar
      bonding: fix the err path for dev hwaddr sync in bond_enslave · f611a5e1
      Xin Long authored
      
      [ Upstream commit 5c78f6bf ]
      
      vlan_vids_add_by_dev is called right after dev hwaddr sync, so on
      the err path it should unsync dev hwaddr. Otherwise, the slave
      dev's hwaddr will never be unsync when this err happens.
      
      Fixes: 1ff412ad ("bonding: change the bond's vlan syncing functions with the standard ones")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Reviewed-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Acked-by: default avatarAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f611a5e1
    • Hangbin Liu's avatar
      vlan: also check phy_driver ts_info for vlan's real device · 2463af64
      Hangbin Liu authored
      
      [ Upstream commit ec1d8ccb ]
      
      Just like function ethtool_get_ts_info(), we should also consider the
      phy_driver ts_info call back. For example, driver dp83640.
      
      Fixes: 37dd9255 ("vlan: Pass ethtool get_ts_info queries to real device.")
      Acked-by: default avatarRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2463af64
    • Jason Wang's avatar
      vhost: correctly remove wait queue during poll failure · 827148d0
      Jason Wang authored
      
      [ Upstream commit dc6455a7 ]
      
      We tried to remove vq poll from wait queue, but do not check whether
      or not it was in a list before. This will lead double free. Fixing
      this by switching to use vhost_poll_stop() which zeros poll->wqh after
      removing poll from waitqueue to make sure it won't be freed twice.
      
      Cc: Darren Kenny <darren.kenny@oracle.com>
      Reported-by: syzbot+c0272972b01b872e604a@syzkaller.appspotmail.com
      Fixes: 2b8b328b ("vhost_net: handle polling errors when setting backend")
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Reviewed-by: default avatarDarren Kenny <darren.kenny@oracle.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      827148d0
    • Kai-Heng Feng's avatar
      sky2: Increase D3 delay to sky2 stops working after suspend · 10200c71
      Kai-Heng Feng authored
      
      [ Upstream commit afb13363 ]
      
      The sky2 ethernet stops working after system resume from suspend:
      [ 582.852065] sky2 0000:04:00.0: Refused to change power state, currently in D3
      
      The current 150ms delay is not enough, change it to 200ms can solve the
      issue.
      
      BugLink: https://bugs.launchpad.net/bugs/1758507
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      10200c71
    • Eric Dumazet's avatar
      sctp: sctp_sockaddr_af must check minimal addr length for AF_INET6 · 16002a42
      Eric Dumazet authored
      
      [ Upstream commit 81e98370 ]
      
      Check must happen before call to ipv6_addr_v4mapped()
      
      syzbot report was :
      
      BUG: KMSAN: uninit-value in sctp_sockaddr_af net/sctp/socket.c:359 [inline]
      BUG: KMSAN: uninit-value in sctp_do_bind+0x60f/0xdc0 net/sctp/socket.c:384
      CPU: 0 PID: 3576 Comm: syzkaller968804 Not tainted 4.16.0+ #82
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x185/0x1d0 lib/dump_stack.c:53
       kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
       __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
       sctp_sockaddr_af net/sctp/socket.c:359 [inline]
       sctp_do_bind+0x60f/0xdc0 net/sctp/socket.c:384
       sctp_bind+0x149/0x190 net/sctp/socket.c:332
       inet6_bind+0x1fd/0x1820 net/ipv6/af_inet6.c:293
       SYSC_bind+0x3f2/0x4b0 net/socket.c:1474
       SyS_bind+0x54/0x80 net/socket.c:1460
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x43fd49
      RSP: 002b:00007ffe99df3d28 EFLAGS: 00000213 ORIG_RAX: 0000000000000031
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fd49
      RDX: 0000000000000010 RSI: 0000000020000000 RDI: 0000000000000003
      RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
      R10: 00000000004002c8 R11: 0000000000000213 R12: 0000000000401670
      R13: 0000000000401700 R14: 0000000000000000 R15: 0000000000000000
      
      Local variable description: ----address@SYSC_bind
      Variable was created at:
       SYSC_bind+0x6f/0x4b0 net/socket.c:1461
       SyS_bind+0x54/0x80 net/socket.c:1460
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Vlad Yasevich <vyasevich@gmail.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16002a42
    • Eric Dumazet's avatar
      sctp: do not leak kernel memory to user space · 2cd9afc8
      Eric Dumazet authored
      
      [ Upstream commit 6780db24 ]
      
      syzbot produced a nice report [1]
      
      Issue here is that a recvmmsg() managed to leak 8 bytes of kernel memory
      to user space, because sin_zero (padding field) was not properly cleared.
      
      [1]
      BUG: KMSAN: uninit-value in copy_to_user include/linux/uaccess.h:184 [inline]
      BUG: KMSAN: uninit-value in move_addr_to_user+0x32e/0x530 net/socket.c:227
      CPU: 1 PID: 3586 Comm: syzkaller481044 Not tainted 4.16.0+ #82
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x185/0x1d0 lib/dump_stack.c:53
       kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
       kmsan_internal_check_memory+0x164/0x1d0 mm/kmsan/kmsan.c:1176
       kmsan_copy_to_user+0x69/0x160 mm/kmsan/kmsan.c:1199
       copy_to_user include/linux/uaccess.h:184 [inline]
       move_addr_to_user+0x32e/0x530 net/socket.c:227
       ___sys_recvmsg+0x4e2/0x810 net/socket.c:2211
       __sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313
       SYSC_recvmmsg+0x29b/0x3e0 net/socket.c:2394
       SyS_recvmmsg+0x76/0xa0 net/socket.c:2378
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x4401c9
      RSP: 002b:00007ffc56f73098 EFLAGS: 00000217 ORIG_RAX: 000000000000012b
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004401c9
      RDX: 0000000000000001 RSI: 0000000020003ac0 RDI: 0000000000000003
      RBP: 00000000006ca018 R08: 0000000020003bc0 R09: 0000000000000010
      R10: 0000000000000000 R11: 0000000000000217 R12: 0000000000401af0
      R13: 0000000000401b80 R14: 0000000000000000 R15: 0000000000000000
      
      Local variable description: ----addr@___sys_recvmsg
      Variable was created at:
       ___sys_recvmsg+0xd5/0x810 net/socket.c:2172
       __sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313
      
      Bytes 8-15 of 16 are uninitialized
      
      ==================================================================
      Kernel panic - not syncing: panic_on_warn set ...
      
      CPU: 1 PID: 3586 Comm: syzkaller481044 Tainted: G    B            4.16.0+ #82
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x185/0x1d0 lib/dump_stack.c:53
       panic+0x39d/0x940 kernel/panic.c:183
       kmsan_report+0x238/0x240 mm/kmsan/kmsan.c:1083
       kmsan_internal_check_memory+0x164/0x1d0 mm/kmsan/kmsan.c:1176
       kmsan_copy_to_user+0x69/0x160 mm/kmsan/kmsan.c:1199
       copy_to_user include/linux/uaccess.h:184 [inline]
       move_addr_to_user+0x32e/0x530 net/socket.c:227
       ___sys_recvmsg+0x4e2/0x810 net/socket.c:2211
       __sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313
       SYSC_recvmmsg+0x29b/0x3e0 net/socket.c:2394
       SyS_recvmmsg+0x76/0xa0 net/socket.c:2378
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc:	Vlad Yasevich <vyasevich@gmail.com>
      Cc:	Neil Horman <nhorman@tuxdriver.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2cd9afc8
    • Heiner Kallweit's avatar
      r8169: fix setting driver_data after register_netdev · 360e1e58
      Heiner Kallweit authored
      
      [ Upstream commit 19c9ea36 ]
      
      pci_set_drvdata() is called only after registering the net_device,
      therefore we could run into a NPE if one of the functions using
      driver_data is called before it's set.
      
      Fix this by calling pci_set_drvdata() before registering the
      net_device.
      
      This fix is a candidate for stable. As far as I can see the
      bug has been there in kernel version 3.2 already, therefore
      I can't provide a reference which commit is fixed by it.
      
      The fix may need small adjustments per kernel version because
      due to other changes the label which is jumped to if
      register_netdev() fails has changed over time.
      Reported-by: default avatarDavid Miller <davem@davemloft.net>
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      360e1e58
    • Eric Dumazet's avatar
      pptp: remove a buggy dst release in pptp_connect() · 765884bc
      Eric Dumazet authored
      
      [ Upstream commit bfacfb45 ]
      
      Once dst has been cached in socket via sk_setup_caps(),
      it is illegal to call ip_rt_put() (or dst_release()),
      since sk_setup_caps() did not change dst refcount.
      
      We can still dereference it since we hold socket lock.
      
      Caugth by syzbot :
      
      BUG: KASAN: use-after-free in atomic_dec_return include/asm-generic/atomic-instrumented.h:198 [inline]
      BUG: KASAN: use-after-free in dst_release+0x27/0xa0 net/core/dst.c:185
      Write of size 4 at addr ffff8801c54dc040 by task syz-executor4/20088
      
      CPU: 1 PID: 20088 Comm: syz-executor4 Not tainted 4.16.0+ #376
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x1a7/0x27d lib/dump_stack.c:53
       print_address_description+0x73/0x250 mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report+0x23c/0x360 mm/kasan/report.c:412
       check_memory_region_inline mm/kasan/kasan.c:260 [inline]
       check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
       kasan_check_write+0x14/0x20 mm/kasan/kasan.c:278
       atomic_dec_return include/asm-generic/atomic-instrumented.h:198 [inline]
       dst_release+0x27/0xa0 net/core/dst.c:185
       sk_dst_set include/net/sock.h:1812 [inline]
       sk_dst_reset include/net/sock.h:1824 [inline]
       sock_setbindtodevice net/core/sock.c:610 [inline]
       sock_setsockopt+0x431/0x1b20 net/core/sock.c:707
       SYSC_setsockopt net/socket.c:1845 [inline]
       SyS_setsockopt+0x2ff/0x360 net/socket.c:1828
       do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x42/0xb7
      RIP: 0033:0x4552d9
      RSP: 002b:00007f4878126c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
      RAX: ffffffffffffffda RBX: 00007f48781276d4 RCX: 00000000004552d9
      RDX: 0000000000000019 RSI: 0000000000000001 RDI: 0000000000000013
      RBP: 000000000072bea0 R08: 0000000000000010 R09: 0000000000000000
      R10: 00000000200010c0 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 0000000000000526 R14: 00000000006fac30 R15: 0000000000000000
      
      Allocated by task 20088:
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459 [inline]
       kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
       kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
       kmem_cache_alloc+0x12e/0x760 mm/slab.c:3542
       dst_alloc+0x11f/0x1a0 net/core/dst.c:104
       rt_dst_alloc+0xe9/0x540 net/ipv4/route.c:1520
       __mkroute_output net/ipv4/route.c:2265 [inline]
       ip_route_output_key_hash_rcu+0xa49/0x2c60 net/ipv4/route.c:2493
       ip_route_output_key_hash+0x20b/0x370 net/ipv4/route.c:2322
       __ip_route_output_key include/net/route.h:126 [inline]
       ip_route_output_flow+0x26/0xa0 net/ipv4/route.c:2577
       ip_route_output_ports include/net/route.h:163 [inline]
       pptp_connect+0xa84/0x1170 drivers/net/ppp/pptp.c:453
       SYSC_connect+0x213/0x4a0 net/socket.c:1639
       SyS_connect+0x24/0x30 net/socket.c:1620
       do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      Freed by task 20082:
       save_stack+0x43/0xd0 mm/kasan/kasan.c:447
       set_track mm/kasan/kasan.c:459 [inline]
       __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
       kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
       __cache_free mm/slab.c:3486 [inline]
       kmem_cache_free+0x83/0x2a0 mm/slab.c:3744
       dst_destroy+0x266/0x380 net/core/dst.c:140
       dst_destroy_rcu+0x16/0x20 net/core/dst.c:153
       __rcu_reclaim kernel/rcu/rcu.h:178 [inline]
       rcu_do_batch kernel/rcu/tree.c:2675 [inline]
       invoke_rcu_callbacks kernel/rcu/tree.c:2930 [inline]
       __rcu_process_callbacks kernel/rcu/tree.c:2897 [inline]
       rcu_process_callbacks+0xd6c/0x17b0 kernel/rcu/tree.c:2914
       __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
      
      The buggy address belongs to the object at ffff8801c54dc000
       which belongs to the cache ip_dst_cache of size 168
      The buggy address is located 64 bytes inside of
       168-byte region [ffff8801c54dc000, ffff8801c54dc0a8)
      The buggy address belongs to the page:
      page:ffffea0007153700 count:1 mapcount:0 mapping:ffff8801c54dc000 index:0x0
      flags: 0x2fffc0000000100(slab)
      raw: 02fffc0000000100 ffff8801c54dc000 0000000000000000 0000000100000010
      raw: ffffea0006b34b20 ffffea0006b6c1e0 ffff8801d674a1c0 0000000000000000
      page dumped because: kasan: bad access detected
      Signed-off-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>
      765884bc
    • Davide Caratti's avatar
      net/sched: fix NULL dereference in the error path of tcf_bpf_init() · 44c8871e
      Davide Caratti authored
      
      [ Upstream commit 3239534a ]
      
      when tcf_bpf_init_from_ops() fails (e.g. because of program having invalid
      number of instructions), tcf_bpf_cfg_cleanup() calls bpf_prog_put(NULL) or
      bpf_prog_destroy(NULL). Unless CONFIG_BPF_SYSCALL is unset, this causes
      the following error:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
       PGD 800000007345a067 P4D 800000007345a067 PUD 340e1067 PMD 0
       Oops: 0000 [#1] SMP PTI
       Modules linked in: act_bpf(E) ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 mbcache jbd2 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic pcbc snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd glue_helper cryptd joydev snd_timer snd virtio_balloon pcspkr soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm virtio_blk drm virtio_net virtio_console i2c_core crc32c_intel serio_raw virtio_pci ata_piix libata virtio_ring floppy virtio dm_mirror dm_region_hash dm_log dm_mod [last unloaded: act_bpf]
       CPU: 3 PID: 5654 Comm: tc Tainted: G            E    4.16.0.bpf_test+ #408
       Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
       RIP: 0010:__bpf_prog_put+0xc/0xc0
       RSP: 0018:ffff9594003ef728 EFLAGS: 00010202
       RAX: 0000000000000000 RBX: ffff9594003ef758 RCX: 0000000000000024
       RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
       RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000044
       R10: 0000000000000220 R11: ffff8a7ab9f17131 R12: 0000000000000000
       R13: ffff8a7ab7c3c8e0 R14: 0000000000000001 R15: ffff8a7ab88f1054
       FS:  00007fcb2f17c740(0000) GS:ffff8a7abfd80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000020 CR3: 000000007c888006 CR4: 00000000001606e0
       Call Trace:
        tcf_bpf_cfg_cleanup+0x2f/0x40 [act_bpf]
        tcf_bpf_cleanup+0x4c/0x70 [act_bpf]
        __tcf_idr_release+0x79/0x140
        tcf_bpf_init+0x125/0x330 [act_bpf]
        tcf_action_init_1+0x2cc/0x430
        ? get_page_from_freelist+0x3f0/0x11b0
        tcf_action_init+0xd3/0x1b0
        tc_ctl_action+0x18b/0x240
        rtnetlink_rcv_msg+0x29c/0x310
        ? _cond_resched+0x15/0x30
        ? __kmalloc_node_track_caller+0x1b9/0x270
        ? rtnl_calcit.isra.29+0x100/0x100
        netlink_rcv_skb+0xd2/0x110
        netlink_unicast+0x17c/0x230
        netlink_sendmsg+0x2cd/0x3c0
        sock_sendmsg+0x30/0x40
        ___sys_sendmsg+0x27a/0x290
        ? mem_cgroup_commit_charge+0x80/0x130
        ? page_add_new_anon_rmap+0x73/0xc0
        ? do_anonymous_page+0x2a2/0x560
        ? __handle_mm_fault+0xc75/0xe20
        __sys_sendmsg+0x58/0xa0
        do_syscall_64+0x6e/0x1a0
        entry_SYSCALL_64_after_hwframe+0x3d/0xa2
       RIP: 0033:0x7fcb2e58eba0
       RSP: 002b:00007ffc93c496c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
       RAX: ffffffffffffffda RBX: 00007ffc93c497f0 RCX: 00007fcb2e58eba0
       RDX: 0000000000000000 RSI: 00007ffc93c49740 RDI: 0000000000000003
       RBP: 000000005ac6a646 R08: 0000000000000002 R09: 0000000000000000
       R10: 00007ffc93c49120 R11: 0000000000000246 R12: 0000000000000000
       R13: 00007ffc93c49804 R14: 0000000000000001 R15: 000000000066afa0
       Code: 5f 00 48 8b 43 20 48 c7 c7 70 2f 7c b8 c7 40 10 00 00 00 00 5b e9 a5 8b 61 00 0f 1f 44 00 00 0f 1f 44 00 00 41 54 55 48 89 fd 53 <48> 8b 47 20 f0 ff 08 74 05 5b 5d 41 5c c3 41 89 f4 0f 1f 44 00
       RIP: __bpf_prog_put+0xc/0xc0 RSP: ffff9594003ef728
       CR2: 0000000000000020
      
      Fix it in tcf_bpf_cfg_cleanup(), ensuring that bpf_prog_{put,destroy}(f)
      is called only when f is not NULL.
      
      Fixes: bbc09e78 ("net/sched: fix idr leak on the error path of tcf_bpf_init()")
      Reported-by: default avatarLucas Bates <lucasb@mojatatu.com>
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      44c8871e
    • Alexander Potapenko's avatar
      netlink: make sure nladdr has correct size in netlink_connect() · cf105335
      Alexander Potapenko authored
      
      [ Upstream commit 78802879 ]
      
      KMSAN reports use of uninitialized memory in the case when |alen| is
      smaller than sizeof(struct sockaddr_nl), and therefore |nladdr| isn't
      fully copied from the userspace.
      Signed-off-by: default avatarAlexander Potapenko <glider@google.com>
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reviewed-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>
      cf105335
    • Jeff Barnhill's avatar
      net/ipv6: Increment OUTxxx counters after netfilter hook · 584d541c
      Jeff Barnhill authored
      
      [ Upstream commit 71a1c915 ]
      
      At the end of ip6_forward(), IPSTATS_MIB_OUTFORWDATAGRAMS and
      IPSTATS_MIB_OUTOCTETS are incremented immediately before the NF_HOOK call
      for NFPROTO_IPV6 / NF_INET_FORWARD.  As a result, these counters get
      incremented regardless of whether or not the netfilter hook allows the
      packet to continue being processed.  This change increments the counters
      in ip6_forward_finish() so that it will not happen if the netfilter hook
      chooses to terminate the packet, which is similar to how IPv4 works.
      Signed-off-by: default avatarJeff Barnhill <0xeffeff@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      584d541c
    • David Ahern's avatar
      net/ipv6: Fix route leaking between VRFs · eb3dd0f9
      David Ahern authored
      
      [ Upstream commit b6cdbc85 ]
      
      Donald reported that IPv6 route leaking between VRFs is not working.
      The root cause is the strict argument in the call to rt6_lookup when
      validating the nexthop spec.
      
      ip6_route_check_nh validates the gateway and device (if given) of a
      route spec. It in turn could call rt6_lookup (e.g., lookup in a given
      table did not succeed so it falls back to a full lookup) and if so
      sets the strict argument to 1. That means if the egress device is given,
      the route lookup needs to return a result with the same device. This
      strict requirement does not work with VRFs (IPv4 or IPv6) because the
      oif in the flow struct is overridden with the index of the VRF device
      to trigger a match on the l3mdev rule and force the lookup to its table.
      
      The right long term solution is to add an l3mdev index to the flow
      struct such that the oif is not overridden. That solution will not
      backport well, so this patch aims for a simpler solution to relax the
      strict argument if the route spec device is an l3mdev slave. As done
      in other places, use the FLOWI_FLAG_SKIP_NH_OIF to know that the
      RT6_LOOKUP_F_IFACE flag needs to be removed.
      
      Fixes: ca254490 ("net: Add VRF support to IPv6 stack")
      Reported-by: default avatarDonald Sharp <sharpd@cumulusnetworks.com>
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eb3dd0f9
    • Eric Dumazet's avatar
      net: fix possible out-of-bound read in skb_network_protocol() · fb9fa142
      Eric Dumazet authored
      
      [ Upstream commit 1dfe82eb ]
      
      skb mac header is not necessarily set at the time skb_network_protocol()
      is called. Use skb->data instead.
      
      BUG: KASAN: slab-out-of-bounds in skb_network_protocol+0x46b/0x4b0 net/core/dev.c:2739
      Read of size 2 at addr ffff8801b3097a0b by task syz-executor5/14242
      
      CPU: 1 PID: 14242 Comm: syz-executor5 Not tainted 4.16.0-rc6+ #280
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x194/0x24d lib/dump_stack.c:53
       print_address_description+0x73/0x250 mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report+0x23c/0x360 mm/kasan/report.c:412
       __asan_report_load_n_noabort+0xf/0x20 mm/kasan/report.c:443
       skb_network_protocol+0x46b/0x4b0 net/core/dev.c:2739
       harmonize_features net/core/dev.c:2924 [inline]
       netif_skb_features+0x509/0x9b0 net/core/dev.c:3011
       validate_xmit_skb+0x81/0xb00 net/core/dev.c:3084
       validate_xmit_skb_list+0xbf/0x120 net/core/dev.c:3142
       packet_direct_xmit+0x117/0x790 net/packet/af_packet.c:256
       packet_snd net/packet/af_packet.c:2944 [inline]
       packet_sendmsg+0x3aed/0x60b0 net/packet/af_packet.c:2969
       sock_sendmsg_nosec net/socket.c:629 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:639
       ___sys_sendmsg+0x767/0x8b0 net/socket.c:2047
       __sys_sendmsg+0xe5/0x210 net/socket.c:2081
      
      Fixes: 19acc327 ("gso: Handle Trans-Ether-Bridging protocol in skb_network_protocol()")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Pravin B Shelar <pshelar@ovn.org>
      Reported-by: default avatarReported-by: syzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fb9fa142
    • Paolo Abeni's avatar
      ipv6: the entire IPv6 header chain must fit the first fragment · 81eb03e0
      Paolo Abeni authored
      
      [ Upstream commit 10b8a3de ]
      
      While building ipv6 datagram we currently allow arbitrary large
      extheaders, even beyond pmtu size. The syzbot has found a way
      to exploit the above to trigger the following splat:
      
      kernel BUG at ./include/linux/skbuff.h:2073!
      invalid opcode: 0000 [#1] SMP KASAN
      Dumping ftrace buffer:
          (ftrace buffer empty)
      Modules linked in:
      CPU: 1 PID: 4230 Comm: syzkaller672661 Not tainted 4.16.0-rc2+ #326
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      RIP: 0010:__skb_pull include/linux/skbuff.h:2073 [inline]
      RIP: 0010:__ip6_make_skb+0x1ac8/0x2190 net/ipv6/ip6_output.c:1636
      RSP: 0018:ffff8801bc18f0f0 EFLAGS: 00010293
      RAX: ffff8801b17400c0 RBX: 0000000000000738 RCX: ffffffff84f01828
      RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8801b415ac18
      RBP: ffff8801bc18f360 R08: ffff8801b4576844 R09: 0000000000000000
      R10: ffff8801bc18f380 R11: ffffed00367aee4e R12: 00000000000000d6
      R13: ffff8801b415a740 R14: dffffc0000000000 R15: ffff8801b45767c0
      FS:  0000000001535880(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000000002000b000 CR3: 00000001b4123001 CR4: 00000000001606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
        ip6_finish_skb include/net/ipv6.h:969 [inline]
        udp_v6_push_pending_frames+0x269/0x3b0 net/ipv6/udp.c:1073
        udpv6_sendmsg+0x2a96/0x3400 net/ipv6/udp.c:1343
        inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:764
        sock_sendmsg_nosec net/socket.c:630 [inline]
        sock_sendmsg+0xca/0x110 net/socket.c:640
        ___sys_sendmsg+0x320/0x8b0 net/socket.c:2046
        __sys_sendmmsg+0x1ee/0x620 net/socket.c:2136
        SYSC_sendmmsg net/socket.c:2167 [inline]
        SyS_sendmmsg+0x35/0x60 net/socket.c:2162
        do_syscall_64+0x280/0x940 arch/x86/entry/common.c:287
        entry_SYSCALL_64_after_hwframe+0x42/0xb7
      RIP: 0033:0x4404c9
      RSP: 002b:00007ffdce35f948 EFLAGS: 00000217 ORIG_RAX: 0000000000000133
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004404c9
      RDX: 0000000000000003 RSI: 0000000020001f00 RDI: 0000000000000003
      RBP: 00000000006cb018 R08: 00000000004002c8 R09: 00000000004002c8
      R10: 0000000020000080 R11: 0000000000000217 R12: 0000000000401df0
      R13: 0000000000401e80 R14: 0000000000000000 R15: 0000000000000000
      Code: ff e8 1d 5e b9 fc e9 15 e9 ff ff e8 13 5e b9 fc e9 44 e8 ff ff e8 29
      5e b9 fc e9 c0 e6 ff ff e8 3f f3 80 fc 0f 0b e8 38 f3 80 fc <0f> 0b 49 8d
      87 80 00 00 00 4d 8d 87 84 00 00 00 48 89 85 20 fe
      RIP: __skb_pull include/linux/skbuff.h:2073 [inline] RSP: ffff8801bc18f0f0
      RIP: __ip6_make_skb+0x1ac8/0x2190 net/ipv6/ip6_output.c:1636 RSP:
      ffff8801bc18f0f0
      
      As stated by RFC 7112 section 5:
      
         When a host fragments an IPv6 datagram, it MUST include the entire
         IPv6 Header Chain in the First Fragment.
      
      So this patch addresses the issue dropping datagrams with excessive
      extheader length. It also updates the error path to report to the
      calling socket nonnegative pmtu values.
      
      The issue apparently predates git history.
      
      v1 -> v2: cleanup error path, as per Eric's suggestion
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: syzbot+91e6f9932ff122fa4410@syzkaller.appspotmail.com
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-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>
      81eb03e0
    • Miguel Fadon Perlines's avatar
      arp: fix arp_filter on l3slave devices · 24123fde
      Miguel Fadon Perlines authored
      
      [ Upstream commit 58b35f27 ]
      
      arp_filter performs an ip_route_output search for arp source address and
      checks if output device is the same where the arp request was received,
      if it is not, the arp request is not answered.
      
      This route lookup is always done on main route table so l3slave devices
      never find the proper route and arp is not answered.
      
      Passing l3mdev_master_ifindex_rcu(dev) return value as oif fixes the
      lookup for l3slave devices while maintaining same behavior for non
      l3slave devices as this function returns 0 in that case.
      
      Fixes: 613d09b3 ("net: Use VRF device index for lookups on TX")
      Signed-off-by: default avatarMiguel Fadon Perlines <mfadon@teldat.com>
      Acked-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24123fde
    • Alexandre Belloni's avatar
      clk: at91: fix clk-generated compilation · 2f9c90e7
      Alexandre Belloni authored
      commit 4a5f06a0 upstream.
      
      Fix missing }
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Cc: Amit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f9c90e7
    • Theodore Ts'o's avatar
      random: use lockless method of accessing and updating f->reg_idx · b4d93c6f
      Theodore Ts'o authored
      commit 92e75428 upstream.
      
      Linus pointed out that there is a much more efficient way of avoiding
      the problem that we were trying to address in commit 9dfa7bba:
      "fix race in drivers/char/random.c:get_reg()".
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: Michael Schmitz <schmitzmic@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b4d93c6f
    • Nathan Chancellor's avatar
      virtio_net: check return value of skb_to_sgvec in one more location · 32a1f129
      Nathan Chancellor authored
      Kernels that do not have f6b10209 ("virtio-net: switch to use
      build_skb() for small buffer") will have an extra call to skb_to_sgvec
      that is not handled by e2fcad58 ("virtio_net: check return value of
      skb_to_sgvec always"). Since the former does not appear to be stable
      material, just fix the call up directly.
      
      Cc: Jason A. Donenfeld <Jason@zx2c4.com>
      Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      32a1f129
    • Jason A. Donenfeld's avatar
      virtio_net: check return value of skb_to_sgvec always · 0414cff3
      Jason A. Donenfeld authored
      commit e2fcad58 upstream.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Reviewed-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0414cff3
    • Jason A. Donenfeld's avatar
    • Jason A. Donenfeld's avatar
      ipsec: check return value of skb_to_sgvec always · 753b04d2
      Jason A. Donenfeld authored
      commit 3f297707 upstream.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [natechancellor: Adjusted context due to lack of fca11ebd]
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      753b04d2
    • Jiri Olsa's avatar
      perf tools: Fix copyfile_offset update of output offset · 720f6277
      Jiri Olsa authored
      
      [ Upstream commit fa1195cc ]
      
      We need to increase output offset in each iteration, not decrease it as
      we currently do.
      
      I guess we were lucky to finish in most cases in first iteration, so the
      bug never showed. However it shows a lot when working with big (~4GB)
      size data.
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Fixes: 9c9f5a2f ("perf tools: Introduce copyfile_offset() function")
      Link: http://lkml.kernel.org/r/20180109133923.25406-1-jolsa@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      720f6277
    • Miquel Raynal's avatar
      mtd: mtd_oobtest: Handle bitflips during reads · f6df92f2
      Miquel Raynal authored
      
      [ Upstream commit 12663b44 ]
      
      Reads from NAND devices usually trigger bitflips, this is an expected
      behavior. While bitflips are under a given threshold, the MTD core
      returns 0. However, when the number of corrected bitflips is above this
      same threshold, -EUCLEAN is returned to inform the upper layer that this
      block is slightly dying and soon the ECC engine will be overtaken so
      actions should be taken to move the data out of it.
      
      This particular condition should not be treated like an error and the
      test should continue.
      Signed-off-by: default avatarMiquel Raynal <miquel.raynal@free-electrons.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f6df92f2
    • Hans de Goede's avatar
      Input: goodix - disable IRQs while suspended · 2a584051
      Hans de Goede authored
      
      [ Upstream commit faec44b6 ]
      
      We should not try to do any i2c transfers before the controller is
      resumed (which happens before our resume method gets called).
      
      So we need to disable our IRQ while suspended to enforce this. The
      code paths for devices with GPIOs for the int and reset pins already
      disable the IRQ the through goodix_free_irq().
      
      This commit also disables the IRQ while suspended for devices without
      GPIOs for the int and reset pins.
      
      This fixes the i2c bus sometimes getting stuck after a suspend/resume
      causing the touchscreen to sometimes not work after a suspend/resume.
      This has been tested on a GPD pocked device.
      
      BugLink: https://github.com/nexus511/gpd-ubuntu-packages/issues/10
      BugLink: https://www.reddit.com/r/GPDPocket/comments/7niut2/fix_for_broken_touch_after_resume_all_linux/Tested-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarBastien Nocera <hadess@hadess.net>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a584051
    • Andy Shevchenko's avatar
      sdhci: Advertise 2.0v supply on SDIO host controller · 905348d0
      Andy Shevchenko authored
      
      [ Upstream commit 2a609abe ]
      
      On Intel Edison the Broadcom Wi-Fi card, which is connected to SDIO,
      requires 2.0v, while the host, according to Intel Merrifield TRM,
      supports 1.8v supply only.
      
      The card announces itself as
      
        mmc2: new ultra high speed DDR50 SDIO card at address 0001
      
      Introduce a custom OCR mask for SDIO host controller on Intel Merrifield
      and add a special case to sdhci_set_power_noreg() to override 2.0v supply
      by enforcing 1.8v power choice.
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      905348d0
    • Arjun Vynipadath's avatar
      cxgb4vf: Fix SGE FL buffer initialization logic for 64K pages · d774913b
      Arjun Vynipadath authored
      
      [ Upstream commit ea0a4210 ]
      
      We'd come in with SGE_FL_BUFFER_SIZE[0] and [1] both equal to 64KB and
      the extant logic would flag that as an error. This was already fixed in
      cxgb4 driver with "92ddcc7b cxgb4: Fix some small bugs in
      t4_sge_init_soft() when our Page Size is 64KB".
      
      Original Work by: Casey Leedom <leedom@chelsio.com>
      Signed-off-by: default avatarArjun Vynipadath <arjun@chelsio.com>
      Signed-off-by: default avatarGanesh Goudar <ganeshgr@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d774913b
    • Christophe JAILLET's avatar
      EDAC, mv64x60: Fix an error handling path · 8c2ba5fa
      Christophe JAILLET authored
      
      [ Upstream commit 68fa24f9 ]
      
      We should not call edac_mc_del_mc() if a corresponding call to
      edac_mc_add_mc() has not been performed yet.
      
      So here, we should go to err instead of err2 to branch at the right
      place of the error handling path.
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Link: http://lkml.kernel.org/r/20180107205400.14068-1-christophe.jaillet@wanadoo.frSigned-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8c2ba5fa
    • Tony Lindgren's avatar
      tty: n_gsm: Allow ADM response in addition to UA for control dlci · a74b51be
      Tony Lindgren authored
      
      [ Upstream commit ea3d8465 ]
      
      Some devices have the control dlci stay in ADM mode instead of the UA
      mode. This can seen at least on droid 4 when trying to open the ts
      27.010 mux port. Enabling n_gsm debug mode shows the control dlci
      always respond with DM to SABM instead of UA:
      
      # modprobe n_gsm debug=0xff
      # ldattach -d GSM0710 /dev/ttyS0 &
      gsmld_output: 00000000: f9 03 3f 01 1c f9
      --> 0) C: SABM(P)
      gsmld_receive: 00000000: f9 03 1f 01 36 f9
      <-- 0) C: DM(P)
      ...
      $ minicom -D /dev/gsmtty1
      minicom: cannot open /dev/gsmtty1: No error information
      $ strace minicom -D /dev/gsmtty1
      ...
      open("/dev/gsmtty1", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = -1 EL2HLT
      
      Note that this is different issue from other n_gsm -EL2HLT issues such
      as timeouts when the control dlci does not respond at all.
      
      The ADM mode seems to be a quite common according to "RF Wireless World"
      article "GSM Issue-UE sends SABM and gets a DM response instead of
      UA response":
      
        This issue is most commonly observed in GSM networks where in UE sends
        SABM and expects network to send UA response but it ends up receiving
        DM response from the network. SABM stands for Set asynchronous balanced
        mode, UA stands for Unnumbered Acknowledge and DA stands for
        Disconnected Mode.
      
        An RLP entity can be in one of two modes:
        - Asynchronous Balanced Mode (ABM)
        - Asynchronous Disconnected Mode (ADM)
      
      Currently Linux kernel closes the control dlci after several retries
      in gsm_dlci_t1() on DM. This causes n_gsm /dev/gsmtty ports to produce
      error code -EL2HLT when trying to open them as the closing of control
      dlci has already set gsm->dead.
      
      Let's fix the issue by allowing control dlci stay in ADM mode after the
      retries so the /dev/gsmtty ports can be opened and used. It seems that
      it might take several attempts to get any response from the control
      dlci, so it's best to allow ADM mode only after the SABM retries are
      done.
      
      Note that for droid 4 additional patches are needed to mux the ttyS0
      pins and to toggle RTS gpio_149 to wake up the mdm6600 modem are also
      needed to use n_gsm. And the mdm6600 modem needs to be powered on.
      
      Cc: linux-serial@vger.kernel.org
      Cc: Alan Cox <alan@llwyncelyn.cymru>
      Cc: Jiri Prchal <jiri.prchal@aksignal.cz>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Marcel Partap <mpartap@gmx.net>
      Cc: Michael Scott <michael.scott@linaro.org>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Cc: Russ Gorby <russ.gorby@intel.com>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Sebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a74b51be
    • Ming Lei's avatar
      blk-mq: fix kernel oops in blk_mq_tag_idle() · 3f4e2419
      Ming Lei authored
      
      [ Upstream commit 8ab0b7dc ]
      
      HW queues may be unmapped in some cases, such as blk_mq_update_nr_hw_queues(),
      then we need to check it before calling blk_mq_tag_idle(), otherwise
      the following kernel oops can be triggered, so fix it by checking if
      the hw queue is unmapped since it doesn't make sense to idle the tags
      any more after hw queues are unmapped.
      
      [  440.771298] Workqueue: nvme-wq nvme_rdma_del_ctrl_work [nvme_rdma]
      [  440.779104] task: ffff894bae755ee0 ti: ffff893bf9bc8000 task.ti: ffff893bf9bc8000
      [  440.788359] RIP: 0010:[<ffffffffb730e2b4>]  [<ffffffffb730e2b4>] __blk_mq_tag_idle+0x24/0x40
      [  440.798697] RSP: 0018:ffff893bf9bcbd10  EFLAGS: 00010286
      [  440.805538] RAX: 0000000000000000 RBX: ffff895bb131dc00 RCX: 000000000000011f
      [  440.814426] RDX: 00000000ffffffff RSI: 0000000000000120 RDI: ffff895bb131dc00
      [  440.823301] RBP: ffff893bf9bcbd10 R08: 000000000001b860 R09: 4a51d361c00c0000
      [  440.832193] R10: b5907f32b4cc7003 R11: ffffd6cabfb57000 R12: ffff894bafd1e008
      [  440.841091] R13: 0000000000000001 R14: ffff895baf770000 R15: 0000000000000080
      [  440.849988] FS:  0000000000000000(0000) GS:ffff894bbdcc0000(0000) knlGS:0000000000000000
      [  440.859955] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  440.867274] CR2: 0000000000000008 CR3: 000000103d098000 CR4: 00000000001407e0
      [  440.876169] Call Trace:
      [  440.879818]  [<ffffffffb7309d68>] blk_mq_exit_hctx+0xd8/0xe0
      [  440.887051]  [<ffffffffb730dc40>] blk_mq_free_queue+0xf0/0x160
      [  440.894465]  [<ffffffffb72ff679>] blk_cleanup_queue+0xd9/0x150
      [  440.901881]  [<ffffffffc08a802b>] nvme_ns_remove+0x5b/0xb0 [nvme_core]
      [  440.910068]  [<ffffffffc08a811b>] nvme_remove_namespaces+0x3b/0x60 [nvme_core]
      [  440.919026]  [<ffffffffc08b817b>] __nvme_rdma_remove_ctrl+0x2b/0xb0 [nvme_rdma]
      [  440.928079]  [<ffffffffc08b8237>] nvme_rdma_del_ctrl_work+0x17/0x20 [nvme_rdma]
      [  440.937126]  [<ffffffffb70ab58a>] process_one_work+0x17a/0x440
      [  440.944517]  [<ffffffffb70ac3a8>] worker_thread+0x278/0x3c0
      [  440.951607]  [<ffffffffb70ac130>] ? manage_workers.isra.24+0x2a0/0x2a0
      [  440.959760]  [<ffffffffb70b352f>] kthread+0xcf/0xe0
      [  440.966055]  [<ffffffffb70b3460>] ? insert_kthread_work+0x40/0x40
      [  440.973715]  [<ffffffffb76d8658>] ret_from_fork+0x58/0x90
      [  440.980586]  [<ffffffffb70b3460>] ? insert_kthread_work+0x40/0x40
      [  440.988229] Code: 5b 41 5c 5d c3 66 90 0f 1f 44 00 00 48 8b 87 20 01 00 00 f0 0f ba 77 40 01 19 d2 85 d2 75 08 c3 0f 1f 80 00 00 00 00 55 48 89 e5 <f0> ff 48 08 48 8d 78 10 e8 7f 0f 05 00 5d c3 0f 1f 00 66 2e 0f
      [  441.011620] RIP  [<ffffffffb730e2b4>] __blk_mq_tag_idle+0x24/0x40
      [  441.019301]  RSP <ffff893bf9bcbd10>
      [  441.024052] CR2: 0000000000000008
      Reported-by: default avatarZhang Yi <yizhan@redhat.com>
      Tested-by: default avatarZhang Yi <yizhan@redhat.com>
      Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3f4e2419
    • chenxiang's avatar
      scsi: libsas: initialize sas_phy status according to response of DISCOVER · cafd951e
      chenxiang authored
      
      [ Upstream commit affc6778 ]
      
      The status of SAS PHY is in sas_phy->enabled. There is an issue that the
      status of a remote SAS PHY may be initialized incorrectly: if disable
      remote SAS PHY through sysfs interface (such as echo 0 >
      /sys/class/sas_phy/phy-1:0:0/enable), then reboot the system, and we
      will find the status of remote SAS PHY which is disabled before is
      1 (cat /sys/class/sas_phy/phy-1:0:0/enable). But actually the status of
      remote SAS PHY is disabled and the device attached is not found.
      
      In SAS protocol, NEGOTIATED LOGICAL LINK RATE field of DISCOVER response
      is 0x1 when remote SAS PHY is disabled. So initialize sas_phy->enabled
      according to the value of NEGOTIATED LOGICAL LINK RATE field.
      Signed-off-by: default avatarchenxiang <chenxiang66@hisilicon.com>
      Reviewed-by: default avatarJohn Garry <john.garry@huawei.com>
      Signed-off-by: default avatarJason Yan <yanaijie@huawei.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cafd951e
    • Jason Yan's avatar
      scsi: libsas: fix error when getting phy events · 7333f172
      Jason Yan authored
      
      [ Upstream commit 2b23d950 ]
      
      The intend purpose here was to goto out if smp_execute_task() returned
      error. Obviously something got screwed up. We will never get these link
      error statistics below:
      
      ~:/sys/class/sas_phy/phy-1:0:12 # cat invalid_dword_count
      0
      ~:/sys/class/sas_phy/phy-1:0:12 # cat running_disparity_error_count
      0
      ~:/sys/class/sas_phy/phy-1:0:12 # cat loss_of_dword_sync_count
      0
      ~:/sys/class/sas_phy/phy-1:0:12 # cat phy_reset_problem_count
      0
      
      Obviously we should goto error handler if smp_execute_task() returns
      non-zero.
      
      Fixes: 2908d778 ("[SCSI] aic94xx: new driver")
      Signed-off-by: default avatarJason Yan <yanaijie@huawei.com>
      CC: John Garry <john.garry@huawei.com>
      CC: chenqilin <chenqilin2@huawei.com>
      CC: chenxiang <chenxiang66@hisilicon.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7333f172
    • Jason Yan's avatar
      scsi: libsas: fix memory leak in sas_smp_get_phy_events() · 0ef71347
      Jason Yan authored
      
      [ Upstream commit 4a491b1a ]
      
      We've got a memory leak with the following producer:
      
      while true;
      do cat /sys/class/sas_phy/phy-1:0:12/invalid_dword_count >/dev/null;
      done
      
      The buffer req is allocated and not freed after we return. Fix it.
      
      Fixes: 2908d778 ("[SCSI] aic94xx: new driver")
      Signed-off-by: default avatarJason Yan <yanaijie@huawei.com>
      CC: John Garry <john.garry@huawei.com>
      CC: chenqilin <chenqilin2@huawei.com>
      CC: chenxiang <chenxiang66@hisilicon.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ef71347
    • Tang Junhui's avatar
      bcache: segregate flash only volume write streams · 38f1e54e
      Tang Junhui authored
      
      [ Upstream commit 4eca1cb2 ]
      
      In such scenario that there are some flash only volumes
      , and some cached devices, when many tasks request these devices in
      writeback mode, the write IOs may fall to the same bucket as bellow:
      | cached data | flash data | cached data | cached data| flash data|
      then after writeback of these cached devices, the bucket would
      be like bellow bucket:
      | free | flash data | free | free | flash data |
      
      So, there are many free space in this bucket, but since data of flash
      only volumes still exists, so this bucket cannot be reclaimable,
      which would cause waste of bucket space.
      
      In this patch, we segregate flash only volume write streams from
      cached devices, so data from flash only volumes and cached devices
      can store in different buckets.
      
      Compare to v1 patch, this patch do not add a additionally open bucket
      list, and it is try best to segregate flash only volume write streams
      from cached devices, sectors of flash only volumes may still be mixed
      with dirty sectors of cached device, but the number is very small.
      
      [mlyle: fixed commit log formatting, permissions, line endings]
      Signed-off-by: default avatarTang Junhui <tang.junhui@zte.com.cn>
      Reviewed-by: default avatarMichael Lyle <mlyle@lyle.org>
      Signed-off-by: default avatarMichael Lyle <mlyle@lyle.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38f1e54e
    • Tang Junhui's avatar
      bcache: stop writeback thread after detaching · d046bb9e
      Tang Junhui authored
      
      [ Upstream commit 8d29c442 ]
      
      Currently, when a cached device detaching from cache, writeback thread is
      not stopped, and writeback_rate_update work is not canceled. For example,
      after the following command:
      echo 1 >/sys/block/sdb/bcache/detach
      you can still see the writeback thread. Then you attach the device to the
      cache again, bcache will create another writeback thread, for example,
      after below command:
      echo  ba0fb5cd-658a-4533-9806-6ce166d883b9 > /sys/block/sdb/bcache/attach
      then you will see 2 writeback threads.
      This patch stops writeback thread and cancels writeback_rate_update work
      when cached device detaching from cache.
      
      Compare with patch v1, this v2 patch moves code down into the register
      lock for safety in case of any future changes as Coly and Mike suggested.
      
      [edit by mlyle: commit log spelling/formatting]
      Signed-off-by: default avatarTang Junhui <tang.junhui@zte.com.cn>
      Reviewed-by: default avatarMichael Lyle <mlyle@lyle.org>
      Signed-off-by: default avatarMichael Lyle <mlyle@lyle.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d046bb9e
    • Christophe JAILLET's avatar
      drm/vc4: Fix resource leak in 'vc4_get_hang_state_ioctl()' in error handling path · 9622668c
      Christophe JAILLET authored
      
      [ Upstream commit d0b1d259 ]
      
      If one 'drm_gem_handle_create()' fails, we leak somes handles and some
      memory.
      
      In order to fix it:
        - move the 'free(bo_state)' at the end of the function so that it is also
          called in the eror handling path. This has the side effect to also try
          to free it if the first 'kcalloc' fails. This is harmless.
        - add a new label, err_delete_handle, in order to delete already
          allocated handles in error handling path
        - remove the now useless 'err' label
      
      The way the code is now written will also delete the handles if the
      'copy_to_user()' call fails.
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170512123803.1886-1-christophe.jaillet@wanadoo.frSigned-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9622668c
    • Mickaël Salaün's avatar
      selftests: kselftest_harness: Fix compile warning · db14d756
      Mickaël Salaün authored
      
      [ Upstream commit 34a048cc ]
      
      Do not confuse the compiler with a semicolon preceding a block. Replace
      the semicolon with an empty block to avoid a warning:
      
        gcc -Wl,-no-as-needed -Wall -lpthread seccomp_bpf.c -o /.../linux/tools/testing/selftests/seccomp/seccomp_bpf
        In file included from seccomp_bpf.c:40:0:
        seccomp_bpf.c: In function ‘change_syscall’:
        ../kselftest_harness.h:558:2: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
          for (; _metadata->trigger;  _metadata->trigger = __bail(_assert))
          ^
        ../kselftest_harness.h:574:14: note: in expansion of macro ‘OPTIONAL_HANDLER’
         } while (0); OPTIONAL_HANDLER(_assert)
                      ^~~~~~~~~~~~~~~~
        ../kselftest_harness.h:440:2: note: in expansion of macro ‘__EXPECT’
          __EXPECT(expected, seen, ==, 0)
          ^~~~~~~~
        seccomp_bpf.c:1313:2: note: in expansion of macro ‘EXPECT_EQ’
          EXPECT_EQ(0, ret);
          ^~~~~~~~~
        seccomp_bpf.c:1317:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
          {
          ^
      Signed-off-by: default avatarMickaël Salaün <mic@digikod.net>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Shuah Khan <shuahkh@osg.samsung.com>
      Cc: Will Drewry <wad@chromium.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db14d756
    • Karicheri, Muralidharan's avatar
      hsr: fix incorrect warning · 329812f9
      Karicheri, Muralidharan authored
      
      [ Upstream commit 675c8da0 ]
      
      When HSR interface is setup using ip link command, an annoying warning
      appears with the trace as below:-
      
      [  203.019828] hsr_get_node: Non-HSR frame
      [  203.019833] Modules linked in:
      [  203.019848] CPU: 0 PID: 158 Comm: sd-resolve Tainted: G        W       4.12.0-rc3-00052-g9fa6bf70 #2
      [  203.019853] Hardware name: Generic DRA74X (Flattened Device Tree)
      [  203.019869] [<c0110280>] (unwind_backtrace) from [<c010c2f4>] (show_stack+0x10/0x14)
      [  203.019880] [<c010c2f4>] (show_stack) from [<c04b9f64>] (dump_stack+0xac/0xe0)
      [  203.019894] [<c04b9f64>] (dump_stack) from [<c01374e8>] (__warn+0xd8/0x104)
      [  203.019907] [<c01374e8>] (__warn) from [<c0137548>] (warn_slowpath_fmt+0x34/0x44)
      root@am57xx-evm:~# [  203.019921] [<c0137548>] (warn_slowpath_fmt) from [<c081126c>] (hsr_get_node+0x148/0x170)
      [  203.019932] [<c081126c>] (hsr_get_node) from [<c0814240>] (hsr_forward_skb+0x110/0x7c0)
      [  203.019942] [<c0814240>] (hsr_forward_skb) from [<c0811d64>] (hsr_dev_xmit+0x2c/0x34)
      [  203.019954] [<c0811d64>] (hsr_dev_xmit) from [<c06c0828>] (dev_hard_start_xmit+0xc4/0x3bc)
      [  203.019963] [<c06c0828>] (dev_hard_start_xmit) from [<c06c13d8>] (__dev_queue_xmit+0x7c4/0x98c)
      [  203.019974] [<c06c13d8>] (__dev_queue_xmit) from [<c0782f54>] (ip6_finish_output2+0x330/0xc1c)
      [  203.019983] [<c0782f54>] (ip6_finish_output2) from [<c0788f0c>] (ip6_output+0x58/0x454)
      [  203.019994] [<c0788f0c>] (ip6_output) from [<c07b16cc>] (mld_sendpack+0x420/0x744)
      
      As this is an expected path to hsr_get_node() with frame coming from
      the master interface, add a check to ensure packet is not from the
      master port and then warn.
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      329812f9