1. 27 12月, 2019 40 次提交
    • E
      net/mlx5e: ethtool, Remove unsupported SFP EEPROM high pages query · ff68cc2e
      Erez Alfasi 提交于
      [ Upstream commit ace329f4 ]
      
      Querying EEPROM high pages data for SFP module is currently
      not supported by our driver and yet queried, resulting in
      invalid FW queries.
      
      Set the EEPROM ethtool data length to 256 for SFP module will
      limit the reading for page 0 only and prevent invalid FW queries.
      
      Fixes: bb64143e ("net/mlx5e: Add ethtool support for dump module EEPROM")
      Signed-off-by: NErez Alfasi <ereza@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      ff68cc2e
    • A
      mlxsw: spectrum: Fix autoneg status in ethtool · 86cdfa6a
      Amit Cohen 提交于
      [ Upstream commit 151f0ddd ]
      
      If link is down and autoneg is set to on/off, the status in ethtool does
      not change.
      
      The reason is when the link is down the function returns with zero
      before changing autoneg value.
      
      Move the checking of link state (up/down) to be performed after setting
      autoneg value, in order to be sure that autoneg will change in any case.
      
      Fixes: 56ade8fe ("mlxsw: spectrum: Add initial support for Spectrum ASIC")
      Signed-off-by: NAmit Cohen <amitc@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      86cdfa6a
    • Z
      ipv4: set the tcp_min_rtt_wlen range from 0 to one day · 337b48f6
      ZhangXiaoxu 提交于
      [ Upstream commit 19fad20d ]
      
      There is a UBSAN report as below:
      UBSAN: Undefined behaviour in net/ipv4/tcp_input.c:2877:56
      signed integer overflow:
      2147483647 * 1000 cannot be represented in type 'int'
      CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.1.0-rc4-00058-g582549e3 #1
      Call Trace:
       <IRQ>
       dump_stack+0x8c/0xba
       ubsan_epilogue+0x11/0x60
       handle_overflow+0x12d/0x170
       ? ttwu_do_wakeup+0x21/0x320
       __ubsan_handle_mul_overflow+0x12/0x20
       tcp_ack_update_rtt+0x76c/0x780
       tcp_clean_rtx_queue+0x499/0x14d0
       tcp_ack+0x69e/0x1240
       ? __wake_up_sync_key+0x2c/0x50
       ? update_group_capacity+0x50/0x680
       tcp_rcv_established+0x4e2/0xe10
       tcp_v4_do_rcv+0x22b/0x420
       tcp_v4_rcv+0xfe8/0x1190
       ip_protocol_deliver_rcu+0x36/0x180
       ip_local_deliver+0x15b/0x1a0
       ip_rcv+0xac/0xd0
       __netif_receive_skb_one_core+0x7f/0xb0
       __netif_receive_skb+0x33/0xc0
       netif_receive_skb_internal+0x84/0x1c0
       napi_gro_receive+0x2a0/0x300
       receive_buf+0x3d4/0x2350
       ? detach_buf_split+0x159/0x390
       virtnet_poll+0x198/0x840
       ? reweight_entity+0x243/0x4b0
       net_rx_action+0x25c/0x770
       __do_softirq+0x19b/0x66d
       irq_exit+0x1eb/0x230
       do_IRQ+0x7a/0x150
       common_interrupt+0xf/0xf
       </IRQ>
      
      It can be reproduced by:
        echo 2147483647 > /proc/sys/net/ipv4/tcp_min_rtt_wlen
      
      Fixes: f6722583 ("tcp: track min RTT using windowed min-filter")
      Signed-off-by: NZhangXiaoxu <zhangxiaoxu5@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      337b48f6
    • E
      ipv4: add sanity checks in ipv4_link_failure() · 2fe8d032
      Eric Dumazet 提交于
      [ Upstream commit 20ff83f1 ]
      
      Before calling __ip_options_compile(), we need to ensure the network
      header is a an IPv4 one, and that it is already pulled in skb->head.
      
      RAW sockets going through a tunnel can end up calling ipv4_link_failure()
      with total garbage in the skb, or arbitrary lengthes.
      
      syzbot report :
      
      BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:355 [inline]
      BUG: KASAN: stack-out-of-bounds in __ip_options_echo+0x294/0x1120 net/ipv4/ip_options.c:123
      Write of size 69 at addr ffff888096abf068 by task syz-executor.4/9204
      
      CPU: 0 PID: 9204 Comm: syz-executor.4 Not tainted 5.1.0-rc5+ #77
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
       kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       check_memory_region_inline mm/kasan/generic.c:185 [inline]
       check_memory_region+0x123/0x190 mm/kasan/generic.c:191
       memcpy+0x38/0x50 mm/kasan/common.c:133
       memcpy include/linux/string.h:355 [inline]
       __ip_options_echo+0x294/0x1120 net/ipv4/ip_options.c:123
       __icmp_send+0x725/0x1400 net/ipv4/icmp.c:695
       ipv4_link_failure+0x29f/0x550 net/ipv4/route.c:1204
       dst_link_failure include/net/dst.h:427 [inline]
       vti6_xmit net/ipv6/ip6_vti.c:514 [inline]
       vti6_tnl_xmit+0x10d4/0x1c0c net/ipv6/ip6_vti.c:553
       __netdev_start_xmit include/linux/netdevice.h:4414 [inline]
       netdev_start_xmit include/linux/netdevice.h:4423 [inline]
       xmit_one net/core/dev.c:3292 [inline]
       dev_hard_start_xmit+0x1b2/0x980 net/core/dev.c:3308
       __dev_queue_xmit+0x271d/0x3060 net/core/dev.c:3878
       dev_queue_xmit+0x18/0x20 net/core/dev.c:3911
       neigh_direct_output+0x16/0x20 net/core/neighbour.c:1527
       neigh_output include/net/neighbour.h:508 [inline]
       ip_finish_output2+0x949/0x1740 net/ipv4/ip_output.c:229
       ip_finish_output+0x73c/0xd50 net/ipv4/ip_output.c:317
       NF_HOOK_COND include/linux/netfilter.h:278 [inline]
       ip_output+0x21f/0x670 net/ipv4/ip_output.c:405
       dst_output include/net/dst.h:444 [inline]
       NF_HOOK include/linux/netfilter.h:289 [inline]
       raw_send_hdrinc net/ipv4/raw.c:432 [inline]
       raw_sendmsg+0x1d2b/0x2f20 net/ipv4/raw.c:663
       inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
       sock_sendmsg_nosec net/socket.c:651 [inline]
       sock_sendmsg+0xdd/0x130 net/socket.c:661
       sock_write_iter+0x27c/0x3e0 net/socket.c:988
       call_write_iter include/linux/fs.h:1866 [inline]
       new_sync_write+0x4c7/0x760 fs/read_write.c:474
       __vfs_write+0xe4/0x110 fs/read_write.c:487
       vfs_write+0x20c/0x580 fs/read_write.c:549
       ksys_write+0x14f/0x2d0 fs/read_write.c:599
       __do_sys_write fs/read_write.c:611 [inline]
       __se_sys_write fs/read_write.c:608 [inline]
       __x64_sys_write+0x73/0xb0 fs/read_write.c:608
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x458c29
      Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f293b44bc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000458c29
      RDX: 0000000000000014 RSI: 00000000200002c0 RDI: 0000000000000003
      RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f293b44c6d4
      R13: 00000000004c8623 R14: 00000000004ded68 R15: 00000000ffffffff
      
      The buggy address belongs to the page:
      page:ffffea00025aafc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
      flags: 0x1fffc0000000000()
      raw: 01fffc0000000000 0000000000000000 ffffffff025a0101 0000000000000000
      raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff888096abef80: 00 00 00 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 f2
       ffff888096abf000: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
      >ffff888096abf080: 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
                               ^
       ffff888096abf100: 00 00 00 00 f1 f1 f1 f1 00 00 f3 f3 00 00 00 00
       ffff888096abf180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      
      Fixes: ed0de45a ("ipv4: recompile ip options in ipv4_link_failure")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Stephen Suryaputra <ssuryaextr@gmail.com>
      Acked-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      2fe8d032
    • S
      x86/fpu: Don't export __kernel_fpu_{begin, end}() · f25ea67d
      Sebastian Andrzej Siewior 提交于
      commit 12209993 upstream.
      
      There is one user of __kernel_fpu_begin() and before invoking it,
      it invokes preempt_disable(). So it could invoke kernel_fpu_begin()
      right away. The 32bit version of arch_efi_call_virt_setup() and
      arch_efi_call_virt_teardown() does this already.
      
      The comment above *kernel_fpu*() claims that before invoking
      __kernel_fpu_begin() preemption should be disabled and that KVM is a
      good example of doing it. Well, KVM doesn't do that since commit
      
        f775b13e ("x86,kvm: move qemu/guest FPU switching out to vcpu_run")
      
      so it is not an example anymore.
      
      With EFI gone as the last user of __kernel_fpu_{begin|end}(), both can
      be made static and not exported anymore.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Reviewed-by: NRik van Riel <riel@surriel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Nicolai Stange <nstange@suse.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: kvm ML <kvm@vger.kernel.org>
      Cc: linux-efi <linux-efi@vger.kernel.org>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20181129150210.2k4mawt37ow6c2vq@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      f25ea67d
    • J
      mm: Fix warning in insert_pfn() · 80ded77d
      Jan Kara 提交于
      commit f2c57d91 upstream.
      
      In DAX mode a write pagefault can race with write(2) in the following
      way:
      
      CPU0                            CPU1
                                      write fault for mapped zero page (hole)
      dax_iomap_rw()
        iomap_apply()
          xfs_file_iomap_begin()
            - allocates blocks
          dax_iomap_actor()
            invalidate_inode_pages2_range()
              - invalidates radix tree entries in given range
                                      dax_iomap_pte_fault()
                                        grab_mapping_entry()
                                          - no entry found, creates empty
                                        ...
                                        xfs_file_iomap_begin()
                                          - finds already allocated block
                                        ...
                                        vmf_insert_mixed_mkwrite()
                                          - WARNs and does nothing because there
                                            is still zero page mapped in PTE
              unmap_mapping_pages()
      
      This race results in WARN_ON from insert_pfn() and is occasionally
      triggered by fstest generic/344. Note that the race is otherwise
      harmless as before write(2) on CPU0 is finished, we will invalidate page
      tables properly and thus user of mmap will see modified data from
      write(2) from that point on. So just restrict the warning only to the
      case when the PFN in PTE is not zero page.
      
      Link: http://lkml.kernel.org/r/20180824154542.26872-1-jack@suse.czSigned-off-by: NJan Kara <jack@suse.cz>
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      80ded77d
    • D
      x86/retpolines: Disable switch jump tables when retpolines are enabled · a3feaabc
      Daniel Borkmann 提交于
      commit a9d57ef1 upstream.
      
      Commit ce02ef06 ("x86, retpolines: Raise limit for generating indirect
      calls from switch-case") raised the limit under retpolines to 20 switch
      cases where gcc would only then start to emit jump tables, and therefore
      effectively disabling the emission of slow indirect calls in this area.
      
      After this has been brought to attention to gcc folks [0], Martin Liska
      has then fixed gcc to align with clang by avoiding to generate switch jump
      tables entirely under retpolines. This is taking effect in gcc starting
      from stable version 8.4.0. Given kernel supports compilation with older
      versions of gcc where the fix is not being available or backported anymore,
      we need to keep the extra KBUILD_CFLAGS around for some time and generally
      set the -fno-jump-tables to align with what more recent gcc is doing
      automatically today.
      
      More than 20 switch cases are not expected to be fast-path critical, but
      it would still be good to align with gcc behavior for versions < 8.4.0 in
      order to have consistency across supported gcc versions. vmlinux size is
      slightly growing by 0.27% for older gcc. This flag is only set to work
      around affected gcc, no change for clang.
      
        [0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952Suggested-by: NMartin Liska <mliska@suse.cz>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Jesper Dangaard Brouer <brouer@redhat.com>
      Cc: Björn Töpel<bjorn.topel@intel.com>
      Cc: Magnus Karlsson <magnus.karlsson@intel.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: David S. Miller <davem@davemloft.net>
      Link: https://lkml.kernel.org/r/20190325135620.14882-1-daniel@iogearbox.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      a3feaabc
    • D
      x86, retpolines: Raise limit for generating indirect calls from switch-case · ce8f0945
      Daniel Borkmann 提交于
      commit ce02ef06 upstream.
      
      From networking side, there are numerous attempts to get rid of indirect
      calls in fast-path wherever feasible in order to avoid the cost of
      retpolines, for example, just to name a few:
      
        * 283c16a2 ("indirect call wrappers: helpers to speed-up indirect calls of builtin")
        * aaa5d90b ("net: use indirect call wrappers at GRO network layer")
        * 028e0a47 ("net: use indirect call wrappers at GRO transport layer")
        * 356da6d0 ("dma-mapping: bypass indirect calls for dma-direct")
        * 09772d92 ("bpf: avoid retpoline for lookup/update/delete calls on maps")
        * 10870dd8 ("netfilter: nf_tables: add direct calls for all builtin expressions")
        [...]
      
      Recent work on XDP from Björn and Magnus additionally found that manually
      transforming the XDP return code switch statement with more than 5 cases
      into if-else combination would result in a considerable speedup in XDP
      layer due to avoidance of indirect calls in CONFIG_RETPOLINE enabled
      builds. On i40e driver with XDP prog attached, a 20-26% speedup has been
      observed [0]. Aside from XDP, there are many other places later in the
      networking stack's critical path with similar switch-case
      processing. Rather than fixing every XDP-enabled driver and locations in
      stack by hand, it would be good to instead raise the limit where gcc would
      emit expensive indirect calls from the switch under retpolines and stick
      with the default as-is in case of !retpoline configured kernels. This would
      also have the advantage that for archs where this is not necessary, we let
      compiler select the underlying target optimization for these constructs and
      avoid potential slow-downs by if-else hand-rewrite.
      
      In case of gcc, this setting is controlled by case-values-threshold which
      has an architecture global default that selects 4 or 5 (latter if target
      does not have a case insn that compares the bounds) where some arch back
      ends like arm64 or s390 override it with their own target hooks, for
      example, in gcc commit db7a90aa0de5 ("S/390: Disable prediction of indirect
      branches") the threshold pretty much disables jump tables by limit of 20
      under retpoline builds.  Comparing gcc's and clang's default code
      generation on x86-64 under O2 level with retpoline build results in the
      following outcome for 5 switch cases:
      
      * gcc with -mindirect-branch=thunk-inline -mindirect-branch-register:
      
        # gdb -batch -ex 'disassemble dispatch' ./c-switch
        Dump of assembler code for function dispatch:
         0x0000000000400be0 <+0>:     cmp    $0x4,%edi
         0x0000000000400be3 <+3>:     ja     0x400c35 <dispatch+85>
         0x0000000000400be5 <+5>:     lea    0x915f8(%rip),%rdx        # 0x4921e4
         0x0000000000400bec <+12>:    mov    %edi,%edi
         0x0000000000400bee <+14>:    movslq (%rdx,%rdi,4),%rax
         0x0000000000400bf2 <+18>:    add    %rdx,%rax
         0x0000000000400bf5 <+21>:    callq  0x400c01 <dispatch+33>
         0x0000000000400bfa <+26>:    pause
         0x0000000000400bfc <+28>:    lfence
         0x0000000000400bff <+31>:    jmp    0x400bfa <dispatch+26>
         0x0000000000400c01 <+33>:    mov    %rax,(%rsp)
         0x0000000000400c05 <+37>:    retq
         0x0000000000400c06 <+38>:    nopw   %cs:0x0(%rax,%rax,1)
         0x0000000000400c10 <+48>:    jmpq   0x400c90 <fn_3>
         0x0000000000400c15 <+53>:    nopl   (%rax)
         0x0000000000400c18 <+56>:    jmpq   0x400c70 <fn_2>
         0x0000000000400c1d <+61>:    nopl   (%rax)
         0x0000000000400c20 <+64>:    jmpq   0x400c50 <fn_1>
         0x0000000000400c25 <+69>:    nopl   (%rax)
         0x0000000000400c28 <+72>:    jmpq   0x400c40 <fn_0>
         0x0000000000400c2d <+77>:    nopl   (%rax)
         0x0000000000400c30 <+80>:    jmpq   0x400cb0 <fn_4>
         0x0000000000400c35 <+85>:    push   %rax
         0x0000000000400c36 <+86>:    callq  0x40dd80 <abort>
        End of assembler dump.
      
      * clang with -mretpoline emitting search tree:
      
        # gdb -batch -ex 'disassemble dispatch' ./c-switch
        Dump of assembler code for function dispatch:
         0x0000000000400b30 <+0>:     cmp    $0x1,%edi
         0x0000000000400b33 <+3>:     jle    0x400b44 <dispatch+20>
         0x0000000000400b35 <+5>:     cmp    $0x2,%edi
         0x0000000000400b38 <+8>:     je     0x400b4d <dispatch+29>
         0x0000000000400b3a <+10>:    cmp    $0x3,%edi
         0x0000000000400b3d <+13>:    jne    0x400b52 <dispatch+34>
         0x0000000000400b3f <+15>:    jmpq   0x400c50 <fn_3>
         0x0000000000400b44 <+20>:    test   %edi,%edi
         0x0000000000400b46 <+22>:    jne    0x400b5c <dispatch+44>
         0x0000000000400b48 <+24>:    jmpq   0x400c20 <fn_0>
         0x0000000000400b4d <+29>:    jmpq   0x400c40 <fn_2>
         0x0000000000400b52 <+34>:    cmp    $0x4,%edi
         0x0000000000400b55 <+37>:    jne    0x400b66 <dispatch+54>
         0x0000000000400b57 <+39>:    jmpq   0x400c60 <fn_4>
         0x0000000000400b5c <+44>:    cmp    $0x1,%edi
         0x0000000000400b5f <+47>:    jne    0x400b66 <dispatch+54>
         0x0000000000400b61 <+49>:    jmpq   0x400c30 <fn_1>
         0x0000000000400b66 <+54>:    push   %rax
         0x0000000000400b67 <+55>:    callq  0x40dd20 <abort>
        End of assembler dump.
      
        For sake of comparison, clang without -mretpoline:
      
        # gdb -batch -ex 'disassemble dispatch' ./c-switch
        Dump of assembler code for function dispatch:
         0x0000000000400b30 <+0>:	cmp    $0x4,%edi
         0x0000000000400b33 <+3>:	ja     0x400b57 <dispatch+39>
         0x0000000000400b35 <+5>:	mov    %edi,%eax
         0x0000000000400b37 <+7>:	jmpq   *0x492148(,%rax,8)
         0x0000000000400b3e <+14>:	jmpq   0x400bf0 <fn_0>
         0x0000000000400b43 <+19>:	jmpq   0x400c30 <fn_4>
         0x0000000000400b48 <+24>:	jmpq   0x400c10 <fn_2>
         0x0000000000400b4d <+29>:	jmpq   0x400c20 <fn_3>
         0x0000000000400b52 <+34>:	jmpq   0x400c00 <fn_1>
         0x0000000000400b57 <+39>:	push   %rax
         0x0000000000400b58 <+40>:	callq  0x40dcf0 <abort>
        End of assembler dump.
      
      Raising the cases to a high number (e.g. 100) will still result in similar
      code generation pattern with clang and gcc as above, in other words clang
      generally turns off jump table emission by having an extra expansion pass
      under retpoline build to turn indirectbr instructions from their IR into
      switch instructions as a built-in -mno-jump-table lowering of a switch (in
      this case, even if IR input already contained an indirect branch).
      
      For gcc, adding --param=case-values-threshold=20 as in similar fashion as
      s390 in order to raise the limit for x86 retpoline enabled builds results
      in a small vmlinux size increase of only 0.13% (before=18,027,528
      after=18,051,192). For clang this option is ignored due to i) not being
      needed as mentioned and ii) not having above cmdline
      parameter. Non-retpoline-enabled builds with gcc continue to use the
      default case-values-threshold setting, so nothing changes here.
      
      [0] https://lore.kernel.org/netdev/20190129095754.9390-1-bjorn.topel@gmail.com/
          and "The Path to DPDK Speeds for AF_XDP", LPC 2018, networking track:
        - http://vger.kernel.org/lpc_net2018_talks/lpc18_pres_af_xdp_perf-v3.pdf
        - http://vger.kernel.org/lpc_net2018_talks/lpc18_paper_af_xdp_perf-v2.pdfSigned-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NJesper Dangaard Brouer <brouer@redhat.com>
      Acked-by: NBjörn Töpel <bjorn.topel@intel.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: netdev@vger.kernel.org
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Magnus Karlsson <magnus.karlsson@intel.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Link: https://lkml.kernel.org/r/20190221221941.29358-1-daniel@iogearbox.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      ce8f0945
    • M
      aio: initialize kiocb private in case any filesystems expect it. · a3669a09
      Mike Marshall 提交于
      commit ec51f8ee1e63498e9f521ec0e5a6d04622bb2c67 upstream.
      
      A recent optimization had left private uninitialized.
      
      Fixes: 2bc4ca9bb600 ("aio: don't zero entire aio_kiocb aio_get_req()")
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NMike Marshall <hubcap@omnibond.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      a3669a09
    • J
      aio: don't zero entire aio_kiocb aio_get_req() · dc5b3ea4
      Jens Axboe 提交于
      commit 2bc4ca9bb600cbe36941da2b2a67189fc4302a04 upstream.
      
      It's 192 bytes, fairly substantial. Most items don't need to be cleared,
      especially not upfront. Clear the ones we do need to clear, and leave
      the other ones for setup when the iocb is prepared and submitted.
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      
      Conflicts:
        fs/aio.c
      [yyl: adjust context]
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      dc5b3ea4
    • J
      aio: use assigned completion handler · 1e8473d8
      Jens Axboe 提交于
      commit bc9bff61624ac33b7c95861abea1af24ee7a94fc upstream.
      
      We know this is a read/write request, but in preparation for
      having different kinds of those, ensure that we call the assigned
      handler instead of assuming it's aio_complete_rq().
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      1e8473d8
    • E
      rxrpc: fix race condition in rxrpc_input_packet() · ef48248d
      Eric Dumazet 提交于
      commit 032be5f1 upstream.
      
      After commit 5271953c ("rxrpc: Use the UDP encap_rcv hook"),
      rxrpc_input_packet() is directly called from lockless UDP receive
      path, under rcu_read_lock() protection.
      
      It must therefore use RCU rules :
      
      - udp_sk->sk_user_data can be cleared at any point in this function.
        rcu_dereference_sk_user_data() is what we need here.
      
      - Also, since sk_user_data might have been set in rxrpc_open_socket()
        we must observe a proper RCU grace period before kfree(local) in
        rxrpc_lookup_local()
      
      v4: @local can be NULL in xrpc_lookup_local() as reported by kbuild test robot <lkp@intel.com>
              and Julia Lawall <julia.lawall@lip6.fr>, thanks !
      
      v3,v2 : addressed David Howells feedback, thanks !
      
      syzbot reported :
      
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] PREEMPT SMP KASAN
      CPU: 0 PID: 19236 Comm: syz-executor703 Not tainted 5.1.0-rc6 #79
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:__lock_acquire+0xbef/0x3fb0 kernel/locking/lockdep.c:3573
      Code: 00 0f 85 a5 1f 00 00 48 81 c4 10 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 21 00 00 49 81 7d 00 20 54 9c 89 0f 84 cf f4
      RSP: 0018:ffff88809d7aef58 EFLAGS: 00010002
      RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 0000000000000026 RSI: 0000000000000000 RDI: 0000000000000001
      RBP: ffff88809d7af090 R08: 0000000000000001 R09: 0000000000000001
      R10: ffffed1015d05bc7 R11: ffff888089428600 R12: 0000000000000000
      R13: 0000000000000130 R14: 0000000000000001 R15: 0000000000000001
      FS:  00007f059044d700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000004b6040 CR3: 00000000955ca000 CR4: 00000000001406f0
      Call Trace:
       lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:4211
       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
       _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:152
       skb_queue_tail+0x26/0x150 net/core/skbuff.c:2972
       rxrpc_reject_packet net/rxrpc/input.c:1126 [inline]
       rxrpc_input_packet+0x4a0/0x5536 net/rxrpc/input.c:1414
       udp_queue_rcv_one_skb+0xaf2/0x1780 net/ipv4/udp.c:2011
       udp_queue_rcv_skb+0x128/0x730 net/ipv4/udp.c:2085
       udp_unicast_rcv_skb.isra.0+0xb9/0x360 net/ipv4/udp.c:2245
       __udp4_lib_rcv+0x701/0x2ca0 net/ipv4/udp.c:2301
       udp_rcv+0x22/0x30 net/ipv4/udp.c:2482
       ip_protocol_deliver_rcu+0x60/0x8f0 net/ipv4/ip_input.c:208
       ip_local_deliver_finish+0x23b/0x390 net/ipv4/ip_input.c:234
       NF_HOOK include/linux/netfilter.h:289 [inline]
       NF_HOOK include/linux/netfilter.h:283 [inline]
       ip_local_deliver+0x1e9/0x520 net/ipv4/ip_input.c:255
       dst_input include/net/dst.h:450 [inline]
       ip_rcv_finish+0x1e1/0x300 net/ipv4/ip_input.c:413
       NF_HOOK include/linux/netfilter.h:289 [inline]
       NF_HOOK include/linux/netfilter.h:283 [inline]
       ip_rcv+0xe8/0x3f0 net/ipv4/ip_input.c:523
       __netif_receive_skb_one_core+0x115/0x1a0 net/core/dev.c:4987
       __netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5099
       netif_receive_skb_internal+0x117/0x660 net/core/dev.c:5202
       napi_frags_finish net/core/dev.c:5769 [inline]
       napi_gro_frags+0xade/0xd10 net/core/dev.c:5843
       tun_get_user+0x2f24/0x3fb0 drivers/net/tun.c:1981
       tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2027
       call_write_iter include/linux/fs.h:1866 [inline]
       do_iter_readv_writev+0x5e1/0x8e0 fs/read_write.c:681
       do_iter_write fs/read_write.c:957 [inline]
       do_iter_write+0x184/0x610 fs/read_write.c:938
       vfs_writev+0x1b3/0x2f0 fs/read_write.c:1002
       do_writev+0x15e/0x370 fs/read_write.c:1037
       __do_sys_writev fs/read_write.c:1110 [inline]
       __se_sys_writev fs/read_write.c:1107 [inline]
       __x64_sys_writev+0x75/0xb0 fs/read_write.c:1107
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fixes: 5271953c ("rxrpc: Use the UDP encap_rcv hook")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      ef48248d
    • T
      net/rds: Check address length before reading address family · 8cd82c95
      Tetsuo Handa 提交于
      commit dd3ac9a6 upstream.
      
      syzbot is reporting uninitialized value at rds_connect() [1] and
      rds_bind() [2]. This is because syzbot is passing ulen == 0 whereas
      these functions expect that it is safe to access sockaddr->family field
      in order to determine minimal address length for validation.
      
      [1] https://syzkaller.appspot.com/bug?id=f4e61c010416c1e6f0fa3ffe247561b60a50ad71
      [2] https://syzkaller.appspot.com/bug?id=a4bf9e41b7e055c3823fdcd83e8c58ca7270e38fReported-by: Nsyzbot <syzbot+0049bebbf3042dbd2e8f@syzkaller.appspotmail.com>
      Reported-by: Nsyzbot <syzbot+915c9f99f3dbc4bd6cd1@syzkaller.appspotmail.com>
      Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      8cd82c95
    • Y
      net: netrom: Fix error cleanup path of nr_proto_init · 8c70adb4
      YueHaibing 提交于
      commit d3706566 upstream.
      
      Syzkaller report this:
      
      BUG: unable to handle kernel paging request at fffffbfff830524b
      PGD 237fe8067 P4D 237fe8067 PUD 237e64067 PMD 1c9716067 PTE 0
      Oops: 0000 [#1] SMP KASAN PTI
      CPU: 1 PID: 4465 Comm: syz-executor.0 Not tainted 5.0.0+ #5
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      RIP: 0010:__list_add_valid+0x21/0xe0 lib/list_debug.c:23
      Code: 8b 0c 24 e9 17 fd ff ff 90 55 48 89 fd 48 8d 7a 08 53 48 89 d3 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 48 83 ec 08 <80> 3c 02 00 0f 85 8b 00 00 00 48 8b 53 08 48 39 f2 75 35 48 89 f2
      RSP: 0018:ffff8881ea2278d0 EFLAGS: 00010282
      RAX: dffffc0000000000 RBX: ffffffffc1829250 RCX: 1ffff1103d444ef4
      RDX: 1ffffffff830524b RSI: ffffffff85659300 RDI: ffffffffc1829258
      RBP: ffffffffc1879250 R08: fffffbfff0acb269 R09: fffffbfff0acb269
      R10: ffff8881ea2278f0 R11: fffffbfff0acb268 R12: ffffffffc1829250
      R13: dffffc0000000000 R14: 0000000000000008 R15: ffffffffc187c830
      FS:  00007fe0361df700(0000) GS:ffff8881f7300000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: fffffbfff830524b CR3: 00000001eb39a001 CR4: 00000000007606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      PKRU: 55555554
      Call Trace:
       __list_add include/linux/list.h:60 [inline]
       list_add include/linux/list.h:79 [inline]
       proto_register+0x444/0x8f0 net/core/sock.c:3375
       nr_proto_init+0x73/0x4b3 [netrom]
       ? 0xffffffffc1628000
       ? 0xffffffffc1628000
       do_one_initcall+0xbc/0x47d init/main.c:887
       do_init_module+0x1b5/0x547 kernel/module.c:3456
       load_module+0x6405/0x8c10 kernel/module.c:3804
       __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
       do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x462e99
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007fe0361dec58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      RDX: 0000000000000000 RSI: 0000000020000100 RDI: 0000000000000003
      RBP: 00007fe0361dec70 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe0361df6bc
      R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
      Modules linked in: netrom(+) ax25 fcrypt pcbc af_alg arizona_ldo1 v4l2_common videodev media v4l2_dv_timings hdlc ide_cd_mod snd_soc_sigmadsp_regmap snd_soc_sigmadsp intel_spi_platform intel_spi mtd spi_nor snd_usbmidi_lib usbcore lcd ti_ads7950 hi6421_regulator snd_soc_kbl_rt5663_max98927 snd_soc_hdac_hdmi snd_hda_ext_core snd_hda_core snd_soc_rt5663 snd_soc_core snd_pcm_dmaengine snd_compress snd_soc_rl6231 mac80211 rtc_rc5t583 spi_slave_time leds_pwm hid_gt683r hid industrialio_triggered_buffer kfifo_buf industrialio ir_kbd_i2c rc_core led_class_flash dwc_xlgmac snd_ymfpci gameport snd_mpu401_uart snd_rawmidi snd_ac97_codec snd_pcm ac97_bus snd_opl3_lib snd_timer snd_seq_device snd_hwdep snd soundcore iptable_security iptable_raw iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr veth netdevsim vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon dummy team bonding vcan
       bridge stp llc ip6_gre gre ip6_tunnel tunnel6 tun joydev mousedev ppdev tpm kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ide_pci_generic piix aesni_intel aes_x86_64 crypto_simd cryptd glue_helper ide_core psmouse input_leds i2c_piix4 serio_raw intel_agp intel_gtt ata_generic agpgart pata_acpi parport_pc rtc_cmos parport floppy sch_fq_codel ip_tables x_tables sha1_ssse3 sha1_generic ipv6 [last unloaded: rxrpc]
      Dumping ftrace buffer:
         (ftrace buffer empty)
      CR2: fffffbfff830524b
      ---[ end trace 039ab24b305c4b19 ]---
      
      If nr_proto_init failed, it may forget to call proto_unregister,
      tiggering this issue.This patch rearrange code of nr_proto_init
      to avoid such issues.
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      8c70adb4
    • Y
      fm10k: Fix a potential NULL pointer dereference · 64de45a7
      Yue Haibing 提交于
      commit 01ca667133d019edc9f0a1f70a272447c84ec41f upstream.
      
      Syzkaller report this:
      
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN PTI
      CPU: 0 PID: 4378 Comm: syz-executor.0 Tainted: G         C        5.0.0+ #5
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      RIP: 0010:__lock_acquire+0x95b/0x3200 kernel/locking/lockdep.c:3573
      Code: 00 0f 85 28 1e 00 00 48 81 c4 08 01 00 00 5b 5d 41 5c 41 5d 41 5e 41 5f c3 4c 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 24 00 00 49 81 7d 00 e0 de 03 a6 41 bc 00 00
      RSP: 0018:ffff8881e3c07a40 EFLAGS: 00010002
      RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000080
      RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
      R10: ffff8881e3c07d98 R11: ffff8881c7f21f80 R12: 0000000000000001
      R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000001
      FS:  00007fce2252e700(0000) GS:ffff8881f2400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fffc7eb0228 CR3: 00000001e5bea002 CR4: 00000000007606f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      PKRU: 55555554
      Call Trace:
       lock_acquire+0xff/0x2c0 kernel/locking/lockdep.c:4211
       __mutex_lock_common kernel/locking/mutex.c:925 [inline]
       __mutex_lock+0xdf/0x1050 kernel/locking/mutex.c:1072
       drain_workqueue+0x24/0x3f0 kernel/workqueue.c:2934
       destroy_workqueue+0x23/0x630 kernel/workqueue.c:4319
       __do_sys_delete_module kernel/module.c:1018 [inline]
       __se_sys_delete_module kernel/module.c:961 [inline]
       __x64_sys_delete_module+0x30c/0x480 kernel/module.c:961
       do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x462e99
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007fce2252dc58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
      RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000140
      RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fce2252e6bc
      R13: 00000000004bcca9 R14: 00000000006f6b48 R15: 00000000ffffffff
      
      If alloc_workqueue fails, it should return -ENOMEM, otherwise may
      trigger this NULL pointer dereference while unloading drivers.
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Fixes: 0a38c17a ("fm10k: Remove create_workqueue")
      Signed-off-by: NYue Haibing <yuehaibing@huawei.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      64de45a7
    • F
      netfilter: ebtables: CONFIG_COMPAT: drop a bogus WARN_ON · 7ee99eb9
      Florian Westphal 提交于
      commit 7caa56f0 upstream.
      
      It means userspace gave us a ruleset where there is some other
      data after the ebtables target but before the beginning of the next rule.
      
      Fixes: 81e675c2 ("netfilter: ebtables: add CONFIG_COMPAT support")
      Reported-by: syzbot+659574e7bcc7f7eb4df7@syzkaller.appspotmail.com
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      7ee99eb9
    • T
      binder: fix handling of misaligned binder object · 3c239fad
      Todd Kjos 提交于
      commit 26528be6 upstream.
      
      Fixes crash found by syzbot:
      kernel BUG at drivers/android/binder_alloc.c:LINE! (2)
      
      Reported-and-tested-by: syzbot+55de1eb4975dec156d8f@syzkaller.appspotmail.com
      Signed-off-by: NTodd Kjos <tkjos@google.com>
      Reviewed-by: NJoel Fernandes (Google) <joel@joelfernandes.org>
      Cc: stable <stable@vger.kernel.org> # 5.0, 4.19, 4.14
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      3c239fad
    • T
      workqueue: Try to catch flush_work() without INIT_WORK(). · 0711f016
      Tetsuo Handa 提交于
      commit 4d43d395 upstream.
      
      syzbot found a flush_work() caller who forgot to call INIT_WORK()
      because that work_struct was allocated by kzalloc() [1]. But the message
      
        INFO: trying to register non-static key.
        the code is fine but needs lockdep annotation.
        turning off the locking correctness validator.
      
      by lock_map_acquire() is failing to tell that INIT_WORK() is missing.
      
      Since flush_work() without INIT_WORK() is a bug, and INIT_WORK() should
      set ->func field to non-zero, let's warn if ->func field is zero.
      
      [1] https://syzkaller.appspot.com/bug?id=a5954455fcfa51c29ca2ab55b203076337e1c770Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      0711f016
    • A
      intel_th: gth: Fix an off-by-one in output unassigning · 6849dcda
      Alexander Shishkin 提交于
      commit 91d3f8a6 upstream.
      
      Commit 9ed3f222 ("intel_th: Don't reference unassigned outputs")
      fixes a NULL dereference for all masters except the last one ("256+"),
      which keeps the stale pointer after the output driver had been unassigned.
      
      Fix the off-by-one.
      Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Fixes: 9ed3f222 ("intel_th: Don't reference unassigned outputs")
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      6849dcda
    • L
      slip: make slhc_free() silently accept an error pointer · d55a413c
      Linus Torvalds 提交于
      commit baf76f0c upstream.
      
      This way, slhc_free() accepts what slhc_init() returns, whether that is
      an error or not.
      
      In particular, the pattern in sl_alloc_bufs() is
      
              slcomp = slhc_init(16, 16);
              ...
              slhc_free(slcomp);
      
      for the error handling path, and rather than complicate that code, just
      make it ok to always free what was returned by the init function.
      
      That's what the code used to do before commit 4ab42d78 ("ppp, slip:
      Validate VJ compression slot parameters completely") when slhc_init()
      just returned NULL for the error case, with no actual indication of the
      details of the error.
      
      Reported-by: syzbot+45474c076a4927533d2e@syzkaller.appspotmail.com
      Fixes: 4ab42d78 ("ppp, slip: Validate VJ compression slot parameters completely")
      Acked-by: NBen Hutchings <ben@decadent.org.uk>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      d55a413c
    • M
      drm/vc4: Fix compilation error reported by kbuild test bot · 18568a58
      Maarten Lankhorst 提交于
      commit 462ce5d963f18b71c63f6b7730a35a2ee5273540 upstream.
      
      A pointer to crtc was missing, resulting in the following build error:
      drivers/gpu/drm/vc4/vc4_crtc.c:1045:44: sparse: sparse: incorrect type in argument 1 (different base types)
      drivers/gpu/drm/vc4/vc4_crtc.c:1045:44: sparse:    expected struct drm_crtc *crtc
      drivers/gpu/drm/vc4/vc4_crtc.c:1045:44: sparse:    got struct drm_crtc_state *state
      drivers/gpu/drm/vc4/vc4_crtc.c:1045:39: sparse: sparse: not enough arguments for function vc4_crtc_destroy_state
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Cc: Eric Anholt <eric@anholt.net>
      Link: https://patchwork.freedesktop.org/patch/msgid/2b6ed5e6-81b0-4276-8860-870b54ca3262@linux.intel.com
      Fixes: d08106796a78 ("drm/vc4: Fix memory leak during gpu reset.")
      Cc: <stable@vger.kernel.org> # v4.6+
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      18568a58
    • D
      Revert "drm/i915/fbdev: Actually configure untiled displays" · 1f4763df
      Dave Airlie 提交于
      commit 9fa24625 upstream.
      
      This reverts commit d179b88d.
      
      This commit is documented to break userspace X.org modesetting driver in certain configurations.
      
      The X.org modesetting userspace driver is broken. No fixes are available yet. In order for this patch to be applied it either needs a config option or a workaround developed.
      
      This has been reported a few times, saying it's a userspace problem is clearly against the regression rules.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109806Signed-off-by: NDave Airlie <airlied@redhat.com>
      Cc: <stable@vger.kernel.org> # v3.19+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      1f4763df
    • M
      drm/vc4: Fix memory leak during gpu reset. · 352f9641
      Maarten Lankhorst 提交于
      commit d08106796a78a4273e39e1bbdf538dc4334b2635 upstream.
      
      __drm_atomic_helper_crtc_destroy_state does not free memory, it only
      cleans it up. Fix this by calling the functions own destroy function.
      
      Fixes: 6d6e5003 ("drm/vc4: Allocate the right amount of space for boot-time CRTC state.")
      Cc: Eric Anholt <eric@anholt.net>
      Cc: <stable@vger.kernel.org> # v4.6+
      Reviewed-by: NEric Anholt <eric@anholt.net>
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190301125627.7285-2-maarten.lankhorst@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      352f9641
    • M
      powerpc/mm/radix: Make Radix require HUGETLB_PAGE · ef61a070
      Michael Ellerman 提交于
      commit 8adddf34 upstream.
      
      Joel reported weird crashes using skiroot_defconfig, in his case we
      jumped into an NX page:
      
        kernel tried to execute exec-protected page (c000000002bff4f0) - exploit attempt? (uid: 0)
        BUG: Unable to handle kernel instruction fetch
        Faulting instruction address: 0xc000000002bff4f0
      
      Looking at the disassembly, we had simply branched to that address:
      
        c000000000c001bc  49fff335    bl     c000000002bff4f0
      
      But that didn't match the original kernel image:
      
        c000000000c001bc  4bfff335    bl     c000000000bff4f0 <kobject_get+0x8>
      
      When STRICT_KERNEL_RWX is enabled, and we're using the radix MMU, we
      call radix__change_memory_range() late in boot to change page
      protections. We do that both to mark rodata read only and also to mark
      init text no-execute. That involves walking the kernel page tables,
      and clearing _PAGE_WRITE or _PAGE_EXEC respectively.
      
      With radix we may use hugepages for the linear mapping, so the code in
      radix__change_memory_range() uses eg. pmd_huge() to test if it has
      found a huge mapping, and if so it stops the page table walk and
      changes the PMD permissions.
      
      However if the kernel is built without HUGETLBFS support, pmd_huge()
      is just a #define that always returns 0. That causes the code in
      radix__change_memory_range() to incorrectly interpret the PMD value as
      a pointer to a PTE page rather than as a PTE at the PMD level.
      
      We can see this using `dv` in xmon which also uses pmd_huge():
      
        0:mon> dv c000000000000000
        pgd  @ 0xc000000001740000
        pgdp @ 0xc000000001740000 = 0x80000000ffffb009
        pudp @ 0xc0000000ffffb000 = 0x80000000ffffa009
        pmdp @ 0xc0000000ffffa000 = 0xc00000000000018f   <- this is a PTE
        ptep @ 0xc000000000000100 = 0xa64bb17da64ab07d   <- kernel text
      
      The end result is we treat the value at 0xc000000000000100 as a PTE
      and clear _PAGE_WRITE or _PAGE_EXEC, potentially corrupting the code
      at that address.
      
      In Joel's specific case we cleared the sign bit in the offset of the
      branch, causing a backward branch to turn into a forward branch which
      caused us to branch into a non-executable page. However the exact
      nature of the crash depends on kernel version, compiler version, and
      other factors.
      
      We need to fix radix__change_memory_range() to not use accessors that
      depend on HUGETLBFS, but we also have radix memory hotplug code that
      uses pmd_huge() etc that will also need fixing. So for now just
      disallow the broken combination of Radix with HUGETLBFS disabled.
      
      The only defconfig we have that is affected is skiroot_defconfig, so
      turn on HUGETLBFS there so that it still gets Radix.
      
      Fixes: 566ca99a ("powerpc/mm/radix: Add dummy radix_enabled()")
      Cc: stable@vger.kernel.org # v4.7+
      Reported-by: NJoel Stanley <joel@jms.id.au>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      ef61a070
    • A
      ARM: 8857/1: efi: enable CP15 DMB instructions before cleaning the cache · 4da84087
      Ard Biesheuvel 提交于
      commit e17b1af96b2afc38e684aa2f1033387e2ed10029 upstream.
      
      The EFI stub is entered with the caches and MMU enabled by the
      firmware, and once the stub is ready to hand over to the decompressor,
      we clean and disable the caches.
      
      The cache clean routines use CP15 barrier instructions, which can be
      disabled via SCTLR. Normally, when using the provided cache handling
      routines to enable the caches and MMU, this bit is enabled as well.
      However, but since we entered the stub with the caches already enabled,
      this routine is not executed before we call the cache clean routines,
      resulting in undefined instruction exceptions if the firmware never
      enabled this bit.
      
      So set the bit explicitly in the EFI entry code, but do so in a way that
      guarantees that the resulting code can still run on v6 cores as well
      (which are guaranteed to have CP15 barriers enabled)
      
      Cc: <stable@vger.kernel.org> # v4.9+
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      4da84087
    • A
      dmaengine: sh: rcar-dmac: Fix glitch in dmaengine_tx_status · ff9f7bc1
      Achim Dahlhoff 提交于
      commit 6e7da747 upstream.
      
      The tx_status poll in the rcar_dmac driver reads the status register
      which indicates which chunk is busy (DMACHCRB). Afterwards the point
      inside the chunk is read from DMATCRB. It is possible that the chunk
      has changed between the two reads. The result is a non-monotonous
      increase of the residue. Fix this by introducing a 'safe read' logic.
      
      Fixes: 73a47bd0 ("dmaengine: rcar-dmac: use TCRB instead of TCR for residue")
      Signed-off-by: NAchim Dahlhoff <Achim.Dahlhoff@de.bosch.com>
      Signed-off-by: NDirk Behme <dirk.behme@de.bosch.com>
      Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Cc: <stable@vger.kernel.org> # v4.16+
      Signed-off-by: NVinod Koul <vkoul@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      ff9f7bc1
    • D
      dmaengine: sh: rcar-dmac: With cyclic DMA residue 0 is valid · 1458696d
      Dirk Behme 提交于
      commit 907bd68a upstream.
      
      Having a cyclic DMA, a residue 0 is not an indication of a completed
      DMA. In case of cyclic DMA make sure that dma_set_residue() is called
      and with this a residue of 0 is forwarded correctly to the caller.
      
      Fixes: 3544d287 ("dmaengine: rcar-dmac: use result of updated get_residue in tx_status")
      Signed-off-by: NDirk Behme <dirk.behme@de.bosch.com>
      Signed-off-by: NAchim Dahlhoff <Achim.Dahlhoff@de.bosch.com>
      Signed-off-by: NHiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
      Signed-off-by: NYao Lihua <ylhuajnu@outlook.com>
      Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: <stable@vger.kernel.org> # v4.8+
      Signed-off-by: NVinod Koul <vkoul@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      1458696d
    • L
      Input: synaptics-rmi4 - write config register values to the right offset · 1baee0e2
      Lucas Stach 提交于
      commit 3a349763 upstream.
      
      Currently any changed config register values don't take effect, as the
      function to write them back is called with the wrong register offset.
      
      Fixes: ff8f8370 (Input: synaptics-rmi4 - add support for 2D
                           sensors and F11)
      Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
      Reviewed-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      1baee0e2
    • H
      perf/x86/intel: Update KBL Package C-state events to also include PC8/PC9/PC10 counters · be78bebf
      Harry Pan 提交于
      commit 82c99f7a upstream.
      
      Kaby Lake (and Coffee Lake) has PC8/PC9/PC10 residency counters.
      
      This patch updates the list of Kaby/Coffee Lake PMU event counters
      from the snb_cstates[] list of events to the hswult_cstates[]
      list of events, which keeps all previously supported events and
      also adds the PKG_C8, PKG_C9 and PKG_C10 residency counters.
      
      This allows user space tools to profile them through the perf interface.
      Signed-off-by: NHarry Pan <harry.pan@intel.com>
      Cc: <stable@vger.kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: gs0622@gmail.com
      Link: http://lkml.kernel.org/r/20190424145033.1924-1-harry.pan@intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      be78bebf
    • N
      sunrpc: don't mark uninitialised items as VALID. · 8812b223
      NeilBrown 提交于
      commit d58431ea upstream.
      
      A recent commit added a call to cache_fresh_locked()
      when an expired item was found.
      The call sets the CACHE_VALID flag, so it is important
      that the item actually is valid.
      There are two ways it could be valid:
      1/ If ->update has been called to fill in relevant content
      2/ if CACHE_NEGATIVE is set, to say that content doesn't exist.
      
      An expired item that is waiting for an update will be neither.
      Setting CACHE_VALID will mean that a subsequent call to cache_put()
      will be likely to dereference uninitialised pointers.
      
      So we must make sure the item is valid, and we already have code to do
      that in try_to_negate_entry().  This takes the hash lock and so cannot
      be used directly, so take out the two lines that we need and use them.
      
      Now cache_fresh_locked() is certain to be called only on
      a valid item.
      
      Cc: stable@kernel.org # 2.6.35
      Fixes: 4ecd55ea ("sunrpc: fix cache_head leak due to queued request")
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      8812b223
    • T
      nfsd: Don't release the callback slot unless it was actually held · e0ec73ad
      Trond Myklebust 提交于
      commit e6abc8ca upstream.
      
      If there are multiple callbacks queued, waiting for the callback
      slot when the callback gets shut down, then they all currently
      end up acting as if they hold the slot, and call
      nfsd4_cb_sequence_done() resulting in interesting side-effects.
      
      In addition, the 'retry_nowait' path in nfsd4_cb_sequence_done()
      causes a loop back to nfsd4_cb_prepare() without first freeing the
      slot, which causes a deadlock when nfsd41_cb_get_slot() gets called
      a second time.
      
      This patch therefore adds a boolean to track whether or not the
      callback did pick up the slot, so that it can do the right thing
      in these 2 cases.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      e0ec73ad
    • Y
      ceph: fix ci->i_head_snapc leak · ab5a5c78
      Yan, Zheng 提交于
      commit 37659182bff1eeaaeadcfc8f853c6d2b6dbc3f47 upstream.
      
      We missed two places that i_wrbuffer_ref_head, i_wr_ref, i_dirty_caps
      and i_flushing_caps may change. When they are all zeros, we should free
      i_head_snapc.
      
      Cc: stable@vger.kernel.org
      Link: https://tracker.ceph.com/issues/38224Reported-and-tested-by: NLuis Henriques <lhenriques@suse.com>
      Signed-off-by: N"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      ab5a5c78
    • J
      ceph: ensure d_name stability in ceph_dentry_hash() · d2f65a9f
      Jeff Layton 提交于
      commit 76a495d666e5043ffc315695f8241f5e94a98849 upstream.
      
      Take the d_lock here to ensure that d_name doesn't change.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJeff Layton <jlayton@kernel.org>
      Reviewed-by: N"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      d2f65a9f
    • J
      ceph: only use d_name directly when parent is locked · 800e027d
      Jeff Layton 提交于
      commit 1bcb344086f3ecf8d6705f6d708441baa823beb3 upstream.
      
      Ben reported tripping the BUG_ON in create_request_message during some
      performance testing. Analysis of the vmcore showed that the length of
      the r_dentry->d_name string changed after we allocated the buffer, but
      before we encoded it.
      
      build_dentry_path returns pointers to d_name in the common case of
      non-snapped dentries, but this optimization isn't safe unless the parent
      directory is locked. When it isn't, have the code make a copy of the
      d_name while holding the d_lock.
      
      Cc: stable@vger.kernel.org
      Reported-by: NBen England <bengland@redhat.com>
      Signed-off-by: NJeff Layton <jlayton@kernel.org>
      Reviewed-by: N"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      800e027d
    • X
      sched/numa: Fix a possible divide-by-zero · 84bca3a7
      Xie XiuQi 提交于
      commit a860fa7b upstream.
      
      sched_clock_cpu() may not be consistent between CPUs. If a task
      migrates to another CPU, then se.exec_start is set to that CPU's
      rq_clock_task() by update_stats_curr_start(). Specifically, the new
      value might be before the old value due to clock skew.
      
      So then if in numa_get_avg_runtime() the expression:
      
        'now - p->last_task_numa_placement'
      
      ends up as -1, then the divider '*period + 1' in task_numa_placement()
      is 0 and things go bang. Similar to update_curr(), check if time goes
      backwards to avoid this.
      
      [ peterz: Wrote new changelog. ]
      [ mingo: Tweaked the code comment. ]
      Signed-off-by: NXie XiuQi <xiexiuqi@huawei.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: cj.chengjian@huawei.com
      Cc: <stable@vger.kernel.org>
      Link: http://lkml.kernel.org/r/20190425080016.GX11158@hirez.programming.kicks-ass.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      
      Conflicts:
        kernel/sched/fair.c
      [yyl: adjust context]
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      84bca3a7
    • J
      RDMA/mlx5: Do not allow the user to write to the clock page · d52d30ce
      Jason Gunthorpe 提交于
      commit c660133c339f9ab684fdf568c0d51b9ae5e86002 upstream.
      
      The intent of this VMA was to be read-only from user space, but the
      VM_MAYWRITE masking was missed, so mprotect could make it writable.
      
      Cc: stable@vger.kernel.org
      Fixes: 5c99eaec ("IB/mlx5: Mmap the HCA's clock info to user-space")
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Reviewed-by: NHaggai Eran <haggaie@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      d52d30ce
    • J
      IB/rdmavt: Fix frwr memory registration · 8f90bc8c
      Josh Collier 提交于
      commit 7c39f7f6 upstream.
      
      Current implementation was not properly handling frwr memory
      registrations. This was uncovered by commit 27f26cec761das ("xprtrdma:
      Plant XID in on-the-wire RDMA offset (FRWR)") in which xprtrdma, which is
      used for NFS over RDMA, started failing as it was the first ULP to modify
      the ib_mr iova resulting in the NFS server getting REMOTE ACCESS ERROR
      when attempting to perform RDMA Writes to the client.
      
      The fix is to properly capture the true iova, offset, and length in the
      call to ib_map_mr_sg, and then update the iova when processing the
      IB_WR_REG_MEM on the send queue.
      
      Fixes: a41081aa ("IB/rdmavt: Add support for ib_map_mr_sg")
      Cc: stable@vger.kernel.org
      Reviewed-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Reviewed-by: NDennis Dalessandro <dennis.dalessandro@intel.com>
      Reviewed-by: NMichael J. Ruhl <michael.j.ruhl@intel.com>
      Signed-off-by: NJosh Collier <josh.d.collier@intel.com>
      Signed-off-by: NDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      8f90bc8c
    • P
      trace: Fix preempt_enable_no_resched() abuse · 1402e48c
      Peter Zijlstra 提交于
      commit d6097c9e upstream.
      
      Unless the very next line is schedule(), or implies it, one must not use
      preempt_enable_no_resched(). It can cause a preemption to go missing and
      thereby cause arbitrary delays, breaking the PREEMPT=y invariant.
      
      Link: http://lkml.kernel.org/r/20190423200318.GY14281@hirez.programming.kicks-ass.net
      
      Cc: Waiman Long <longman@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: the arch/x86 maintainers <x86@kernel.org>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: huang ying <huang.ying.caritas@gmail.com>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: stable@vger.kernel.org
      Fixes: 2c2d7329 ("tracing/ftrace: use preempt_enable_no_resched_notrace in ring_buffer_time_stamp()")
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      1402e48c
    • A
      MIPS: scall64-o32: Fix indirect syscall number load · 7f20c2d1
      Aurelien Jarno 提交于
      commit 79b4a9cf upstream.
      
      Commit 4c21b8fd (MIPS: seccomp: Handle indirect system calls (o32))
      added indirect syscall detection for O32 processes running on MIPS64,
      but it did not work correctly for big endian kernel/processes. The
      reason is that the syscall number is loaded from ARG1 using the lw
      instruction while this is a 64-bit value, so zero is loaded instead of
      the syscall number.
      
      Fix the code by using the ld instruction instead. When running a 32-bit
      processes on a 64 bit CPU, the values are properly sign-extended, so it
      ensures the value passed to syscall_trace_enter is correct.
      
      Recent systemd versions with seccomp enabled whitelist the getpid
      syscall for their internal  processes (e.g. systemd-journald), but call
      it through syscall(SYS_getpid). This fix therefore allows O32 big endian
      systems with a 64-bit kernel to run recent systemd versions.
      Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
      Cc: <stable@vger.kernel.org> # v3.15+
      Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      7f20c2d1
    • Y
      lib/Kconfig.debug: fix build error without CONFIG_BLOCK · f8374cbd
      YueHaibing 提交于
      commit ae3d6a323347940f0548bbb4b17f0bb2e9164169 upstream.
      
      If CONFIG_TEST_KMOD is set to M, while CONFIG_BLOCK is not set, XFS and
      BTRFS can not be compiled successly.
      
      Link: http://lkml.kernel.org/r/20190410075434.35220-1-yuehaibing@huawei.com
      Fixes: d9c6a72d ("kmod: add test driver to stress test the module loader")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Reviewed-by: NKees Cook <keescook@chromium.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Joe Lawrence <joe.lawrence@redhat.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Luis Chamberlain <mcgrof@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      f8374cbd
新手
引导
客服 返回
顶部