1. 26 4月, 2019 6 次提交
    • E
      ext4: fix reserved cluster accounting at page invalidation time · 4fea2e24
      Eric Whitney 提交于
      commit f456767d3391e9f7d9d25a2e7241d75676dc19da upstream.
      
      Add new code to count canceled pending cluster reservations on bigalloc
      file systems and to reduce the cluster reservation count on all file
      systems using delayed allocation.  This replaces old code in
      ext4_da_page_release_reservations that was incorrect.
      Signed-off-by: NEric Whitney <enwlinux@gmail.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: NJoseph Qi <joseph.qi@linux.alibaba.com>
      Reviewed-by: NJiufei Xue <jiufei.xue@linux.alibaba.com>
      4fea2e24
    • E
      ext4: adjust reserved cluster count when removing extents · eb6f0dde
      Eric Whitney 提交于
      commit 9fe671496b6c286f9033aedfc1718d67721da0ae upstream.
      
      Modify ext4_ext_remove_space() and the code it calls to correct the
      reserved cluster count for pending reservations (delayed allocated
      clusters shared with allocated blocks) when a block range is removed
      from the extent tree.  Pending reservations may be found for the clusters
      at the ends of written or unwritten extents when a block range is removed.
      If a physical cluster at the end of an extent is freed, it's necessary
      to increment the reserved cluster count to maintain correct accounting
      if the corresponding logical cluster is shared with at least one
      delayed and unwritten extent as found in the extents status tree.
      
      Add a new function, ext4_rereserve_cluster(), to reapply a reservation
      on a delayed allocated cluster sharing blocks with a freed allocated
      cluster.  To avoid ENOSPC on reservation, a flag is applied to
      ext4_free_blocks() to briefly defer updating the freeclusters counter
      when an allocated cluster is freed.  This prevents another thread
      from allocating the freed block before the reservation can be reapplied.
      
      Redefine the partial cluster object as a struct to carry more state
      information and to clarify the code using it.
      
      Adjust the conditional code structure in ext4_ext_remove_space to
      reduce the indentation level in the main body of the code to improve
      readability.
      Signed-off-by: NEric Whitney <enwlinux@gmail.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: NJoseph Qi <joseph.qi@linux.alibaba.com>
      Reviewed-by: NJiufei Xue <jiufei.xue@linux.alibaba.com>
      eb6f0dde
    • E
      ext4: reduce reserved cluster count by number of allocated clusters · b9d79899
      Eric Whitney 提交于
      commit b6bf9171ef5c37b66d446378ba63af5339a56a97 upstream.
      
      Ext4 does not always reduce the reserved cluster count by the number
      of clusters allocated when mapping a delayed extent.  It sometimes
      adds back one or more clusters after allocation if delalloc blocks
      adjacent to the range allocated by ext4_ext_map_blocks() share the
      clusters newly allocated for that range.  However, this overcounts
      the number of clusters needed to satisfy future mapping requests
      (holding one or more reservations for clusters that have already been
      allocated) and premature ENOSPC and quota failures, etc., result.
      
      Ext4 also does not reduce the reserved cluster count when allocating
      clusters for non-delayed allocated writes that have previously been
      reserved for delayed writes.  This also results in overcounts.
      
      To make it possible to handle reserved cluster accounting for
      fallocated regions in the same manner as used for other non-delayed
      writes, do the reserved cluster accounting for them at the time of
      allocation.  In the current code, this is only done later when a
      delayed extent sharing the fallocated region is finally mapped.
      
      Address comment correcting handling of unsigned long long constant
      from Jan Kara's review of RFC version of this patch.
      Signed-off-by: NEric Whitney <enwlinux@gmail.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: NJoseph Qi <joseph.qi@linux.alibaba.com>
      Reviewed-by: NJiufei Xue <jiufei.xue@linux.alibaba.com>
      b9d79899
    • E
      ext4: fix reserved cluster accounting at delayed write time · d376c9a0
      Eric Whitney 提交于
      commit 0b02f4c0d6d9e2c611dfbdd4317193e9dca740e6 upstream.
      
      The code in ext4_da_map_blocks sometimes reserves space for more
      delayed allocated clusters than it should, resulting in premature
      ENOSPC, exceeded quota, and inaccurate free space reporting.
      
      Fix this by checking for written and unwritten blocks shared in the
      same cluster with the newly delayed allocated block.  A cluster
      reservation should not be made for a cluster for which physical space
      has already been allocated.
      Signed-off-by: NEric Whitney <enwlinux@gmail.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: NJoseph Qi <joseph.qi@linux.alibaba.com>
      Reviewed-by: NJiufei Xue <jiufei.xue@linux.alibaba.com>
      d376c9a0
    • E
      ext4: add new pending reservation mechanism · 0e5179b2
      Eric Whitney 提交于
      commit 1dc0aa46e74a3366e12f426b7caaca477853e9c3 upstream.
      
      Add new pending reservation mechanism to help manage reserved cluster
      accounting.  Its primary function is to avoid the need to read extents
      from the disk when invalidating pages as a result of a truncate, punch
      hole, or collapse range operation.
      Signed-off-by: NEric Whitney <enwlinux@gmail.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: NJoseph Qi <joseph.qi@linux.alibaba.com>
      Reviewed-by: NJiufei Xue <jiufei.xue@linux.alibaba.com>
      0e5179b2
    • E
      ext4: generalize extents status tree search functions · 6fb42841
      Eric Whitney 提交于
      commit ad431025aecda85d3ebef5e4a3aca5c1c681d0c7 upstream.
      
      Ext4 contains a few functions that are used to search for delayed
      extents or blocks in the extents status tree.  Rather than duplicate
      code to add new functions to search for extents with different status
      values, such as written or a combination of delayed and unwritten,
      generalize the existing code to search for caller-specified extents
      status values.  Also, move this code into extents_status.c where it
      is better associated with the data structures it operates upon, and
      where it can be more readily used to implement new extents status tree
      functions that might want a broader scope for i_es_lock.
      
      Three missing static specifiers in RFC version of patch reported and
      fixed by Fengguang Wu <fengguang.wu@intel.com>.
      Signed-off-by: NEric Whitney <enwlinux@gmail.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: NJoseph Qi <joseph.qi@linux.alibaba.com>
      Reviewed-by: NJiufei Xue <jiufei.xue@linux.alibaba.com>
      6fb42841
  2. 20 4月, 2019 34 次提交
    • G
      Linux 4.19.36 · c98875d9
      Greg Kroah-Hartman 提交于
      c98875d9
    • A
      appletalk: Fix compile regression · 0c00f71e
      Arnd Bergmann 提交于
      [ Upstream commit 27da0d2ef998e222a876c0cec72aa7829a626266 ]
      
      A bugfix just broke compilation of appletalk when CONFIG_SYSCTL
      is disabled:
      
      In file included from net/appletalk/ddp.c:65:
      net/appletalk/ddp.c: In function 'atalk_init':
      include/linux/atalk.h:164:34: error: expected expression before 'do'
       #define atalk_register_sysctl()  do { } while(0)
                                        ^~
      net/appletalk/ddp.c:1934:7: note: in expansion of macro 'atalk_register_sysctl'
        rc = atalk_register_sysctl();
      
      This is easier to avoid by using conventional inline functions
      as stubs rather than macros. The header already has inline
      functions for other purposes, so I'm changing over all the
      macros for consistency.
      
      Fixes: 6377f787aeb9 ("appletalk: Fix use-after-free in atalk_proc_exit")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0c00f71e
    • K
      mm: hide incomplete nr_indirectly_reclaimable in sysfs · 9e91db59
      Konstantin Khlebnikov 提交于
      In upstream branch this fixed by commit b29940c1abd7 ("mm: rename and
      change semantics of nr_indirectly_reclaimable_bytes").
      
      This fixes /sys/devices/system/node/node*/vmstat format:
      
      ...
      nr_dirtied 6613155
      nr_written 5796802
       11089216
      ...
      
      Cc: <stable@vger.kernel.org> # 4.19.y
      Fixes: 7aaf7727 ("mm: don't show nr_indirectly_reclaimable in /proc/vmstat")
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9e91db59
    • R
      mm: hide incomplete nr_indirectly_reclaimable in /proc/zoneinfo · d49dea54
      Roman Gushchin 提交于
      [fixed differently upstream, this is a work-around to resolve it for 4.19.y]
      
      Yongqin reported that /proc/zoneinfo format is broken in 4.14
      due to commit 7aaf7727 ("mm: don't show nr_indirectly_reclaimable
      in /proc/vmstat")
      
      Node 0, zone      DMA
        per-node stats
            nr_inactive_anon 403
            nr_active_anon 89123
            nr_inactive_file 128887
            nr_active_file 47377
            nr_unevictable 2053
            nr_slab_reclaimable 7510
            nr_slab_unreclaimable 10775
            nr_isolated_anon 0
            nr_isolated_file 0
            <...>
            nr_vmscan_write 0
            nr_vmscan_immediate_reclaim 0
            nr_dirtied   6022
            nr_written   5985
                         74240
            ^^^^^^^^^^
        pages free     131656
      
      The problem is caused by the nr_indirectly_reclaimable counter,
      which is hidden from the /proc/vmstat, but not from the
      /proc/zoneinfo. Let's fix this inconsistency and hide the
      counter from /proc/zoneinfo exactly as from /proc/vmstat.
      
      BTW, in 4.19+ the counter has been renamed and exported by
      the commit b29940c1abd7 ("mm: rename and change semantics of
      nr_indirectly_reclaimable_bytes"), so there is no such a problem
      anymore.
      
      Cc: <stable@vger.kernel.org> # 4.14.x-4.18.x
      Fixes: 7aaf7727 ("mm: don't show nr_indirectly_reclaimable in /proc/vmstat")
      Reported-by: NYongqin Liu <yongqin.liu@linaro.org>
      Signed-off-by: NRoman Gushchin <guro@fb.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d49dea54
    • K
      IB/hfi1: Failed to drain send queue when QP is put into error state · 7a462679
      Kaike Wan 提交于
      commit 662d66466637862ef955f7f6e78a286d8cf0ebef upstream.
      
      When a QP is put into error state, all pending requests in the send work
      queue should be drained. The following sequence of events could lead to a
      failure, causing a request to hang:
      
      (1) The QP builds a packet and tries to send through SDMA engine.
          However, PIO engine is still busy. Consequently, this packet is put on
          the QP's tx list and the QP is put on the PIO waiting list. The field
          qp->s_flags is set with HFI1_S_WAIT_PIO_DRAIN;
      
      (2) The QP is put into error state by the user application and
          notify_error_qp() is called, which removes the QP from the PIO waiting
          list and the packet from the QP's tx list. In addition, qp->s_flags is
          cleared of RVT_S_ANY_WAIT_IO bits, which does not include
          HFI1_S_WAIT_PIO_DRAIN bit;
      
      (3) The hfi1_schdule_send() function is called to drain the QP's send
          queue. Subsequently, hfi1_do_send() is called. Since the flag bit
          HFI1_S_WAIT_PIO_DRAIN is set in qp->s_flags, hfi1_send_ok() fails.  As
          a result, hfi1_do_send() bails out without draining any request from
          the send queue;
      
      (4) The PIO engine completes the sending and tries to wake up any QP on
          its waiting list. But the QP has been removed from the PIO waiting
          list and therefore is kept in sleep forever.
      
      The fix is to clear qp->s_flags of HFI1_S_ANY_WAIT_IO bits in step (2).
      HFI1_S_ANY_WAIT_IO includes RVT_S_ANY_WAIT_IO and HFI1_S_WAIT_PIO_DRAIN.
      
      Fixes: 2e2ba09e ("IB/rdmavt, IB/hfi1: Create device dependent s_flags")
      Cc: <stable@vger.kernel.org> # 4.19.x+
      Reviewed-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Reviewed-by: NAlex Estrin <alex.estrin@intel.com>
      Signed-off-by: NKaike Wan <kaike.wan@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>
      
      7a462679
    • D
      bpf: fix use after free in bpf_evict_inode · e8eef7ad
      Daniel Borkmann 提交于
      [ Upstream commit 1da6c4d9140cb7c13e87667dc4e1488d6c8fc10f ]
      
      syzkaller was able to generate the following UAF in bpf:
      
        BUG: KASAN: use-after-free in lookup_last fs/namei.c:2269 [inline]
        BUG: KASAN: use-after-free in path_lookupat.isra.43+0x9f8/0xc00 fs/namei.c:2318
        Read of size 1 at addr ffff8801c4865c47 by task syz-executor2/9423
      
        CPU: 0 PID: 9423 Comm: syz-executor2 Not tainted 4.20.0-rc1-next-20181109+
        #110
        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+0x244/0x39d lib/dump_stack.c:113
          print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
          kasan_report_error mm/kasan/report.c:354 [inline]
          kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
          __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
          lookup_last fs/namei.c:2269 [inline]
          path_lookupat.isra.43+0x9f8/0xc00 fs/namei.c:2318
          filename_lookup+0x26a/0x520 fs/namei.c:2348
          user_path_at_empty+0x40/0x50 fs/namei.c:2608
          user_path include/linux/namei.h:62 [inline]
          do_mount+0x180/0x1ff0 fs/namespace.c:2980
          ksys_mount+0x12d/0x140 fs/namespace.c:3258
          __do_sys_mount fs/namespace.c:3272 [inline]
          __se_sys_mount fs/namespace.c:3269 [inline]
          __x64_sys_mount+0xbe/0x150 fs/namespace.c:3269
          do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
          entry_SYSCALL_64_after_hwframe+0x49/0xbe
        RIP: 0033:0x457569
        Code: fd b3 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 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
        RSP: 002b:00007fde6ed96c78 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
        RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000457569
        RDX: 0000000020000040 RSI: 0000000020000000 RDI: 0000000000000000
        RBP: 000000000072bf00 R08: 0000000020000340 R09: 0000000000000000
        R10: 0000000000200000 R11: 0000000000000246 R12: 00007fde6ed976d4
        R13: 00000000004c2c24 R14: 00000000004d4990 R15: 00000000ffffffff
      
        Allocated by task 9424:
          save_stack+0x43/0xd0 mm/kasan/kasan.c:448
          set_track mm/kasan/kasan.c:460 [inline]
          kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
          __do_kmalloc mm/slab.c:3722 [inline]
          __kmalloc_track_caller+0x157/0x760 mm/slab.c:3737
          kstrdup+0x39/0x70 mm/util.c:49
          bpf_symlink+0x26/0x140 kernel/bpf/inode.c:356
          vfs_symlink+0x37a/0x5d0 fs/namei.c:4127
          do_symlinkat+0x242/0x2d0 fs/namei.c:4154
          __do_sys_symlink fs/namei.c:4173 [inline]
          __se_sys_symlink fs/namei.c:4171 [inline]
          __x64_sys_symlink+0x59/0x80 fs/namei.c:4171
          do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
          entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
        Freed by task 9425:
          save_stack+0x43/0xd0 mm/kasan/kasan.c:448
          set_track mm/kasan/kasan.c:460 [inline]
          __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
          kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
          __cache_free mm/slab.c:3498 [inline]
          kfree+0xcf/0x230 mm/slab.c:3817
          bpf_evict_inode+0x11f/0x150 kernel/bpf/inode.c:565
          evict+0x4b9/0x980 fs/inode.c:558
          iput_final fs/inode.c:1550 [inline]
          iput+0x674/0xa90 fs/inode.c:1576
          do_unlinkat+0x733/0xa30 fs/namei.c:4069
          __do_sys_unlink fs/namei.c:4110 [inline]
          __se_sys_unlink fs/namei.c:4108 [inline]
          __x64_sys_unlink+0x42/0x50 fs/namei.c:4108
          do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
          entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      In this scenario path lookup under RCU is racing with the final
      unlink in case of symlinks. As Linus puts it in his analysis:
      
        [...] We actually RCU-delay the inode freeing itself, but
        when we do the final iput(), the "evict()" function is called
        synchronously. Now, the simple fix would seem to just RCU-delay
        the kfree() of the symlink data in bpf_evict_inode(). Maybe
        that's the right thing to do. [...]
      
      Al suggested to piggy-back on the ->destroy_inode() callback in
      order to implement RCU deferral there which can then kfree() the
      inode->i_link eventually right before putting inode back into
      inode cache. By reusing free_inode_nonrcu() from there we can
      avoid the need for our own inode cache and just reuse generic
      one as we currently do.
      
      And in-fact on top of all this we should just get rid of the
      bpf_evict_inode() entirely. This means truncate_inode_pages_final()
      and clear_inode() will then simply be called by the fs core via
      evict(). Dropping the reference should really only be done when
      inode is unhashed and nothing reachable anymore, so it's better
      also moved into the final ->destroy_inode() callback.
      
      Fixes: 0f98621b ("bpf, inode: add support for symlinks and fix mtime/ctime")
      Reported-by: syzbot+fb731ca573367b7f6564@syzkaller.appspotmail.com
      Reported-by: syzbot+a13e5ead792d6df37818@syzkaller.appspotmail.com
      Reported-by: syzbot+7a8ba368b47fdefca61e@syzkaller.appspotmail.com
      Suggested-by: NAl Viro <viro@zeniv.linux.org.uk>
      Analyzed-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Link: https://lore.kernel.org/lkml/0000000000006946d2057bbd0eef@google.com/T/Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org>
      e8eef7ad
    • P
      include/linux/swap.h: use offsetof() instead of custom __swapoffset macro · 40c6d718
      Pi-Hsun Shih 提交于
      [ Upstream commit a4046c06be50a4f01d435aa7fe57514818e6cc82 ]
      
      Use offsetof() to calculate offset of a field to take advantage of
      compiler built-in version when possible, and avoid UBSAN warning when
      compiling with Clang:
      
        UBSAN: Undefined behaviour in mm/swapfile.c:3010:38
        member access within null pointer of type 'union swap_header'
        CPU: 6 PID: 1833 Comm: swapon Tainted: G S                4.19.23 #43
        Call trace:
         dump_backtrace+0x0/0x194
         show_stack+0x20/0x2c
         __dump_stack+0x20/0x28
         dump_stack+0x70/0x94
         ubsan_epilogue+0x14/0x44
         ubsan_type_mismatch_common+0xf4/0xfc
         __ubsan_handle_type_mismatch_v1+0x34/0x54
         __se_sys_swapon+0x654/0x1084
         __arm64_sys_swapon+0x1c/0x24
         el0_svc_common+0xa8/0x150
         el0_svc_compat_handler+0x2c/0x38
         el0_svc_compat+0x8/0x18
      
      Link: http://lkml.kernel.org/r/20190312081902.223764-1-pihsun@chromium.orgSigned-off-by: NPi-Hsun Shih <pihsun@chromium.org>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      40c6d718
    • C
      f2fs: fix to dirty inode for i_mode recovery · 48b0309f
      Chao Yu 提交于
      [ Upstream commit ca597bddedd94906cd761d8be6a3ad21292725de ]
      
      As Seulbae Kim reported in bugzilla:
      
      https://bugzilla.kernel.org/show_bug.cgi?id=202637
      
      We didn't recover permission field correctly after sudden power-cut,
      the reason is in setattr we didn't add inode into global dirty list
      once i_mode is changed, so latter checkpoint triggered by fsync will
      not flush last i_mode into disk, result in this problem, fix it.
      Reported-by: NSeulbae Kim <seulbae@gatech.edu>
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      48b0309f
    • D
      rxrpc: Fix client call connect/disconnect race · 11582064
      David Howells 提交于
      [ Upstream commit 930c9f9125c85b5134b3e711bc252ecc094708e3 ]
      
      rxrpc_disconnect_client_call() reads the call's connection ID protocol
      value (call->cid) as part of that function's variable declarations.  This
      is bad because it's not inside the locked section and so may race with
      someone granting use of the channel to the call.
      
      This manifests as an assertion failure (see below) where the call in the
      presumed channel (0 because call->cid wasn't set when we read it) doesn't
      match the call attached to the channel we were actually granted (if 1, 2 or
      3).
      
      Fix this by moving the read and dependent calculations inside of the
      channel_lock section.  Also, only set the channel number and pointer
      variables if cid is not zero (ie. unset).
      
      This problem can be induced by injecting an occasional error in
      rxrpc_wait_for_channel() before the call to schedule().
      
      Make two further changes also:
      
       (1) Add a trace for wait failure in rxrpc_connect_call().
      
       (2) Drop channel_lock before BUG'ing in the case of the assertion failure.
      
      The failure causes a trace akin to the following:
      
      rxrpc: Assertion failed - 18446612685268945920(0xffff8880beab8c00) == 18446612685268621312(0xffff8880bea69800) is false
      ------------[ cut here ]------------
      kernel BUG at net/rxrpc/conn_client.c:824!
      ...
      RIP: 0010:rxrpc_disconnect_client_call+0x2bf/0x99d
      ...
      Call Trace:
       rxrpc_connect_call+0x902/0x9b3
       ? wake_up_q+0x54/0x54
       rxrpc_new_client_call+0x3a0/0x751
       ? rxrpc_kernel_begin_call+0x141/0x1bc
       ? afs_alloc_call+0x1b5/0x1b5
       rxrpc_kernel_begin_call+0x141/0x1bc
       afs_make_call+0x20c/0x525
       ? afs_alloc_call+0x1b5/0x1b5
       ? __lock_is_held+0x40/0x71
       ? lockdep_init_map+0xaf/0x193
       ? lockdep_init_map+0xaf/0x193
       ? __lock_is_held+0x40/0x71
       ? yfs_fs_fetch_data+0x33b/0x34a
       yfs_fs_fetch_data+0x33b/0x34a
       afs_fetch_data+0xdc/0x3b7
       afs_read_dir+0x52d/0x97f
       afs_dir_iterate+0xa0/0x661
       ? iterate_dir+0x63/0x141
       iterate_dir+0xa2/0x141
       ksys_getdents64+0x9f/0x11b
       ? filldir+0x111/0x111
       ? do_syscall_64+0x3e/0x1a0
       __x64_sys_getdents64+0x16/0x19
       do_syscall_64+0x7d/0x1a0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Fixes: 45025bce ("rxrpc: Improve management and caching of client connection objects")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NMarc Dionne <marc.dionne@auristor.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      11582064
    • S
      lib/div64.c: off by one in shift · a7e90c18
      Stanislaw Gruszka 提交于
      [ Upstream commit cdc94a37493135e355dfc0b0e086d84e3eadb50d ]
      
      fls counts bits starting from 1 to 32 (returns 0 for zero argument).  If
      we add 1 we shift right one bit more and loose precision from divisor,
      what cause function incorect results with some numbers.
      
      Corrected code was tested in user-space, see bugzilla:
         https://bugzilla.kernel.org/show_bug.cgi?id=202391
      
      Link: http://lkml.kernel.org/r/1548686944-11891-1-git-send-email-sgruszka@redhat.com
      Fixes: 658716d1 ("div64_u64(): improve precision on 32bit platforms")
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Reported-by: NSiarhei Volkau <lis8215@gmail.com>
      Tested-by: NSiarhei Volkau <lis8215@gmail.com>
      Acked-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a7e90c18
    • Y
      appletalk: Fix use-after-free in atalk_proc_exit · 6c42507f
      YueHaibing 提交于
      [ Upstream commit 6377f787aeb945cae7abbb6474798de129e1f3ac ]
      
      KASAN report this:
      
      BUG: KASAN: use-after-free in pde_subdir_find+0x12d/0x150 fs/proc/generic.c:71
      Read of size 8 at addr ffff8881f41fe5b0 by task syz-executor.0/2806
      
      CPU: 0 PID: 2806 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xfa/0x1ce lib/dump_stack.c:113
       print_address_description+0x65/0x270 mm/kasan/report.c:187
       kasan_report+0x149/0x18d mm/kasan/report.c:317
       pde_subdir_find+0x12d/0x150 fs/proc/generic.c:71
       remove_proc_entry+0xe8/0x420 fs/proc/generic.c:667
       atalk_proc_exit+0x18/0x820 [appletalk]
       atalk_exit+0xf/0x5a [appletalk]
       __do_sys_delete_module kernel/module.c:1018 [inline]
       __se_sys_delete_module kernel/module.c:961 [inline]
       __x64_sys_delete_module+0x3dc/0x5e0 kernel/module.c:961
       do_syscall_64+0x147/0x600 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:00007fb2de6b9c58 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
      RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000200001c0
      RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb2de6ba6bc
      R13: 00000000004bccaa R14: 00000000006f6bc8 R15: 00000000ffffffff
      
      Allocated by task 2806:
       set_track mm/kasan/common.c:85 [inline]
       __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:496
       slab_post_alloc_hook mm/slab.h:444 [inline]
       slab_alloc_node mm/slub.c:2739 [inline]
       slab_alloc mm/slub.c:2747 [inline]
       kmem_cache_alloc+0xcf/0x250 mm/slub.c:2752
       kmem_cache_zalloc include/linux/slab.h:730 [inline]
       __proc_create+0x30f/0xa20 fs/proc/generic.c:408
       proc_mkdir_data+0x47/0x190 fs/proc/generic.c:469
       0xffffffffc10c01bb
       0xffffffffc10c0166
       do_one_initcall+0xfa/0x5ca init/main.c:887
       do_init_module+0x204/0x5f6 kernel/module.c:3460
       load_module+0x66b2/0x8570 kernel/module.c:3808
       __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 2806:
       set_track mm/kasan/common.c:85 [inline]
       __kasan_slab_free+0x130/0x180 mm/kasan/common.c:458
       slab_free_hook mm/slub.c:1409 [inline]
       slab_free_freelist_hook mm/slub.c:1436 [inline]
       slab_free mm/slub.c:2986 [inline]
       kmem_cache_free+0xa6/0x2a0 mm/slub.c:3002
       pde_put+0x6e/0x80 fs/proc/generic.c:647
       remove_proc_entry+0x1d3/0x420 fs/proc/generic.c:684
       0xffffffffc10c031c
       0xffffffffc10c0166
       do_one_initcall+0xfa/0x5ca init/main.c:887
       do_init_module+0x204/0x5f6 kernel/module.c:3460
       load_module+0x66b2/0x8570 kernel/module.c:3808
       __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff8881f41fe500
       which belongs to the cache proc_dir_entry of size 256
      The buggy address is located 176 bytes inside of
       256-byte region [ffff8881f41fe500, ffff8881f41fe600)
      The buggy address belongs to the page:
      page:ffffea0007d07f80 count:1 mapcount:0 mapping:ffff8881f6e69a00 index:0x0
      flags: 0x2fffc0000000200(slab)
      raw: 02fffc0000000200 dead000000000100 dead000000000200 ffff8881f6e69a00
      raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8881f41fe480: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
       ffff8881f41fe500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff8881f41fe580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                           ^
       ffff8881f41fe600: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
       ffff8881f41fe680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      It should check the return value of atalk_proc_init fails,
      otherwise atalk_exit will trgger use-after-free in pde_subdir_find
      while unload the module.This patch fix error cleanup path of atalk_init
      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: NSasha Levin <sashal@kernel.org>
      6c42507f
    • K
      drm/amdkfd: use init_mqd function to allocate object for hid_mqd (CI) · 539282e9
      Kevin Wang 提交于
      [ Upstream commit cac734c2dbd2514f14c8c6a17caba1990d83bf1d ]
      
      if use the legacy method to allocate object, when mqd_hiq need to run
      uninit code, it will be cause WARNING call trace.
      
      eg: (s3 suspend test)
      [   34.918944] Call Trace:
      [   34.918948]  [<ffffffff92961dc1>] dump_stack+0x19/0x1b
      [   34.918950]  [<ffffffff92297648>] __warn+0xd8/0x100
      [   34.918951]  [<ffffffff9229778d>] warn_slowpath_null+0x1d/0x20
      [   34.918991]  [<ffffffffc03ce1fe>] uninit_mqd_hiq_sdma+0x4e/0x50 [amdgpu]
      [   34.919028]  [<ffffffffc03d0ef7>] uninitialize+0x37/0xe0 [amdgpu]
      [   34.919064]  [<ffffffffc03d15a6>] kernel_queue_uninit+0x16/0x30 [amdgpu]
      [   34.919086]  [<ffffffffc03d26c2>] pm_uninit+0x12/0x20 [amdgpu]
      [   34.919107]  [<ffffffffc03d4915>] stop_nocpsch+0x15/0x20 [amdgpu]
      [   34.919129]  [<ffffffffc03c1dce>] kgd2kfd_suspend.part.4+0x2e/0x50 [amdgpu]
      [   34.919150]  [<ffffffffc03c2667>] kgd2kfd_suspend+0x17/0x20 [amdgpu]
      [   34.919171]  [<ffffffffc03c103a>] amdgpu_amdkfd_suspend+0x1a/0x20 [amdgpu]
      [   34.919187]  [<ffffffffc02ec428>] amdgpu_device_suspend+0x88/0x3a0 [amdgpu]
      [   34.919189]  [<ffffffff922e22cf>] ? enqueue_entity+0x2ef/0xbe0
      [   34.919205]  [<ffffffffc02e8220>] amdgpu_pmops_suspend+0x20/0x30 [amdgpu]
      [   34.919207]  [<ffffffff925c56ff>] pci_pm_suspend+0x6f/0x150
      [   34.919208]  [<ffffffff925c5690>] ? pci_pm_freeze+0xf0/0xf0
      [   34.919210]  [<ffffffff926b45c6>] dpm_run_callback+0x46/0x90
      [   34.919212]  [<ffffffff926b49db>] __device_suspend+0xfb/0x2a0
      [   34.919213]  [<ffffffff926b4b9f>] async_suspend+0x1f/0xa0
      [   34.919214]  [<ffffffff922c918f>] async_run_entry_fn+0x3f/0x130
      [   34.919216]  [<ffffffff922b9d4f>] process_one_work+0x17f/0x440
      [   34.919217]  [<ffffffff922bade6>] worker_thread+0x126/0x3c0
      [   34.919218]  [<ffffffff922bacc0>] ? manage_workers.isra.25+0x2a0/0x2a0
      [   34.919220]  [<ffffffff922c1c31>] kthread+0xd1/0xe0
      [   34.919221]  [<ffffffff922c1b60>] ? insert_kthread_work+0x40/0x40
      [   34.919222]  [<ffffffff92974c1d>] ret_from_fork_nospec_begin+0x7/0x21
      [   34.919224]  [<ffffffff922c1b60>] ? insert_kthread_work+0x40/0x40
      [   34.919224] ---[ end trace 38cd9f65c963adad ]---
      Signed-off-by: NKevin Wang <kevin1.wang@amd.com>
      Reviewed-by: NOak Zeng <Oak.Zeng@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      539282e9
    • Y
      ARM: 8839/1: kprobe: make patch_lock a raw_spinlock_t · 91583411
      Yang Shi 提交于
      [ Upstream commit 143c2a89e0e5fda6c6fd08d7bc1126438c19ae90 ]
      
      When running kprobe on -rt kernel, the below bug is caught:
      
      |BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:931
      |in_atomic(): 1, irqs_disabled(): 128, pid: 14, name: migration/0
      |Preemption disabled at:[<802f2b98>] cpu_stopper_thread+0xc0/0x140
      |CPU: 0 PID: 14 Comm: migration/0 Tainted: G O 4.8.3-rt2 #1
      |Hardware name: Freescale LS1021A
      |[<8025a43c>] (___might_sleep)
      |[<80b5b324>] (rt_spin_lock)
      |[<80b5c31c>] (__patch_text_real)
      |[<80b5c3ac>] (patch_text_stop_machine)
      |[<802f2920>] (multi_cpu_stop)
      
      Since patch_text_stop_machine() is called in stop_machine() which
      disables IRQ, sleepable lock should be not used in this atomic context,
       so replace patch_lock to raw lock.
      Signed-off-by: NYang Shi <yang.shi@linaro.org>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      91583411
    • I
      drm/nouveau/volt/gf117: fix speedo readout register · 1b871f39
      Ilia Mirkin 提交于
      [ Upstream commit fc782242749fa4235592854fafe1a1297583c1fb ]
      
      GF117 appears to use the same register as GK104 (but still with the
      general Fermi readout mechanism).
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1b871f39
    • M
      PCI: Blacklist power management of Gigabyte X299 DESIGNARE EX PCIe ports · ad854fa3
      Mika Westerberg 提交于
      [ Upstream commit 85b0cae89d5266e6a7abb2e83c6f716326fc494c ]
      
      Gigabyte X299 DESIGNARE EX motherboard has one PCIe root port that is
      connected to an Alpine Ridge Thunderbolt controller.  This port has slot
      implemented bit set in the config space but other than that it is not
      hotplug capable in the sense we are expecting in Linux (it has
      dev->is_hotplug_bridge set to 0):
      
        00:1c.4 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #5
          Bus: primary=00, secondary=05, subordinate=46, sec-latency=0
          Memory behind bridge: 78000000-8fffffff [size=384M]
          Prefetchable memory behind bridge: 00003800f8000000-00003800ffffffff [size=128M]
          ...
          Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
          ...
            SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
      	      Slot #8, PowerLimit 25.000W; Interlock- NoCompl+
            SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
      	      Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
            SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
      	      Changed: MRL- PresDet+ LinkState+
      
      This system is using ACPI based hotplug to notify the OS that it needs to
      rescan the PCI bus (ACPI hotplug).
      
      If there is nothing connected in any of the Thunderbolt ports the root port
      will not have any runtime PM active children and is thus automatically
      runtime suspended pretty soon after boot by PCI PM core.  Now, when a
      device is connected the BIOS SMI handler responsible for enumerating newly
      added devices is not able to find anything because the port is in D3.
      
      Prevent this from happening by blacklisting PCI power management of this
      particular Gigabyte system.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=202031Reported-by: NKedar A Dongre <kedar.a.dongre@intel.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ad854fa3
    • L
      coresight: cpu-debug: Support for CA73 CPUs · 4984d918
      Leo Yan 提交于
      [ Upstream commit a0f890aba2be33377f4eb24e13633c4a76a68f38 ]
      
      This patch is to add the AMBA device ID for CA73 CPU, so that CPU debug
      module can be initialized successfully when a SoC contain CA73 CPUs.
      
      This patch has been verified on 96boards Hikey960.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4984d918
    • Z
      Revert "ACPI / EC: Remove old CLEAR_ON_RESUME quirk" · 2a3c322d
      Zhang Rui 提交于
      [ Upstream commit b6a3e1475b0220378ad32bdf4d8692f058b1fc03 ]
      
      On some Samsung hardware, it is necessary to clear events accumulated by
      the EC during sleep. These ECs stop reporting GPEs until they are manually
      polled, if too many events are accumulated.
      Thus the CLEAR_ON_RESUME quirk is introduced to send EC query commands
      unconditionally after resume to clear all the EC query events on those
      platforms.
      
      Later, commit 4c237371 ("ACPI / EC: Remove old CLEAR_ON_RESUME quirk")
      removes the CLEAR_ON_RESUME quirk because we thought the new EC IRQ
      polling logic should handle this case.
      
      Now it has been proved that the EC IRQ Polling logic does not fix the
      issue actually because we got regression report on these Samsung
      platforms after removing the quirk.
      
      Thus revert commit 4c237371 ("ACPI / EC: Remove old CLEAR_ON_RESUME
      quirk") to introduce back the Samsung quirk in this patch.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161Tested-by: NOrtwin Glück <odi@odi.ch>
      Tested-by: NFrancisco Cribari <cribari@gmail.com>
      Tested-by: NBalazs Varga <balazs4web@gmail.com>
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2a3c322d
    • L
      crypto: axis - fix for recursive locking from bottom half · 5f516d0b
      Lars Persson 提交于
      [ Upstream commit c34a83820f59bb275e5f2d55cd5ea99c64f6ef23 ]
      
      Clients may submit a new requests from the completion callback
      context. The driver was not prepared to receive a request in this
      state because it already held the request queue lock and a recursive
      lock error is triggered.
      
      Now all completions are queued up until we are ready to drop the queue
      lock and then delivered.
      
      The fault was triggered by TCP over an IPsec connection in the LTP
      test suite:
        LTP: starting tcp4_ipsec02 (tcp_ipsec.sh -p ah -m transport -s "100 1000 65535")
        BUG: spinlock recursion on CPU#1, genload/943
         lock: 0xbf3c3094, .magic: dead4ead, .owner: genload/943, .owner_cpu: 1
        CPU: 1 PID: 943 Comm: genload Tainted: G           O    4.9.62-axis5-devel #6
        Hardware name: Axis ARTPEC-6 Platform
         (unwind_backtrace) from [<8010d134>] (show_stack+0x18/0x1c)
         (show_stack) from [<803a289c>] (dump_stack+0x84/0x98)
         (dump_stack) from [<8016e164>] (do_raw_spin_lock+0x124/0x128)
         (do_raw_spin_lock) from [<804de1a4>] (artpec6_crypto_submit+0x2c/0xa0)
         (artpec6_crypto_submit) from [<804def38>] (artpec6_crypto_prepare_submit_hash+0xd0/0x54c)
         (artpec6_crypto_prepare_submit_hash) from [<7f3165f0>] (ah_output+0x2a4/0x3dc [ah4])
         (ah_output [ah4]) from [<805df9bc>] (xfrm_output_resume+0x178/0x4a4)
         (xfrm_output_resume) from [<805d283c>] (xfrm4_output+0xac/0xbc)
         (xfrm4_output) from [<80587928>] (ip_queue_xmit+0x140/0x3b4)
         (ip_queue_xmit) from [<805a13b4>] (tcp_transmit_skb+0x4c4/0x95c)
         (tcp_transmit_skb) from [<8059f218>] (tcp_rcv_state_process+0xdf4/0xdfc)
         (tcp_rcv_state_process) from [<805a7530>] (tcp_v4_do_rcv+0x64/0x1ac)
         (tcp_v4_do_rcv) from [<805a9724>] (tcp_v4_rcv+0xa34/0xb74)
         (tcp_v4_rcv) from [<80581d34>] (ip_local_deliver_finish+0x78/0x2b0)
         (ip_local_deliver_finish) from [<8058259c>] (ip_local_deliver+0xe4/0x104)
         (ip_local_deliver) from [<805d23ec>] (xfrm4_transport_finish+0xf4/0x144)
         (xfrm4_transport_finish) from [<805df564>] (xfrm_input+0x4f4/0x74c)
         (xfrm_input) from [<804de420>] (artpec6_crypto_task+0x208/0x38c)
         (artpec6_crypto_task) from [<801271b0>] (tasklet_action+0x60/0xec)
         (tasklet_action) from [<801266d4>] (__do_softirq+0xcc/0x3a4)
         (__do_softirq) from [<80126d20>] (irq_exit+0xf4/0x15c)
         (irq_exit) from [<801741e8>] (__handle_domain_irq+0x68/0xbc)
         (__handle_domain_irq) from [<801014f0>] (gic_handle_irq+0x50/0x94)
         (gic_handle_irq) from [<80657370>] (__irq_usr+0x50/0x80)
      Signed-off-by: NLars Persson <larper@axis.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5f516d0b
    • H
      drm/panel: panel-innolux: set display off in innolux_panel_unprepare · 862adb5b
      Hsin-Yi, Wang 提交于
      [ Upstream commit 46f3ceaffa81e846677bca8668e0ad40e643cffd ]
      
      Move mipi_dsi_dcs_set_display_off() from innolux_panel_disable()
      to innolux_panel_unprepare(), so they are consistent with
      innolux_panel_enable() and innolux_panel_prepare().
      
      This also fixes some mode check and irq timeout issue in MTK dsi code.
      
      Since some dsi code (e.g. mtk_dsi) have following call trace:
      1. drm_panel_disable(), which calls innolux_panel_disable()
      2. switch to cmd mode
      3. drm_panel_unprepare(), which calls innolux_panel_unprepare()
      
      However, mtk_dsi needs to be in cmd mode to be able to send commands
      (e.g. mipi_dsi_dcs_set_display_off() and mipi_dsi_dcs_enter_sleep_mode()),
      so we need these functions to be called after the switch to cmd mode happens,
      i.e. in innolux_panel_unprepare.
      Signed-off-by: NHsin-Yi, Wang <hsinyi@chromium.org>
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190109065922.231753-1-hsinyi@chromium.orgSigned-off-by: NSasha Levin <sashal@kernel.org>
      862adb5b
    • C
      lkdtm: Add tests for NULL pointer dereference · 2be8987a
      Christophe Leroy 提交于
      [ Upstream commit 59a12205d3c32aee4c13ca36889fdf7cfed31126 ]
      
      Introduce lkdtm tests for NULL pointer dereference: check access or exec
      at NULL address, since these errors tend to be reported differently from
      the general fault error text. For example from x86:
      
          pr_alert("BUG: unable to handle kernel %s at %px\n",
              address < PAGE_SIZE ? "NULL pointer dereference" : "paging request",
              (void *)address);
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2be8987a
    • C
      lkdtm: Print real addresses · 55588aeb
      Christophe Leroy 提交于
      [ Upstream commit 4c411157a42f122051ae3469bee0b5cabe89e139 ]
      
      Today, when doing a lkdtm test before the readiness of the
      random generator, (ptrval) is printed instead of the address
      at which it perform the fault:
      
      [ 1597.337030] lkdtm: Performing direct entry EXEC_USERSPACE
      [ 1597.337142] lkdtm: attempting ok execution at (ptrval)
      [ 1597.337398] lkdtm: attempting bad execution at (ptrval)
      [ 1597.337460] kernel tried to execute user page (77858000) -exploit attempt? (uid: 0)
      [ 1597.344769] Unable to handle kernel paging request for instruction fetch
      [ 1597.351392] Faulting instruction address: 0x77858000
      [ 1597.356312] Oops: Kernel access of bad area, sig: 11 [#1]
      
      If the lkdtm test is done later on, it prints an hashed address.
      
      In both cases this is pointless. The purpose of the test is to
      ensure the kernel generates an Oops at the expected address,
      so real addresses needs to be printed. This patch fixes that.
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      55588aeb
    • D
      soc/tegra: pmc: Drop locking from tegra_powergate_is_powered() · 8387c145
      Dmitry Osipenko 提交于
      [ Upstream commit b6e1fd17a38bd1d97c11d69fd3207b3ef9bfa4b3 ]
      
      This fixes splats like the one below if CONFIG_DEBUG_ATOMIC_SLEEP=y
      and machine (Tegra30) booted with SMP=n or all secondary CPU's are put
      offline. Locking isn't needed because it protects atomic operation.
      
      BUG: sleeping function called from invalid context at kernel/locking/mutex.c:254
      in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
      CPU: 0 PID: 0 Comm: swapper/0 Tainted: G         C        4.18.0-next-20180821-00180-gc3ebb6544e44-dirty #823
      Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
      [<c01134f4>] (unwind_backtrace) from [<c010db2c>] (show_stack+0x20/0x24)
      [<c010db2c>] (show_stack) from [<c0bd0f3c>] (dump_stack+0x94/0xa8)
      [<c0bd0f3c>] (dump_stack) from [<c0151df8>] (___might_sleep+0x13c/0x174)
      [<c0151df8>] (___might_sleep) from [<c0151ea0>] (__might_sleep+0x70/0xa8)
      [<c0151ea0>] (__might_sleep) from [<c0bec2b8>] (mutex_lock+0x2c/0x70)
      [<c0bec2b8>] (mutex_lock) from [<c0589844>] (tegra_powergate_is_powered+0x44/0xa8)
      [<c0589844>] (tegra_powergate_is_powered) from [<c0581a60>] (tegra30_cpu_rail_off_ready+0x30/0x74)
      [<c0581a60>] (tegra30_cpu_rail_off_ready) from [<c0122244>] (tegra30_idle_lp2+0xa0/0x108)
      [<c0122244>] (tegra30_idle_lp2) from [<c0853438>] (cpuidle_enter_state+0x140/0x540)
      [<c0853438>] (cpuidle_enter_state) from [<c08538a4>] (cpuidle_enter+0x40/0x4c)
      [<c08538a4>] (cpuidle_enter) from [<c01595e0>] (call_cpuidle+0x30/0x48)
      [<c01595e0>] (call_cpuidle) from [<c01599f8>] (do_idle+0x238/0x28c)
      [<c01599f8>] (do_idle) from [<c0159d28>] (cpu_startup_entry+0x28/0x2c)
      [<c0159d28>] (cpu_startup_entry) from [<c0be76c8>] (rest_init+0xd8/0xdc)
      [<c0be76c8>] (rest_init) from [<c1200f50>] (start_kernel+0x41c/0x430)
      Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
      Acked-by: NJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8387c145
    • B
      scsi: core: Avoid that system resume triggers a kernel warning · 29b934dd
      Bart Van Assche 提交于
      [ Upstream commit 388b4e6a00bb3097278ed1648ac5a1cb48c894e6 ]
      
      scsi_device_quiesce() and scsi_device_resume() are called during
      system-wide suspend and resume. scsi_device_quiesce() only succeeds for
      SCSI devices that are in one of the RUNNING, OFFLINE or TRANSPORT_OFFLINE
      states (see also scsi_set_device_state()).  This patch avoids that the
      following warning is triggered when resuming a system for which quiescing a
      SCSI device failed:
      
      WARNING: CPU: 2 PID: 11303 at drivers/scsi/scsi_lib.c:2600 scsi_device_resume+0x4f/0x58
      CPU: 2 PID: 11303 Comm: kworker/u8:70 Not tainted 5.0.0-rc1+ #50
      Hardware name: LENOVO 80E3/Lancer 5B2, BIOS A2CN45WW(V2.13) 08/04/2016
      Workqueue: events_unbound async_run_entry_fn
      Call Trace:
       scsi_dev_type_resume+0x2e/0x60
       async_run_entry_fn+0x32/0xd8
       process_one_work+0x1f4/0x420
       worker_thread+0x28/0x3c0
       kthread+0x118/0x130
       ret_from_fork+0x22/0x40
      
      Cc: Przemek Socha <soprwa@gmail.com>
      Reported-by: NPrzemek Socha <soprwa@gmail.com>
      Fixes: 3a0a5299 ("block, scsi: Make SCSI quiesce and resume work reliably") # v4.15
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      29b934dd
    • J
      iommu/dmar: Fix buffer overflow during PCI bus notification · 38855a84
      Julia Cartwright 提交于
      [ Upstream commit cffaaf0c816238c45cd2d06913476c83eb50f682 ]
      
      Commit 57384592 ("iommu/vt-d: Store bus information in RMRR PCI
      device path") changed the type of the path data, however, the change in
      path type was not reflected in size calculations.  Update to use the
      correct type and prevent a buffer overflow.
      
      This bug manifests in systems with deep PCI hierarchies, and can lead to
      an overflow of the static allocated buffer (dmar_pci_notify_info_buf),
      or can lead to overflow of slab-allocated data.
      
         BUG: KASAN: global-out-of-bounds in dmar_alloc_pci_notify_info+0x1d5/0x2e0
         Write of size 1 at addr ffffffff90445d80 by task swapper/0/1
         CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W       4.14.87-rt49-02406-gd0a0e96 #1
         Call Trace:
          ? dump_stack+0x46/0x59
          ? print_address_description+0x1df/0x290
          ? dmar_alloc_pci_notify_info+0x1d5/0x2e0
          ? kasan_report+0x256/0x340
          ? dmar_alloc_pci_notify_info+0x1d5/0x2e0
          ? e820__memblock_setup+0xb0/0xb0
          ? dmar_dev_scope_init+0x424/0x48f
          ? __down_write_common+0x1ec/0x230
          ? dmar_dev_scope_init+0x48f/0x48f
          ? dmar_free_unused_resources+0x109/0x109
          ? cpumask_next+0x16/0x20
          ? __kmem_cache_create+0x392/0x430
          ? kmem_cache_create+0x135/0x2f0
          ? e820__memblock_setup+0xb0/0xb0
          ? intel_iommu_init+0x170/0x1848
          ? _raw_spin_unlock_irqrestore+0x32/0x60
          ? migrate_enable+0x27a/0x5b0
          ? sched_setattr+0x20/0x20
          ? migrate_disable+0x1fc/0x380
          ? task_rq_lock+0x170/0x170
          ? try_to_run_init_process+0x40/0x40
          ? locks_remove_file+0x85/0x2f0
          ? dev_prepare_static_identity_mapping+0x78/0x78
          ? rt_spin_unlock+0x39/0x50
          ? lockref_put_or_lock+0x2a/0x40
          ? dput+0x128/0x2f0
          ? __rcu_read_unlock+0x66/0x80
          ? __fput+0x250/0x300
          ? __rcu_read_lock+0x1b/0x30
          ? mntput_no_expire+0x38/0x290
          ? e820__memblock_setup+0xb0/0xb0
          ? pci_iommu_init+0x25/0x63
          ? pci_iommu_init+0x25/0x63
          ? do_one_initcall+0x7e/0x1c0
          ? initcall_blacklisted+0x120/0x120
          ? kernel_init_freeable+0x27b/0x307
          ? rest_init+0xd0/0xd0
          ? kernel_init+0xf/0x120
          ? rest_init+0xd0/0xd0
          ? ret_from_fork+0x1f/0x40
         The buggy address belongs to the variable:
          dmar_pci_notify_info_buf+0x40/0x60
      
      Fixes: 57384592 ("iommu/vt-d: Store bus information in RMRR PCI device path")
      Signed-off-by: NJulia Cartwright <julia@ni.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      38855a84
    • L
      net: ip6_gre: fix possible NULL pointer dereference in ip6erspan_set_version · 8c5e9ea1
      Lorenzo Bianconi 提交于
      [ Upstream commit efcc9bcaf77c07df01371a7c34e50424c291f3ac ]
      
      Fix a possible NULL pointer dereference in ip6erspan_set_version checking
      nlattr data pointer
      
      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: 1 PID: 7549 Comm: syz-executor432 Not tainted 5.0.0-rc6-next-20190218
      #37
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      RIP: 0010:ip6erspan_set_version+0x5c/0x350 net/ipv6/ip6_gre.c:1726
      Code: 07 38 d0 7f 08 84 c0 0f 85 9f 02 00 00 49 8d bc 24 b0 00 00 00 c6 43
      54 01 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
      85 9a 02 00 00 4d 8b ac 24 b0 00 00 00 4d 85 ed 0f
      RSP: 0018:ffff888089ed7168 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: ffff8880869d6e58 RCX: 0000000000000000
      RDX: 0000000000000016 RSI: ffffffff862736b4 RDI: 00000000000000b0
      RBP: ffff888089ed7180 R08: 1ffff11010d3adcb R09: ffff8880869d6e58
      R10: ffffed1010d3add5 R11: ffff8880869d6eaf R12: 0000000000000000
      R13: ffffffff8931f8c0 R14: ffffffff862825d0 R15: ffff8880869d6e58
      FS:  0000000000b3d880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000020000184 CR3: 0000000092cc5000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
        ip6erspan_newlink+0x66/0x7b0 net/ipv6/ip6_gre.c:2210
        __rtnl_newlink+0x107b/0x16c0 net/core/rtnetlink.c:3176
        rtnl_newlink+0x69/0xa0 net/core/rtnetlink.c:3234
        rtnetlink_rcv_msg+0x465/0xb00 net/core/rtnetlink.c:5192
        netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2485
        rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5210
        netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
        netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
        netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1925
        sock_sendmsg_nosec net/socket.c:621 [inline]
        sock_sendmsg+0xdd/0x130 net/socket.c:631
        ___sys_sendmsg+0x806/0x930 net/socket.c:2136
        __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
        __do_sys_sendmsg net/socket.c:2183 [inline]
        __se_sys_sendmsg net/socket.c:2181 [inline]
        __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
        do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x440159
      Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fffa69156e8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440159
      RDX: 0000000000000000 RSI: 0000000020001340 RDI: 0000000000000003
      RBP: 00000000006ca018 R08: 0000000000000001 R09: 00000000004002c8
      R10: 0000000000000011 R11: 0000000000000246 R12: 00000000004019e0
      R13: 0000000000401a70 R14: 0000000000000000 R15: 0000000000000000
      Modules linked in:
      ---[ end trace 09f8a7d13b4faaa1 ]---
      RIP: 0010:ip6erspan_set_version+0x5c/0x350 net/ipv6/ip6_gre.c:1726
      Code: 07 38 d0 7f 08 84 c0 0f 85 9f 02 00 00 49 8d bc 24 b0 00 00 00 c6 43
      54 01 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
      85 9a 02 00 00 4d 8b ac 24 b0 00 00 00 4d 85 ed 0f
      RSP: 0018:ffff888089ed7168 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: ffff8880869d6e58 RCX: 0000000000000000
      RDX: 0000000000000016 RSI: ffffffff862736b4 RDI: 00000000000000b0
      RBP: ffff888089ed7180 R08: 1ffff11010d3adcb R09: ffff8880869d6e58
      R10: ffffed1010d3add5 R11: ffff8880869d6eaf R12: 0000000000000000
      R13: ffffffff8931f8c0 R14: ffffffff862825d0 R15: ffff8880869d6e58
      FS:  0000000000b3d880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000020000184 CR3: 0000000092cc5000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      
      Fixes: 4974d5f678ab ("net: ip6_gre: initialize erspan_ver just for erspan tunnels")
      Reported-and-tested-by: syzbot+30191cf1057abd3064af@syzkaller.appspotmail.com
      Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Reviewed-by: NGreg Rose <gvrose8192@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8c5e9ea1
    • A
      crypto: sha512/arm - fix crash bug in Thumb2 build · d7a90ee5
      Ard Biesheuvel 提交于
      [ Upstream commit c64316502008064c158fa40cc250665e461b0f2a ]
      
      The SHA512 code we adopted from the OpenSSL project uses a rather
      peculiar way to take the address of the round constant table: it
      takes the address of the sha256_block_data_order() routine, and
      substracts a constant known quantity to arrive at the base of the
      table, which is emitted by the same assembler code right before
      the routine's entry point.
      
      However, recent versions of binutils have helpfully changed the
      behavior of references emitted via an ADR instruction when running
      in Thumb2 mode: it now takes the Thumb execution mode bit into
      account, which is bit 0 af the address. This means the produced
      table address also has bit 0 set, and so we end up with an address
      value pointing 1 byte past the start of the table, which results
      in crashes such as
      
        Unable to handle kernel paging request at virtual address bf825000
        pgd = 42f44b11
        [bf825000] *pgd=80000040206003, *pmd=5f1bd003, *pte=00000000
        Internal error: Oops: 207 [#1] PREEMPT SMP THUMB2
        Modules linked in: sha256_arm(+) sha1_arm_ce sha1_arm ...
        CPU: 7 PID: 396 Comm: cryptomgr_test Not tainted 5.0.0-rc6+ #144
        Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
        PC is at sha256_block_data_order+0xaaa/0xb30 [sha256_arm]
        LR is at __this_module+0x17fd/0xffffe800 [sha256_arm]
        pc : [<bf820bca>]    lr : [<bf824ffd>]    psr: 800b0033
        sp : ebc8bbe8  ip : faaabe1c  fp : 2fdd3433
        r10: 4c5f1692  r9 : e43037df  r8 : b04b0a5a
        r7 : c369d722  r6 : 39c3693e  r5 : 7a013189  r4 : 1580d26b
        r3 : 8762a9b0  r2 : eea9c2cd  r1 : 3e9ab536  r0 : 1dea4ae7
        Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment user
        Control: 70c5383d  Table: 6b8467c0  DAC: dbadc0de
        Process cryptomgr_test (pid: 396, stack limit = 0x69e1fe23)
        Stack: (0xebc8bbe8 to 0xebc8c000)
        ...
        unwind: Unknown symbol address bf820bca
        unwind: Index not found bf820bca
        Code: 441a ea80 40f9 440a (f85e) 3b04
        ---[ end trace e560cce92700ef8a ]---
      
      Given that this affects older kernels as well, in case they are built
      with a recent toolchain, apply a minimal backportable fix, which is
      to emit another non-code label at the start of the routine, and
      reference that instead. (This is similar to the current upstream state
      of this file in OpenSSL)
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d7a90ee5
    • A
      crypto: sha256/arm - fix crash bug in Thumb2 build · 1f52fa12
      Ard Biesheuvel 提交于
      [ Upstream commit 69216a545cf81b2b32d01948f7039315abaf75a0 ]
      
      The SHA256 code we adopted from the OpenSSL project uses a rather
      peculiar way to take the address of the round constant table: it
      takes the address of the sha256_block_data_order() routine, and
      substracts a constant known quantity to arrive at the base of the
      table, which is emitted by the same assembler code right before
      the routine's entry point.
      
      However, recent versions of binutils have helpfully changed the
      behavior of references emitted via an ADR instruction when running
      in Thumb2 mode: it now takes the Thumb execution mode bit into
      account, which is bit 0 af the address. This means the produced
      table address also has bit 0 set, and so we end up with an address
      value pointing 1 byte past the start of the table, which results
      in crashes such as
      
        Unable to handle kernel paging request at virtual address bf825000
        pgd = 42f44b11
        [bf825000] *pgd=80000040206003, *pmd=5f1bd003, *pte=00000000
        Internal error: Oops: 207 [#1] PREEMPT SMP THUMB2
        Modules linked in: sha256_arm(+) sha1_arm_ce sha1_arm ...
        CPU: 7 PID: 396 Comm: cryptomgr_test Not tainted 5.0.0-rc6+ #144
        Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
        PC is at sha256_block_data_order+0xaaa/0xb30 [sha256_arm]
        LR is at __this_module+0x17fd/0xffffe800 [sha256_arm]
        pc : [<bf820bca>]    lr : [<bf824ffd>]    psr: 800b0033
        sp : ebc8bbe8  ip : faaabe1c  fp : 2fdd3433
        r10: 4c5f1692  r9 : e43037df  r8 : b04b0a5a
        r7 : c369d722  r6 : 39c3693e  r5 : 7a013189  r4 : 1580d26b
        r3 : 8762a9b0  r2 : eea9c2cd  r1 : 3e9ab536  r0 : 1dea4ae7
        Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment user
        Control: 70c5383d  Table: 6b8467c0  DAC: dbadc0de
        Process cryptomgr_test (pid: 396, stack limit = 0x69e1fe23)
        Stack: (0xebc8bbe8 to 0xebc8c000)
        ...
        unwind: Unknown symbol address bf820bca
        unwind: Index not found bf820bca
        Code: 441a ea80 40f9 440a (f85e) 3b04
        ---[ end trace e560cce92700ef8a ]---
      
      Given that this affects older kernels as well, in case they are built
      with a recent toolchain, apply a minimal backportable fix, which is
      to emit another non-code label at the start of the routine, and
      reference that instead. (This is similar to the current upstream state
      of this file in OpenSSL)
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1f52fa12
    • C
      xfrm: destroy xfrm_state synchronously on net exit path · bbbe4746
      Cong Wang 提交于
      [ Upstream commit f75a2804da391571563c4b6b29e7797787332673 ]
      
      xfrm_state_put() moves struct xfrm_state to the GC list
      and schedules the GC work to clean it up. On net exit call
      path, xfrm_state_flush() is called to clean up and
      xfrm_flush_gc() is called to wait for the GC work to complete
      before exit.
      
      However, this doesn't work because one of the ->destructor(),
      ipcomp_destroy(), schedules the same GC work again inside
      the GC work. It is hard to wait for such a nested async
      callback. This is also why syzbot still reports the following
      warning:
      
       WARNING: CPU: 1 PID: 33 at net/ipv6/xfrm6_tunnel.c:351 xfrm6_tunnel_net_exit+0x2cb/0x500 net/ipv6/xfrm6_tunnel.c:351
       ...
        ops_exit_list.isra.0+0xb0/0x160 net/core/net_namespace.c:153
        cleanup_net+0x51d/0xb10 net/core/net_namespace.c:551
        process_one_work+0xd0c/0x1ce0 kernel/workqueue.c:2153
        worker_thread+0x143/0x14a0 kernel/workqueue.c:2296
        kthread+0x357/0x430 kernel/kthread.c:246
        ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
      
      In fact, it is perfectly fine to bypass GC and destroy xfrm_state
      synchronously on net exit call path, because it is in process context
      and doesn't need a work struct to do any blocking work.
      
      This patch introduces xfrm_state_put_sync() which simply bypasses
      GC, and lets its callers to decide whether to use this synchronous
      version. On net exit path, xfrm_state_fini() and
      xfrm6_tunnel_net_exit() use it. And, as ipcomp_destroy() itself is
      blocking, it can use xfrm_state_put_sync() directly too.
      
      Also rename xfrm_state_gc_destroy() to ___xfrm_state_destroy() to
      reflect this change.
      
      Fixes: b48c05ab ("xfrm: Fix warning in xfrm6_tunnel_net_exit.")
      Reported-and-tested-by: syzbot+e9aebef558e3ed673934@syzkaller.appspotmail.com
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bbbe4746
    • S
      net/rds: fix warn in rds_message_alloc_sgs · 5be4bb31
      shamir rabinovitch 提交于
      [ Upstream commit ea010070d0a7497253d5a6f919f6dd107450b31a ]
      
      redundant copy_from_user in rds_sendmsg system call expose rds
      to issue where rds_rdma_extra_size walk the rds iovec and and
      calculate the number pf pages (sgs) it need to add to the tail of
      rds message and later rds_cmsg_rdma_args copy the rds iovec again
      and re calculate the same number and get different result causing
      WARN_ON in rds_message_alloc_sgs.
      
      fix this by doing the copy_from_user only once per rds_sendmsg
      system call.
      
      When issue occur the below dump is seen:
      
      WARNING: CPU: 0 PID: 19789 at net/rds/message.c:316 rds_message_alloc_sgs+0x10c/0x160 net/rds/message.c:316
      Kernel panic - not syncing: panic_on_warn set ...
      CPU: 0 PID: 19789 Comm: syz-executor827 Not tainted 4.19.0-next-20181030+ #101
      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+0x244/0x39d lib/dump_stack.c:113
       panic+0x2ad/0x55c kernel/panic.c:188
       __warn.cold.8+0x20/0x45 kernel/panic.c:540
       report_bug+0x254/0x2d0 lib/bug.c:186
       fixup_bug arch/x86/kernel/traps.c:178 [inline]
       do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
       do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
       invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:969
      RIP: 0010:rds_message_alloc_sgs+0x10c/0x160 net/rds/message.c:316
      Code: c0 74 04 3c 03 7e 6c 44 01 ab 78 01 00 00 e8 2b 9e 35 fa 4c 89 e0 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 14 9e 35 fa <0f> 0b 31 ff 44 89 ee e8 18 9f 35 fa 45 85 ed 75 1b e8 fe 9d 35 fa
      RSP: 0018:ffff8801c51b7460 EFLAGS: 00010293
      RAX: ffff8801bc412080 RBX: ffff8801d7bf4040 RCX: ffffffff8749c9e6
      RDX: 0000000000000000 RSI: ffffffff8749ca5c RDI: 0000000000000004
      RBP: ffff8801c51b7490 R08: ffff8801bc412080 R09: ffffed003b5c5b67
      R10: ffffed003b5c5b67 R11: ffff8801dae2db3b R12: 0000000000000000
      R13: 000000000007165c R14: 000000000007165c R15: 0000000000000005
       rds_cmsg_rdma_args+0x82d/0x1510 net/rds/rdma.c:623
       rds_cmsg_send net/rds/send.c:971 [inline]
       rds_sendmsg+0x19a2/0x3180 net/rds/send.c:1273
       sock_sendmsg_nosec net/socket.c:622 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:632
       ___sys_sendmsg+0x7fd/0x930 net/socket.c:2117
       __sys_sendmsg+0x11d/0x280 net/socket.c:2155
       __do_sys_sendmsg net/socket.c:2164 [inline]
       __se_sys_sendmsg net/socket.c:2162 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x44a859
      Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 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 0f 83 6b cb fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f1d4710ada8 EFLAGS: 00000297 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00000000006dcc28 RCX: 000000000044a859
      RDX: 0000000000000000 RSI: 0000000020001600 RDI: 0000000000000003
      RBP: 00000000006dcc20 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000297 R12: 00000000006dcc2c
      R13: 646e732f7665642f R14: 00007f1d4710b9c0 R15: 00000000006dcd2c
      Kernel Offset: disabled
      Rebooting in 86400 seconds..
      
      Reported-by: syzbot+26de17458aeda9d305d8@syzkaller.appspotmail.com
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: Nshamir rabinovitch <shamir.rabinovitch@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5be4bb31
    • R
      ACPI: EC / PM: Disable non-wakeup GPEs for suspend-to-idle · d801282d
      Rafael J. Wysocki 提交于
      [ Upstream commit f941d3e41da7f86bdb9dcc1977c2bcc6b89bfe47 ]
      
      There are systems in which non-wakeup GPEs fire during the "noirq"
      suspend stage of suspending devices and that effectively prevents the
      system that tries to suspend to idle from entering any low-power
      state at all.  If the offending GPE fires regularly and often enough,
      the system appears to be suspended, but in fact it is in a tight loop
      over "noirq" suspend and "noirq" resume of devices all the time.
      
      To prevent that from happening, disable all non-wakeup GPEs except
      for the EC GPE for suspend-to-idle (the EC GPE is special, because
      on some systems it has to be enabled for power button wakeup events
      to be generated as expected).
      
      Fixes: 147a7d9d (ACPI / PM: Do not reconfigure GPEs for suspend-to-idle)
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=201987Reported-by: NZhang Rui <rui.zhang@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d801282d
    • A
      ALSA: hda: fix front speakers on Huawei MBXP · e434fbf4
      Ayman Bagabas 提交于
      [ Upstream commit 8ac51bbc4cfec4ef08b03bef24b31e2d50ef8b37 ]
      
      This patch solves bug 200501 'Only 2 of 4 speakers playing sound.'
      It enables the front speakers on Huawei Matebook X Pro laptops.
      These laptops come with Dolby Atmos sound system and these pins
      configuration enables the front speakers.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200501Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Reviewed-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NAyman Bagabas <ayman.bagabas@gmail.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e434fbf4
    • T
      drm/ttm: Fix bo_global and mem_global kfree error · b10cc083
      Trigger Huang 提交于
      [ Upstream commit 30f33126feca0fe16df9e9302ffc28a953e2eb37 ]
      
      ttm_bo_glob and ttm_mem_glob are defined as structure instance, while
      not allocated by kzalloc, so kfree should not be invoked to release
      them anymore. Otherwise, it will cause the following kernel BUG when
      unloading amdgpu module
      
      [   48.419294] kernel BUG at /build/linux-5s7Xkn/linux-4.15.0/mm/slub.c:3894!
      [   48.419352] invalid opcode: 0000 [#1] SMP PTI
      [   48.419387] Modules linked in: amdgpu(OE-) amdchash(OE) amdttm(OE) amd_sched(OE) amdkcl(OE) amd_iommu_v2 drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi pcbc snd_seq snd_seq_device snd_timer aesni_intel snd soundcore joydev aes_x86_64 crypto_simd glue_helper cryptd input_leds mac_hid serio_raw binfmt_misc nfsd auth_rpcgss nfs_acl lockd grace sunrpc sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 8139too psmouse i2c_piix4 8139cp mii floppy pata_acpi
      [   48.419782] CPU: 1 PID: 1281 Comm: modprobe Tainted: G           OE    4.15.0-20-generic #21-Ubuntu
      [   48.419838] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      [   48.419901] RIP: 0010:kfree+0x137/0x180
      [   48.419934] RSP: 0018:ffffb02101273bf8 EFLAGS: 00010246
      [   48.419974] RAX: ffffeee1418ad7e0 RBX: ffffffffc075f100 RCX: ffff8fed7fca7ed0
      [   48.420025] RDX: 0000000000000000 RSI: 000000000003440e RDI: 0000000022400000
      [   48.420073] RBP: ffffb02101273c10 R08: 0000000000000010 R09: ffff8fed7ffd3680
      [   48.420121] R10: ffffeee1418ad7c0 R11: ffff8fed7ffd3000 R12: ffffffffc075e2c0
      [   48.420169] R13: ffffffffc074ec10 R14: ffff8fed73063900 R15: ffff8fed737428e8
      [   48.420216] FS:  00007fdc912ec540(0000) GS:ffff8fed7fc80000(0000) knlGS:0000000000000000
      [   48.420267] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   48.420308] CR2: 000055fa40c30060 CR3: 000000023470a006 CR4: 00000000003606e0
      [   48.420358] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   48.420405] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   48.420452] Call Trace:
      [   48.420485]  ttm_bo_global_kobj_release+0x20/0x30 [amdttm]
      [   48.420528]  kobject_release+0x6a/0x180
      [   48.420562]  kobject_put+0x28/0x50
      [   48.420595]  ttm_bo_global_release+0x36/0x50 [amdttm]
      [   48.420636]  amdttm_bo_device_release+0x119/0x180 [amdttm]
      [   48.420678]  ? amdttm_bo_clean_mm+0xa6/0xf0 [amdttm]
      [   48.420760]  amdgpu_ttm_fini+0xc9/0x180 [amdgpu]
      [   48.420821]  amdgpu_bo_fini+0x12/0x40 [amdgpu]
      [   48.420889]  gmc_v9_0_sw_fini+0x40/0x50 [amdgpu]
      [   48.420947]  amdgpu_device_fini+0x36f/0x4c0 [amdgpu]
      [   48.421007]  amdgpu_driver_unload_kms+0xb4/0x150 [amdgpu]
      [   48.421058]  drm_dev_unregister+0x46/0xf0 [drm]
      [   48.421102]  drm_dev_unplug+0x12/0x70 [drm]
      Signed-off-by: NTrigger Huang <Trigger.Huang@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b10cc083
    • H
      platform/x86: Add Intel AtomISP2 dummy / power-management driver · cb09e99b
      Hans de Goede 提交于
      [ Upstream commit 49ad712afa88c502831d37f7089d98eac441fb80 ]
      
      The Image Signal Processor found on Cherry Trail devices is brought up in
      D0 state on devices which have camera sensors attached to it. The ISP will
      not enter D3 state again without some massaging of its registers beforehand
      and the ISP not being in D3 state blocks the SoC from entering S0ix modes.
      
      There was a driver for the ISP in drivers/staging but that got removed
      again because it never worked. It does not seem likely that a real
      driver for the ISP will be added to the mainline kernel anytime soon.
      
      This commit adds a dummy driver which contains the necessary magic from
      the staging driver to powerdown the ISP, so that Cherry Trail devices where
      the ISP is used will properly use S0ix modes when suspended.
      
      Together with other recent S0ix related fixes this allows S0ix modes to
      be entered on e.g. a Chuwi Hi8 Pro and a HP x2 210.
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=196915Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cb09e99b
    • V
      kernel: hung_task.c: disable on suspend · 491dee74
      Vitaly Kuznetsov 提交于
      [ Upstream commit a1c6ca3c6de763459a6e93b644ec6518c890ba1c ]
      
      It is possible to observe hung_task complaints when system goes to
      suspend-to-idle state:
      
       # echo freeze > /sys/power/state
      
       PM: Syncing filesystems ... done.
       Freezing user space processes ... (elapsed 0.001 seconds) done.
       OOM killer disabled.
       Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
       sd 0:0:0:0: [sda] Synchronizing SCSI cache
       INFO: task bash:1569 blocked for more than 120 seconds.
             Not tainted 4.19.0-rc3_+ #687
       "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
       bash            D    0  1569    604 0x00000000
       Call Trace:
        ? __schedule+0x1fe/0x7e0
        schedule+0x28/0x80
        suspend_devices_and_enter+0x4ac/0x750
        pm_suspend+0x2c0/0x310
      
      Register a PM notifier to disable the detector on suspend and re-enable
      back on wakeup.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      491dee74