1. 27 3月, 2019 40 次提交
    • J
      x86/unwind: Add hardcoded ORC entry for NULL · 206a76a6
      Jann Horn 提交于
      commit ac5ceccce5501e43d217c596e4ee859f2a3fef79 upstream.
      
      When the ORC unwinder is invoked for an oops caused by IP==0,
      it currently has no idea what to do because there is no debug information
      for the stack frame of NULL.
      
      But if RIP is NULL, it is very likely that the last successfully executed
      instruction was an indirect CALL/JMP, and it is possible to unwind out in
      the same way as for the first instruction of a normal function. Hardcode
      a corresponding ORC entry.
      
      With an artificially-added NULL call in prctl_set_seccomp(), before this
      patch, the trace is:
      
      Call Trace:
       ? __x64_sys_prctl+0x402/0x680
       ? __ia32_sys_prctl+0x6e0/0x6e0
       ? __do_page_fault+0x457/0x620
       ? do_syscall_64+0x6d/0x160
       ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      After this patch, the trace looks like this:
      
      Call Trace:
       __x64_sys_prctl+0x402/0x680
       ? __ia32_sys_prctl+0x6e0/0x6e0
       ? __do_page_fault+0x457/0x620
       do_syscall_64+0x6d/0x160
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      prctl_set_seccomp() still doesn't show up in the trace because for some
      reason, tail call optimization is only disabled in builds that use the
      frame pointer unwinder.
      Signed-off-by: NJann Horn <jannh@google.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: syzbot <syzbot+ca95b2b7aef9e7cbd6ab@syzkaller.appspotmail.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: linux-kbuild@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190301031201.7416-2-jannh@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      206a76a6
    • J
      x86/unwind: Handle NULL pointer calls better in frame unwinder · 367ccafb
      Jann Horn 提交于
      commit f4f34e1b82eb4219d8eaa1c7e2e17ca219a6a2b5 upstream.
      
      When the frame unwinder is invoked for an oops caused by a call to NULL, it
      currently skips the parent function because BP still points to the parent's
      stack frame; the (nonexistent) current function only has the first half of
      a stack frame, and BP doesn't point to it yet.
      
      Add a special case for IP==0 that calculates a fake BP from SP, then uses
      the real BP for the next frame.
      
      Note that this handles first_frame specially: Return information about the
      parent function as long as the saved IP is >=first_frame, even if the fake
      BP points below it.
      
      With an artificially-added NULL call in prctl_set_seccomp(), before this
      patch, the trace is:
      
      Call Trace:
       ? prctl_set_seccomp+0x3a/0x50
       __x64_sys_prctl+0x457/0x6f0
       ? __ia32_sys_prctl+0x750/0x750
       do_syscall_64+0x72/0x160
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      After this patch, the trace is:
      
      Call Trace:
       prctl_set_seccomp+0x3a/0x50
       __x64_sys_prctl+0x457/0x6f0
       ? __ia32_sys_prctl+0x750/0x750
       do_syscall_64+0x72/0x160
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      Signed-off-by: NJann Horn <jannh@google.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: syzbot <syzbot+ca95b2b7aef9e7cbd6ab@syzkaller.appspotmail.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: linux-kbuild@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190301031201.7416-1-jannh@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      367ccafb
    • D
      loop: access lo_backing_file only when the loop device is Lo_bound · 3254dd30
      Dongli Zhang 提交于
      commit f7c8a4120eedf24c36090b7542b179ff7a649219 upstream.
      
      Commit 758a58d0bc67 ("loop: set GENHD_FL_NO_PART_SCAN after
      blkdev_reread_part()") separates "lo->lo_backing_file = NULL" and
      "lo->lo_state = Lo_unbound" into different critical regions protected by
      loop_ctl_mutex.
      
      However, there is below race that the NULL lo->lo_backing_file would be
      accessed when the backend of a loop is another loop device, e.g., loop0's
      backend is a file, while loop1's backend is loop0.
      
      loop0's backend is file            loop1's backend is loop0
      
      __loop_clr_fd()
        mutex_lock(&loop_ctl_mutex);
        lo->lo_backing_file = NULL; --> set to NULL
        mutex_unlock(&loop_ctl_mutex);
                                         loop_set_fd()
                                           mutex_lock_killable(&loop_ctl_mutex);
                                           loop_validate_file()
                                             f = l->lo_backing_file; --> NULL
                                               access if loop0 is not Lo_unbound
        mutex_lock(&loop_ctl_mutex);
        lo->lo_state = Lo_unbound;
        mutex_unlock(&loop_ctl_mutex);
      
      lo->lo_backing_file should be accessed only when the loop device is
      Lo_bound.
      
      In fact, the problem has been introduced already in commit 7ccd0791d985
      ("loop: Push loop_ctl_mutex down into loop_clr_fd()") after which
      loop_validate_file() could see devices in Lo_rundown state with which it
      did not count. It was harmless at that point but still.
      
      Fixes: 7ccd0791d985 ("loop: Push loop_ctl_mutex down into loop_clr_fd()")
      Reported-by: syzbot+9bdc1adc1c55e7fe765b@syzkaller.appspotmail.com
      Signed-off-by: NDongli Zhang <dongli.zhang@oracle.com>
      Reviewed-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3254dd30
    • F
      netfilter: ebtables: remove BUGPRINT messages · 35cdcdc5
      Florian Westphal 提交于
      commit d824548dae220820bdf69b2d1561b7c4b072783f upstream.
      
      They are however frequently triggered by syzkaller, so remove them.
      
      ebtables userspace should never trigger any of these, so there is little
      value in making them pr_debug (or ratelimited).
      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>
      35cdcdc5
    • C
      f2fs: fix to avoid deadlock of atomic file operations · 1fd916e8
      Chao Yu 提交于
      commit 48432984d718c95cf13e26d487c2d1b697c3c01f upstream.
      
      Thread A				Thread B
      - __fput
       - f2fs_release_file
        - drop_inmem_pages
         - mutex_lock(&fi->inmem_lock)
         - __revoke_inmem_pages
          - lock_page(page)
      					- open
      					- f2fs_setattr
      					- truncate_setsize
      					 - truncate_inode_pages_range
      					  - lock_page(page)
      					  - truncate_cleanup_page
      					   - f2fs_invalidate_page
      					    - drop_inmem_page
      					    - mutex_lock(&fi->inmem_lock);
      
      We may encounter above ABBA deadlock as reported by Kyungtae Kim:
      
      I'm reporting a bug in linux-4.17.19: "INFO: task hung in
      drop_inmem_page" (no reproducer)
      
      I think this might be somehow related to the following:
      https://groups.google.com/forum/#!searchin/syzkaller-bugs/INFO$3A$20task$20hung$20in$20%7Csort:date/syzkaller-bugs/c6soBTrdaIo/AjAzPeIzCgAJ
      
      =========================================
      INFO: task syz-executor7:10822 blocked for more than 120 seconds.
            Not tainted 4.17.19 #1
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      syz-executor7   D27024 10822   6346 0x00000004
      Call Trace:
       context_switch kernel/sched/core.c:2867 [inline]
       __schedule+0x721/0x1e60 kernel/sched/core.c:3515
       schedule+0x88/0x1c0 kernel/sched/core.c:3559
       schedule_preempt_disabled+0x18/0x30 kernel/sched/core.c:3617
       __mutex_lock_common kernel/locking/mutex.c:833 [inline]
       __mutex_lock+0x5bd/0x1410 kernel/locking/mutex.c:893
       mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:908
       drop_inmem_page+0xcb/0x810 fs/f2fs/segment.c:327
       f2fs_invalidate_page+0x337/0x5e0 fs/f2fs/data.c:2401
       do_invalidatepage mm/truncate.c:165 [inline]
       truncate_cleanup_page+0x261/0x330 mm/truncate.c:187
       truncate_inode_pages_range+0x552/0x1610 mm/truncate.c:367
       truncate_inode_pages mm/truncate.c:478 [inline]
       truncate_pagecache+0x6d/0x90 mm/truncate.c:801
       truncate_setsize+0x81/0xa0 mm/truncate.c:826
       f2fs_setattr+0x44f/0x1270 fs/f2fs/file.c:781
       notify_change+0xa62/0xe80 fs/attr.c:313
       do_truncate+0x12e/0x1e0 fs/open.c:63
       do_last fs/namei.c:2955 [inline]
       path_openat+0x2042/0x29f0 fs/namei.c:3505
       do_filp_open+0x1bd/0x2c0 fs/namei.c:3540
       do_sys_open+0x35e/0x4e0 fs/open.c:1101
       __do_sys_open fs/open.c:1119 [inline]
       __se_sys_open fs/open.c:1114 [inline]
       __x64_sys_open+0x89/0xc0 fs/open.c:1114
       do_syscall_64+0xc4/0x4e0 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x4497b9
      RSP: 002b:00007f734e459c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
      RAX: ffffffffffffffda RBX: 00007f734e45a6cc RCX: 00000000004497b9
      RDX: 0000000000000104 RSI: 00000000000a8280 RDI: 0000000020000080
      RBP: 000000000071bea0 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 0000000000007230 R14: 00000000006f02d0 R15: 00007f734e45a700
      INFO: task syz-executor7:10858 blocked for more than 120 seconds.
            Not tainted 4.17.19 #1
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      syz-executor7   D28880 10858   6346 0x00000004
      Call Trace:
       context_switch kernel/sched/core.c:2867 [inline]
       __schedule+0x721/0x1e60 kernel/sched/core.c:3515
       schedule+0x88/0x1c0 kernel/sched/core.c:3559
       __rwsem_down_write_failed_common kernel/locking/rwsem-xadd.c:565 [inline]
       rwsem_down_write_failed+0x5e6/0xc90 kernel/locking/rwsem-xadd.c:594
       call_rwsem_down_write_failed+0x17/0x30 arch/x86/lib/rwsem.S:117
       __down_write arch/x86/include/asm/rwsem.h:142 [inline]
       down_write+0x58/0xa0 kernel/locking/rwsem.c:72
       inode_lock include/linux/fs.h:713 [inline]
       do_truncate+0x120/0x1e0 fs/open.c:61
       do_last fs/namei.c:2955 [inline]
       path_openat+0x2042/0x29f0 fs/namei.c:3505
       do_filp_open+0x1bd/0x2c0 fs/namei.c:3540
       do_sys_open+0x35e/0x4e0 fs/open.c:1101
       __do_sys_open fs/open.c:1119 [inline]
       __se_sys_open fs/open.c:1114 [inline]
       __x64_sys_open+0x89/0xc0 fs/open.c:1114
       do_syscall_64+0xc4/0x4e0 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x4497b9
      RSP: 002b:00007f734e3b4c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
      RAX: ffffffffffffffda RBX: 00007f734e3b56cc RCX: 00000000004497b9
      RDX: 0000000000000104 RSI: 00000000000a8280 RDI: 0000000020000080
      RBP: 000000000071c238 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 0000000000007230 R14: 00000000006f02d0 R15: 00007f734e3b5700
      INFO: task syz-executor5:10829 blocked for more than 120 seconds.
            Not tainted 4.17.19 #1
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      syz-executor5   D28760 10829   6308 0x80000002
      Call Trace:
       context_switch kernel/sched/core.c:2867 [inline]
       __schedule+0x721/0x1e60 kernel/sched/core.c:3515
       schedule+0x88/0x1c0 kernel/sched/core.c:3559
       io_schedule+0x21/0x80 kernel/sched/core.c:5179
       wait_on_page_bit_common mm/filemap.c:1100 [inline]
       __lock_page+0x2b5/0x390 mm/filemap.c:1273
       lock_page include/linux/pagemap.h:483 [inline]
       __revoke_inmem_pages+0xb35/0x11c0 fs/f2fs/segment.c:231
       drop_inmem_pages+0xa3/0x3e0 fs/f2fs/segment.c:306
       f2fs_release_file+0x2c7/0x330 fs/f2fs/file.c:1556
       __fput+0x2c7/0x780 fs/file_table.c:209
       ____fput+0x1a/0x20 fs/file_table.c:243
       task_work_run+0x151/0x1d0 kernel/task_work.c:113
       exit_task_work include/linux/task_work.h:22 [inline]
       do_exit+0x8ba/0x30a0 kernel/exit.c:865
       do_group_exit+0x13b/0x3a0 kernel/exit.c:968
       get_signal+0x6bb/0x1650 kernel/signal.c:2482
       do_signal+0x84/0x1b70 arch/x86/kernel/signal.c:810
       exit_to_usermode_loop+0x155/0x190 arch/x86/entry/common.c:162
       prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
       syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
       do_syscall_64+0x445/0x4e0 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x4497b9
      RSP: 002b:00007f1c68e74ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
      RAX: fffffffffffffe00 RBX: 000000000071bf80 RCX: 00000000004497b9
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000071bf80
      RBP: 000000000071bf80 R08: 0000000000000000 R09: 000000000071bf58
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      R13: 0000000000000000 R14: 00007f1c68e759c0 R15: 00007f1c68e75700
      
      This patch tries to use trylock_page to mitigate such deadlock condition
      for fix.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1fd916e8
    • M
      RDMA/cma: Rollback source IP address if failing to acquire device · 9dd5053c
      Myungho Jung 提交于
      commit 5fc01fb846bce8fa6d5f95e2625b8ce0f8e86810 upstream.
      
      If cma_acquire_dev_by_src_ip() returns error in addr_handler(), the
      device state changes back to RDMA_CM_ADDR_BOUND but the resolved source
      IP address is still left. After that, if rdma_destroy_id() is called
      after rdma_listen(), the device is freed without removed from
      listen_any_list in cma_cancel_operation(). Revert to the previous IP
      address if acquiring device fails.
      
      Reported-by: syzbot+f3ce716af730c8f96637@syzkaller.appspotmail.com
      Signed-off-by: NMyungho Jung <mhjungk@gmail.com>
      Reviewed-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9dd5053c
    • C
      drm: Reorder set_property_atomic to avoid returning with an active ww_ctx · 015b828b
      Chris Wilson 提交于
      commit 227ad6d957898a88b1746e30234ece64d305f066 upstream.
      
      Delay the drm_modeset_acquire_init() until after we check for an
      allocation failure so that we can return immediately upon error without
      having to unwind.
      
      WARNING: lock held when returning to user space!
      4.20.0+ #174 Not tainted
      ------------------------------------------------
      syz-executor556/8153 is leaving the kernel with locks still held!
      1 lock held by syz-executor556/8153:
        #0: 000000005100c85c (crtc_ww_class_acquire){+.+.}, at:
      set_property_atomic+0xb3/0x330 drivers/gpu/drm/drm_mode_object.c:462
      
      Reported-by: syzbot+6ea337c427f5083ebdf2@syzkaller.appspotmail.com
      Fixes: 144a7999 ("drm: Handle properties in the core for atomic drivers")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Sean Paul <sean@poorly.run>
      Cc: David Airlie <airlied@linux.ie>
      Cc: <stable@vger.kernel.org> # v4.14+
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181230122842.21917-1-chris@chris-wilson.co.ukSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      015b828b
    • K
      Bluetooth: hci_ldisc: Postpone HCI_UART_PROTO_READY bit set in hci_uart_set_proto() · e365b940
      Kefeng Wang 提交于
      commit 56897b217a1d0a91c9920cb418d6b3fe922f590a upstream.
      
      task A:                                task B:
      hci_uart_set_proto                     flush_to_ldisc
       - p->open(hu) -> h5_open  //alloc h5  - receive_buf
       - set_bit HCI_UART_PROTO_READY         - tty_port_default_receive_buf
       - hci_uart_register_dev                 - tty_ldisc_receive_buf
                                                - hci_uart_tty_receive
      				           - test_bit HCI_UART_PROTO_READY
      				            - h5_recv
       - clear_bit HCI_UART_PROTO_READY             while() {
       - p->open(hu) -> h5_close //free h5
      				              - h5_rx_3wire_hdr
      				               - h5_reset()  //use-after-free
                                                    }
      
      It could use ioctl to set hci uart proto, but there is
      a use-after-free issue when hci_uart_register_dev() fail in
      hci_uart_set_proto(), see stack above, fix this by setting
      HCI_UART_PROTO_READY bit only when hci_uart_register_dev()
      return success.
      
      Reported-by: syzbot+899a33dc0fa0dbaf06a6@syzkaller.appspotmail.com
      Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
      Reviewed-by: NJeremy Cline <jcline@redhat.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e365b940
    • J
      Bluetooth: hci_ldisc: Initialize hci_dev before open() · f67202f7
      Jeremy Cline 提交于
      commit 32a7b4cbe93b0a0ef7e63d31ca69ce54736c4412 upstream.
      
      The hci_dev struct hdev is referenced in work queues and timers started
      by open() in some protocols. This creates a race between the
      initialization function and the work or timer which can result hdev
      being dereferenced while it is still null.
      
      The syzbot report contains a reliable reproducer which causes a null
      pointer dereference of hdev in hci_uart_write_work() by making the
      memory allocation for hdev fail.
      
      To fix this, ensure hdev is valid from before calling a protocol's
      open() until after calling a protocol's close().
      
      Reported-by: syzbot+257790c15bcdef6fe00c@syzkaller.appspotmail.com
      Signed-off-by: NJeremy Cline <jcline@redhat.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f67202f7
    • M
      Bluetooth: Fix decrementing reference count twice in releasing socket · 4b390513
      Myungho Jung 提交于
      commit e20a2e9c42c9e4002d9e338d74e7819e88d77162 upstream.
      
      When releasing socket, it is possible to enter hci_sock_release() and
      hci_sock_dev_event(HCI_DEV_UNREG) at the same time in different thread.
      The reference count of hdev should be decremented only once from one of
      them but if storing hdev to local variable in hci_sock_release() before
      detached from socket and setting to NULL in hci_sock_dev_event(),
      hci_dev_put(hdev) is unexpectedly called twice. This is resolved by
      referencing hdev from socket after bt_sock_unlink() in
      hci_sock_release().
      
      Reported-by: syzbot+fdc00003f4efff43bc5b@syzkaller.appspotmail.com
      Signed-off-by: NMyungho Jung <mhjungk@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4b390513
    • M
      Bluetooth: hci_uart: Check if socket buffer is ERR_PTR in h4_recv_buf() · 4e0ca4bf
      Myungho Jung 提交于
      commit 1dc2d785156cbdc80806c32e8d2c7c735d0b4721 upstream.
      
      h4_recv_buf() callers store the return value to socket buffer and
      recursively pass the buffer to h4_recv_buf() without protection. So,
      ERR_PTR returned from h4_recv_buf() can be dereferenced, if called again
      before setting the socket buffer to NULL from previous error. Check if
      skb is ERR_PTR in h4_recv_buf().
      
      Reported-by: syzbot+017a32f149406df32703@syzkaller.appspotmail.com
      Signed-off-by: NMyungho Jung <mhjungk@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e0ca4bf
    • H
      media: v4l2-ctrls.c/uvc: zero v4l2_event · 6bef442e
      Hans Verkuil 提交于
      commit f45f3f753b0a3d739acda8e311b4f744d82dc52a upstream.
      
      Control events can leak kernel memory since they do not fully zero the
      event. The same code is present in both v4l2-ctrls.c and uvc_ctrl.c, so
      fix both.
      
      It appears that all other event code is properly zeroing the structure,
      it's these two places.
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Reported-by: syzbot+4f021cf3697781dbd9fb@syzkaller.appspotmail.com
      Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6bef442e
    • Z
      ext4: brelse all indirect buffer in ext4_ind_remove_space() · d12d8641
      zhangyi (F) 提交于
      commit 674a2b27234d1b7afcb0a9162e81b2e53aeef217 upstream.
      
      All indirect buffers get by ext4_find_shared() should be released no
      mater the branch should be freed or not. But now, we forget to release
      the lower depth indirect buffers when removing space from the same
      higher depth indirect block. It will lead to buffer leak and futher
      more, it may lead to quota information corruption when using old quota,
      consider the following case.
      
       - Create and mount an empty ext4 filesystem without extent and quota
         features,
       - quotacheck and enable the user & group quota,
       - Create some files and write some data to them, and then punch hole
         to some files of them, it may trigger the buffer leak problem
         mentioned above.
       - Disable quota and run quotacheck again, it will create two new
         aquota files and write the checked quota information to them, which
         probably may reuse the freed indirect block(the buffer and page
         cache was not freed) as data block.
       - Enable quota again, it will invoke
         vfs_load_quota_inode()->invalidate_bdev() to try to clean unused
         buffers and pagecache. Unfortunately, because of the buffer of quota
         data block is still referenced, quota code cannot read the up to date
         quota info from the device and lead to quota information corruption.
      
      This problem can be reproduced by xfstests generic/231 on ext3 file
      system or ext4 file system without extent and quota features.
      
      This patch fix this problem by releasing the missing indirect buffers,
      in ext4_ind_remove_space().
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: Nzhangyi (F) <yi.zhang@huawei.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: NJan Kara <jack@suse.cz>
      Cc: stable@kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d12d8641
    • L
      ext4: fix data corruption caused by unaligned direct AIO · 76c9ee6b
      Lukas Czerner 提交于
      commit 372a03e01853f860560eade508794dd274e9b390 upstream.
      
      Ext4 needs to serialize unaligned direct AIO because the zeroing of
      partial blocks of two competing unaligned AIOs can result in data
      corruption.
      
      However it decides not to serialize if the potentially unaligned aio is
      past i_size with the rationale that no pending writes are possible past
      i_size. Unfortunately if the i_size is not block aligned and the second
      unaligned write lands past i_size, but still into the same block, it has
      the potential of corrupting the previous unaligned write to the same
      block.
      
      This is (very simplified) reproducer from Frank
      
          // 41472 = (10 * 4096) + 512
          // 37376 = 41472 - 4096
      
          ftruncate(fd, 41472);
          io_prep_pwrite(iocbs[0], fd, buf[0], 4096, 37376);
          io_prep_pwrite(iocbs[1], fd, buf[1], 4096, 41472);
      
          io_submit(io_ctx, 1, &iocbs[1]);
          io_submit(io_ctx, 1, &iocbs[2]);
      
          io_getevents(io_ctx, 2, 2, events, NULL);
      
      Without this patch the 512B range from 40960 up to the start of the
      second unaligned write (41472) is going to be zeroed overwriting the data
      written by the first write. This is a data corruption.
      
      00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
      *
      00009200  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30
      *
      0000a000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
      *
      0000a200  31 31 31 31 31 31 31 31  31 31 31 31 31 31 31 31
      
      With this patch the data corruption is avoided because we will recognize
      the unaligned_aio and wait for the unwritten extent conversion.
      
      00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
      *
      00009200  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30
      *
      0000a200  31 31 31 31 31 31 31 31  31 31 31 31 31 31 31 31
      *
      0000b200
      Reported-by: NFrank Sorenson <fsorenso@redhat.com>
      Signed-off-by: NLukas Czerner <lczerner@redhat.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Fixes: e9e3bcec ("ext4: serialize unaligned asynchronous DIO")
      Cc: stable@vger.kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      76c9ee6b
    • J
      ext4: fix NULL pointer dereference while journal is aborted · 558331d0
      Jiufei Xue 提交于
      commit fa30dde38aa8628c73a6dded7cb0bba38c27b576 upstream.
      
      We see the following NULL pointer dereference while running xfstests
      generic/475:
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      PGD 8000000c84bad067 P4D 8000000c84bad067 PUD c84e62067 PMD 0
      Oops: 0000 [#1] SMP PTI
      CPU: 7 PID: 9886 Comm: fsstress Kdump: loaded Not tainted 5.0.0-rc8 #10
      RIP: 0010:ext4_do_update_inode+0x4ec/0x760
      ...
      Call Trace:
      ? jbd2_journal_get_write_access+0x42/0x50
      ? __ext4_journal_get_write_access+0x2c/0x70
      ? ext4_truncate+0x186/0x3f0
      ext4_mark_iloc_dirty+0x61/0x80
      ext4_mark_inode_dirty+0x62/0x1b0
      ext4_truncate+0x186/0x3f0
      ? unmap_mapping_pages+0x56/0x100
      ext4_setattr+0x817/0x8b0
      notify_change+0x1df/0x430
      do_truncate+0x5e/0x90
      ? generic_permission+0x12b/0x1a0
      
      This is triggered because the NULL pointer handle->h_transaction was
      dereferenced in function ext4_update_inode_fsync_trans().
      I found that the h_transaction was set to NULL in jbd2__journal_restart
      but failed to attached to a new transaction while the journal is aborted.
      
      Fix this by checking the handle before updating the inode.
      
      Fixes: b436b9be ("ext4: Wait for proper transaction commit on fsync")
      Signed-off-by: NJiufei Xue <jiufei.xue@linux.alibaba.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: NJoseph Qi <joseph.qi@linux.alibaba.com>
      Cc: stable@kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      558331d0
    • T
      ALSA: ac97: Fix of-node refcount unbalance · ff7a1f81
      Takashi Iwai 提交于
      commit 31d2350d602511efc9ef626b848fe521233b0387 upstream.
      
      ac97_of_get_child_device() take the refcount of the node explicitly
      via of_node_get(), but this leads to an unbalance.  The
      for_each_child_of_node() loop itself takes the refcount for each
      iteration node, hence you don't need to take the extra refcount
      again.
      
      Fixes: 2225a3e6 ("ALSA: ac97: add codecs devicetree binding")
      Reviewed-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ff7a1f81
    • A
      ALSA: hda/ca0132 - make pci_iounmap() call conditional · c8e91d75
      Arnd Bergmann 提交于
      commit 1e73359a24fad529b0794515b46cbfff99e5fbe6 upstream.
      
      When building without CONFIG_PCI, we can (depending on the architecture)
      get a link failure:
      
      ERROR: "pci_iounmap" [sound/pci/hda/snd-hda-codec-ca0132.ko] undefined!
      
      Adding a compile-time check for PCI gets it to work correctly on
      32-bit ARM.
      
      Fixes: d99501b8575d ("ALSA: hda/ca0132 - Call pci_iounmap() instead of iounmap()")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8e91d75
    • V
      ALSA: x86: Fix runtime PM for hdmi-lpe-audio · 4a767459
      Ville Syrjälä 提交于
      commit 8dfb839cfe737a17def8e5f88ee13c295230364a upstream.
      
      Commit 46e831abe864 ("drm/i915/lpe: Mark LPE audio runtime pm as
      "no callbacks"") broke runtime PM with lpe audio. We can no longer
      runtime suspend the GPU since the sysfs  power/control for the
      lpe-audio device no longer exists and the device is considered
      always active. We can fix this by not marking the device as
      active.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Fixes: 46e831abe864 ("drm/i915/lpe: Mark LPE audio runtime pm as "no callbacks"")
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181024154825.18185-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Acked-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4a767459
    • S
      SMB3: Fix SMB3.1.1 guest mounts to Samba · 38bd575b
      Steve French 提交于
      commit 8c11a607d1d9cd6e7f01fd6b03923597fb0ef95a upstream.
      
      Workaround problem with Samba responses to SMB3.1.1
      null user (guest) mounts.  The server doesn't set the
      expected flag in the session setup response so we have
      to do a similar check to what is done in smb3_validate_negotiate
      where we also check if the user is a null user (but not sec=krb5
      since username might not be passed in on mount for Kerberos case).
      
      Note that the commit below tightened the conditions and forced signing
      for the SMB2-TreeConnect commands as per MS-SMB2.
      However, this should only apply to normal user sessions and not for
      cases where there is no user (even if server forgets to set the flag
      in the response) since we don't have anything useful to sign with.
      This is especially important now that the more secure SMB3.1.1 protocol
      is in the default dialect list.
      
      An earlier patch ("cifs: allow guest mounts to work for smb3.11") fixed
      the guest mounts to Windows.
      
          Fixes: 6188f28b ("Tree connect for SMB3.1.1 must be signed for non-encrypted shares")
      Reviewed-by: NRonnie Sahlberg <lsahlber@redhat.com>
      Reviewed-by: NPaulo Alcantara <palcantara@suse.de>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38bd575b
    • R
      irqchip/gic-v3-its: Fix comparison logic in lpi_range_cmp · aacf2cc8
      Rasmus Villemoes 提交于
      commit 89dc891792c2e046b030f87600109c22209da32e upstream.
      
      The lpi_range_list is supposed to be sorted in ascending order of
      ->base_id (at least if the range merging is to work), but the current
      comparison function returns a positive value if rb->base_id >
      ra->base_id, which means that list_sort() will put A after B in that
      case - and vice versa, of course.
      
      Fixes: 880cb3cd (irqchip/gic-v3-its: Refactor LPI allocator)
      Cc: stable@vger.kernel.org (v4.19+)
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aacf2cc8
    • J
      objtool: Move objtool_file struct off the stack · daaeeca9
      Josh Poimboeuf 提交于
      commit 0c671812f152b628bd87c0af49da032cc2a2c319 upstream.
      
      Objtool uses over 512k of stack, thanks to the hash table embedded in
      the objtool_file struct.  This causes an unnecessarily large stack
      allocation and breaks users with low stack limits.
      
      Move the struct off the stack.
      
      Fixes: 042ba73f ("objtool: Add several performance improvements")
      Reported-by: NVassili Karpov <moosotc@gmail.com>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/df92dcbc4b84b02ffa252f46876df125fb56e2d7.1552954176.git.jpoimboe@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      daaeeca9
    • A
      perf probe: Fix getting the kernel map · 37c6f808
      Adrian Hunter 提交于
      commit eaeffeb9838a7c0dec981d258666bfcc0fa6a947 upstream.
      
      Since commit 4d99e413 ("perf machine: Workaround missing maps for
      x86 PTI entry trampolines"), perf tools has been creating more than one
      kernel map, however 'perf probe' assumed there could be only one.
      
      Fix by using machine__kernel_map() to get the main kernel map.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Tested-by: NJoseph Qi <joseph.qi@linux.alibaba.com>
      Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Jiufei Xue <jiufei.xue@linux.alibaba.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Cc: Xu Yu <xuyu@linux.alibaba.com>
      Fixes: 4d99e413 ("perf machine: Workaround missing maps for x86 PTI entry trampolines")
      Fixes: d83212d5 ("kallsyms, x86: Export addresses of PTI entry trampolines")
      Link: http://lkml.kernel.org/r/2ed432de-e904-85d2-5c36-5897ddc5b23b@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37c6f808
    • R
      cifs: allow guest mounts to work for smb3.11 · 14c52aca
      Ronnie Sahlberg 提交于
      commit e71ab2aa06f731a944993120b0eef1556c63b81c upstream.
      
      Fix Guest/Anonymous sessions so that they work with SMB 3.11.
      
      The commit noted below tightened the conditions and forced signing for
      the SMB2-TreeConnect commands as per MS-SMB2.
      However, this should only apply to normal user sessions and not for
      Guest/Anonumous sessions.
      
      Fixes: 6188f28b ("Tree connect for SMB3.1.1 must be signed for non-encrypted shares")
      Signed-off-by: NRonnie Sahlberg <lsahlber@redhat.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      14c52aca
    • C
      futex: Ensure that futex address is aligned in handle_futex_death() · 36d52f5b
      Chen Jie 提交于
      commit 5a07168d8d89b00fe1760120714378175b3ef992 upstream.
      
      The futex code requires that the user space addresses of futexes are 32bit
      aligned. sys_futex() checks this in futex_get_keys() but the robust list
      code has no alignment check in place.
      
      As a consequence the kernel crashes on architectures with strict alignment
      requirements in handle_futex_death() when trying to cmpxchg() on an
      unaligned futex address which was retrieved from the robust list.
      
      [ tglx: Rewrote changelog, proper sizeof() based alignement check and add
        	comment ]
      
      Fixes: 0771dfef ("[PATCH] lightweight robust futexes: core")
      Signed-off-by: NChen Jie <chenjie6@huawei.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: <dvhart@infradead.org>
      Cc: <peterz@infradead.org>
      Cc: <zengweilin@huawei.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/1552621478-119787-1-git-send-email-chenjie6@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36d52f5b
    • T
      scsi: ibmvscsi: Fix empty event pool access during host removal · 837becb3
      Tyrel Datwyler 提交于
      commit 7f5203c13ba8a7b7f9f6ecfe5a4d5567188d7835 upstream.
      
      The event pool used for queueing commands is destroyed fairly early in the
      ibmvscsi_remove() code path. Since, this happens prior to the call so
      scsi_remove_host() it is possible for further calls to queuecommand to be
      processed which manifest as a panic due to a NULL pointer dereference as
      seen here:
      
      PANIC: "Unable to handle kernel paging request for data at address
      0x00000000"
      
      Context process backtrace:
      
      DSISR: 0000000042000000 ????Syscall Result: 0000000000000000
      4 [c000000002cb3820] memcpy_power7 at c000000000064204
      [Link Register] [c000000002cb3820] ibmvscsi_send_srp_event at d000000003ed14a4
      5 [c000000002cb3920] ibmvscsi_send_srp_event at d000000003ed14a4 [ibmvscsi] ?(unreliable)
      6 [c000000002cb39c0] ibmvscsi_queuecommand at d000000003ed2388 [ibmvscsi]
      7 [c000000002cb3a70] scsi_dispatch_cmd at d00000000395c2d8 [scsi_mod]
      8 [c000000002cb3af0] scsi_request_fn at d00000000395ef88 [scsi_mod]
      9 [c000000002cb3be0] __blk_run_queue at c000000000429860
      10 [c000000002cb3c10] blk_delay_work at c00000000042a0ec
      11 [c000000002cb3c40] process_one_work at c0000000000dac30
      12 [c000000002cb3cd0] worker_thread at c0000000000db110
      13 [c000000002cb3d80] kthread at c0000000000e3378
      14 [c000000002cb3e30] ret_from_kernel_thread at c00000000000982c
      
      The kernel buffer log is overfilled with this log:
      
      [11261.952732] ibmvscsi: found no event struct in pool!
      
      This patch reorders the operations during host teardown. Start by calling
      the SRP transport and Scsi_Host remove functions to flush any outstanding
      work and set the host offline. LLDD teardown follows including destruction
      of the event pool, freeing the Command Response Queue (CRQ), and unmapping
      any persistent buffers. The event pool destruction is protected by the
      scsi_host lock, and the pool is purged prior of any requests for which we
      never received a response. Finally, move the removal of the scsi host from
      our global list to the end so that the host is easily locatable for
      debugging purposes during teardown.
      
      Cc: <stable@vger.kernel.org> # v2.6.12+
      Signed-off-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      837becb3
    • T
      scsi: ibmvscsi: Protect ibmvscsi_head from concurrent modificaiton · 04809b22
      Tyrel Datwyler 提交于
      commit 7205981e045e752ccf96cf6ddd703a98c59d4339 upstream.
      
      For each ibmvscsi host created during a probe or destroyed during a remove
      we either add or remove that host to/from the global ibmvscsi_head
      list. This runs the risk of concurrent modification.
      
      This patch adds a simple spinlock around the list modification calls to
      prevent concurrent updates as is done similarly in the ibmvfc driver and
      ipr driver.
      
      Fixes: 32d6e4b6 ("scsi: ibmvscsi: add vscsi hosts to global list_head")
      Cc: <stable@vger.kernel.org> # v4.10+
      Signed-off-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      04809b22
    • M
      powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038 · b8ea151a
      Michael Ellerman 提交于
      commit b5b4453e7912f056da1ca7572574cada32ecb60c upstream.
      
      Jakub Drnec reported:
        Setting the realtime clock can sometimes make the monotonic clock go
        back by over a hundred years. Decreasing the realtime clock across
        the y2k38 threshold is one reliable way to reproduce. Allegedly this
        can also happen just by running ntpd, I have not managed to
        reproduce that other than booting with rtc at >2038 and then running
        ntp. When this happens, anything with timers (e.g. openjdk) breaks
        rather badly.
      
      And included a test case (slightly edited for brevity):
        #define _POSIX_C_SOURCE 199309L
        #include <stdio.h>
        #include <time.h>
        #include <stdlib.h>
        #include <unistd.h>
      
        long get_time(void) {
          struct timespec tp;
          clock_gettime(CLOCK_MONOTONIC, &tp);
          return tp.tv_sec + tp.tv_nsec / 1000000000;
        }
      
        int main(void) {
          long last = get_time();
          while(1) {
            long now = get_time();
            if (now < last) {
              printf("clock went backwards by %ld seconds!\n", last - now);
            }
            last = now;
            sleep(1);
          }
          return 0;
        }
      
      Which when run concurrently with:
       # date -s 2040-1-1
       # date -s 2037-1-1
      
      Will detect the clock going backward.
      
      The root cause is that wtom_clock_sec in struct vdso_data is only a
      32-bit signed value, even though we set its value to be equal to
      tk->wall_to_monotonic.tv_sec which is 64-bits.
      
      Because the monotonic clock starts at zero when the system boots the
      wall_to_montonic.tv_sec offset is negative for current and future
      dates. Currently on a freshly booted system the offset will be in the
      vicinity of negative 1.5 billion seconds.
      
      However if the wall clock is set past the Y2038 boundary, the offset
      from wall to monotonic becomes less than negative 2^31, and no longer
      fits in 32-bits. When that value is assigned to wtom_clock_sec it is
      truncated and becomes positive, causing the VDSO assembly code to
      calculate CLOCK_MONOTONIC incorrectly.
      
      That causes CLOCK_MONOTONIC to jump ahead by ~4 billion seconds which
      it is not meant to do. Worse, if the time is then set back before the
      Y2038 boundary CLOCK_MONOTONIC will jump backward.
      
      We can fix it simply by storing the full 64-bit offset in the
      vdso_data, and using that in the VDSO assembly code. We also shuffle
      some of the fields in vdso_data to avoid creating a hole.
      
      The original commit that added the CLOCK_MONOTONIC support to the VDSO
      did actually use a 64-bit value for wtom_clock_sec, see commit
      a7f290da ("[PATCH] powerpc: Merge vdso's and add vdso support to
      32 bits kernel") (Nov 2005). However just 3 days later it was
      converted to 32-bits in commit 0c37ec2a ("[PATCH] powerpc: vdso
      fixes (take #2)"), and the bug has existed since then AFAICS.
      
      Fixes: 0c37ec2a ("[PATCH] powerpc: vdso fixes (take #2)")
      Cc: stable@vger.kernel.org # v2.6.15+
      Link: http://lkml.kernel.org/r/HaC.ZfES.62bwlnvAvMP.1STMMj@seznam.czReported-by: NJakub Drnec <jaydee@email.cz>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8ea151a
    • A
      MIPS: Fix kernel crash for R6 in jump label branch function · 9d91069f
      Archer Yan 提交于
      commit 47c25036b60f27b86ab44b66a8861bcf81cde39b upstream.
      
      Insert Branch instruction instead of NOP to make sure assembler don't
      patch code in forbidden slot. In jump label function, it might
      be possible to patch Control Transfer Instructions(CTIs) into
      forbidden slot, which will generate Reserved Instruction exception
      in MIPS release 6.
      Signed-off-by: NArcher Yan <ayan@wavecomp.com>
      Reviewed-by: NPaul Burton <paul.burton@mips.com>
      [paul.burton@mips.com:
        - Add MIPS prefix to subject.
        - Mark for stable from v4.0, which introduced r6 support, onwards.]
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.0+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d91069f
    • Y
      MIPS: Ensure ELF appended dtb is relocated · 6e74961b
      Yasha Cherikovsky 提交于
      commit 3f0a53bc6482fb09770982a8447981260ea258dc upstream.
      
      This fixes booting with the combination of CONFIG_RELOCATABLE=y
      and CONFIG_MIPS_ELF_APPENDED_DTB=y.
      
      Sections that appear after the relocation table are not relocated
      on system boot (except .bss, which has special handling).
      
      With CONFIG_MIPS_ELF_APPENDED_DTB, the dtb is part of the
      vmlinux ELF, so it must be relocated together with everything else.
      
      Fixes: 069fd766 ("MIPS: Reserve space for relocation table")
      Signed-off-by: NYasha Cherikovsky <yasha.che3@gmail.com>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.7+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e74961b
    • Y
      mips: loongson64: lemote-2f: Add IRQF_NO_SUSPEND to "cascade" irqaction. · 56bcf3df
      Yifeng Li 提交于
      commit 5f5f67da9781770df0403269bc57d7aae608fecd upstream.
      
      Timekeeping IRQs from CS5536 MFGPT are routed to i8259, which then
      triggers the "cascade" IRQ on MIPS CPU. Without IRQF_NO_SUSPEND in
      cascade_irqaction, MFGPT interrupts will be masked in suspend mode,
      and the machine would be unable to resume once suspended.
      
      Previously, MIPS IRQs were not disabled properly, so the original
      code appeared to work. Commit a3e6c1ef ("MIPS: IRQ: Fix disable_irq on
      CPU IRQs") uncovers the bug. To fix it, add IRQF_NO_SUSPEND to
      cascade_irqaction.
      
      This commit is functionally identical to 0add9c2f ("MIPS:
      Loongson-3: Add IRQF_NO_SUSPEND to Cascade irqaction"), but it forgot
      to apply the same fix to Loongson2.
      Signed-off-by: NYifeng Li <tomli@tomli.me>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # v3.19+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      56bcf3df
    • J
      udf: Fix crash on IO error during truncate · c72e90d9
      Jan Kara 提交于
      commit d3ca4651d05c0ff7259d087d8c949bcf3e14fb46 upstream.
      
      When truncate(2) hits IO error when reading indirect extent block the
      code just bugs with:
      
      kernel BUG at linux-4.15.0/fs/udf/truncate.c:249!
      ...
      
      Fix the problem by bailing out cleanly in case of IO error.
      
      CC: stable@vger.kernel.org
      Reported-by: Njean-luc malet <jeanluc.malet@gmail.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c72e90d9
    • I
      libceph: wait for latest osdmap in ceph_monc_blacklist_add() · 9cae232a
      Ilya Dryomov 提交于
      commit bb229bbb3bf63d23128e851a1f3b85c083178fa1 upstream.
      
      Because map updates are distributed lazily, an OSD may not know about
      the new blacklist for quite some time after "osd blacklist add" command
      is completed.  This makes it possible for a blacklisted but still alive
      client to overwrite a post-blacklist update, resulting in data
      corruption.
      
      Waiting for latest osdmap in ceph_monc_blacklist_add() and thus using
      the post-blacklist epoch for all post-blacklist requests ensures that
      all such requests "wait" for the blacklist to come into force on their
      respective OSDs.
      
      Cc: stable@vger.kernel.org
      Fixes: 6305a3b4 ("libceph: support for blacklisting clients")
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: NJason Dillaman <dillaman@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9cae232a
    • S
      iommu/amd: fix sg->dma_address for sg->offset bigger than PAGE_SIZE · 86915713
      Stanislaw Gruszka 提交于
      commit 4e50ce03976fbc8ae995a000c4b10c737467beaa upstream.
      
      Take into account that sg->offset can be bigger than PAGE_SIZE when
      setting segment sg->dma_address. Otherwise sg->dma_address will point
      at diffrent page, what makes DMA not possible with erros like this:
      
      xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa70c0 flags=0x0020]
      xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7040 flags=0x0020]
      xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7080 flags=0x0020]
      xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7100 flags=0x0020]
      xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7000 flags=0x0020]
      
      Additinally with wrong sg->dma_address unmap_sg will free wrong pages,
      what what can cause crashes like this:
      
      Feb 28 19:27:45 kernel: BUG: Bad page state in process cinnamon  pfn:39e8b1
      Feb 28 19:27:45 kernel: Disabling lock debugging due to kernel taint
      Feb 28 19:27:45 kernel: flags: 0x2ffff0000000000()
      Feb 28 19:27:45 kernel: raw: 02ffff0000000000 0000000000000000 ffffffff00000301 0000000000000000
      Feb 28 19:27:45 kernel: raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
      Feb 28 19:27:45 kernel: page dumped because: nonzero _refcount
      Feb 28 19:27:45 kernel: Modules linked in: ccm fuse arc4 nct6775 hwmon_vid amdgpu nls_iso8859_1 nls_cp437 edac_mce_amd vfat fat kvm_amd ccp rng_core kvm mt76x0u mt76x0_common mt76x02_usb irqbypass mt76_usb mt76x02_lib mt76 crct10dif_pclmul crc32_pclmul chash mac80211 amd_iommu_v2 ghash_clmulni_intel gpu_sched i2c_algo_bit ttm wmi_bmof snd_hda_codec_realtek snd_hda_codec_generic drm_kms_helper snd_hda_codec_hdmi snd_hda_intel drm snd_hda_codec aesni_intel snd_hda_core snd_hwdep aes_x86_64 crypto_simd snd_pcm cfg80211 cryptd mousedev snd_timer glue_helper pcspkr r8169 input_leds realtek agpgart libphy rfkill snd syscopyarea sysfillrect sysimgblt fb_sys_fops soundcore sp5100_tco k10temp i2c_piix4 wmi evdev gpio_amdpt pinctrl_amd mac_hid pcc_cpufreq acpi_cpufreq sg ip_tables x_tables ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) fscrypto(E) sd_mod(E) hid_generic(E) usbhid(E) hid(E) dm_mod(E) serio_raw(E) atkbd(E) libps2(E) crc32c_intel(E) ahci(E) libahci(E) libata(E) xhci_pci(E) xhci_hcd(E)
      Feb 28 19:27:45 kernel:  scsi_mod(E) i8042(E) serio(E) bcache(E) crc64(E)
      Feb 28 19:27:45 kernel: CPU: 2 PID: 896 Comm: cinnamon Tainted: G    B   W   E     4.20.12-arch1-1-custom #1
      Feb 28 19:27:45 kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450M Pro4, BIOS P1.20 06/26/2018
      Feb 28 19:27:45 kernel: Call Trace:
      Feb 28 19:27:45 kernel:  dump_stack+0x5c/0x80
      Feb 28 19:27:45 kernel:  bad_page.cold.29+0x7f/0xb2
      Feb 28 19:27:45 kernel:  __free_pages_ok+0x2c0/0x2d0
      Feb 28 19:27:45 kernel:  skb_release_data+0x96/0x180
      Feb 28 19:27:45 kernel:  __kfree_skb+0xe/0x20
      Feb 28 19:27:45 kernel:  tcp_recvmsg+0x894/0xc60
      Feb 28 19:27:45 kernel:  ? reuse_swap_page+0x120/0x340
      Feb 28 19:27:45 kernel:  ? ptep_set_access_flags+0x23/0x30
      Feb 28 19:27:45 kernel:  inet_recvmsg+0x5b/0x100
      Feb 28 19:27:45 kernel:  __sys_recvfrom+0xc3/0x180
      Feb 28 19:27:45 kernel:  ? handle_mm_fault+0x10a/0x250
      Feb 28 19:27:45 kernel:  ? syscall_trace_enter+0x1d3/0x2d0
      Feb 28 19:27:45 kernel:  ? __audit_syscall_exit+0x22a/0x290
      Feb 28 19:27:45 kernel:  __x64_sys_recvfrom+0x24/0x30
      Feb 28 19:27:45 kernel:  do_syscall_64+0x5b/0x170
      Feb 28 19:27:45 kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: NJan Viktorin <jan.viktorin@gmail.com>
      Reviewed-by: NAlexander Duyck <alexander.h.duyck@linux.intel.com>
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Fixes: 80187fd3 ('iommu/amd: Optimize map_sg and unmap_sg')
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86915713
    • D
      drm/vmwgfx: Return 0 when gmrid::get_node runs out of ID's · 69e26237
      Deepak Rawat 提交于
      commit 4b9ce3a651a37c60527101db4451a315a8b9588f upstream.
      
      If it's not a system error and get_node implementation accommodate the
      buffer object then it should return 0 with memm::mm_node set to NULL.
      
      v2: Test for id != -ENOMEM instead of id == -ENOSPC.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 4eb085e4 ("drm/vmwgfx: Convert to new IDA API")
      Signed-off-by: NDeepak Rawat <drawat@vmware.com>
      Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      69e26237
    • T
      drm/vmwgfx: Don't double-free the mode stored in par->set_mode · ab483d1c
      Thomas Zimmermann 提交于
      commit c2d311553855395764e2e5bf401d987ba65c2056 upstream.
      
      When calling vmw_fb_set_par(), the mode stored in par->set_mode gets free'd
      twice. The first free is in vmw_fb_kms_detach(), the second is near the
      end of vmw_fb_set_par() under the name of 'old_mode'. The mode-setting code
      only works correctly if the mode doesn't actually change. Removing
      'old_mode' in favor of using par->set_mode directly fixes the problem.
      
      Cc: <stable@vger.kernel.org>
      Fixes: a278724a ("drm/vmwgfx: Implement fbdev on kms v2")
      Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
      Reviewed-by: NDeepak Rawat <drawat@vmware.com>
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab483d1c
    • W
      mmc: renesas_sdhi: limit block count to 16 bit for old revisions · 42f358b2
      Wolfram Sang 提交于
      commit c9a9497ccef205ed4ed2e247011382627876d831 upstream.
      
      R-Car Gen2 has two different SDHI incarnations in the same chip. The
      older one does not support the recently introduced 32 bit register
      access to the block count register. Make sure we use this feature only
      after the first known version.
      
      Thanks to the Renesas Testing team for this bug report!
      
      Fixes: 5603731a15ef ("mmc: tmio: fix access width of Block Count Register")
      Reported-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
      Tested-by: NPhong Hoang <phong.hoang.wz@renesas.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42f358b2
    • A
      mmc: mxcmmc: "Revert mmc: mxcmmc: handle highmem pages" · 65a5c936
      Alexander Shiyan 提交于
      commit 2b77158ffa92b820a0c5da9a3c6ead7aa069c71c upstream.
      
      This reverts commit b189e758.
      
      Unable to handle kernel paging request at virtual address c8358000
      pgd = efa405c3
      [c8358000] *pgd=00000000
      Internal error: Oops: 805 [#1] PREEMPT ARM
      CPU: 0 PID: 711 Comm: kworker/0:2 Not tainted 4.20.0+ #30
      Hardware name: Freescale i.MX27 (Device Tree Support)
      Workqueue: events mxcmci_datawork
      PC is at mxcmci_datawork+0xbc/0x2ac
      LR is at mxcmci_datawork+0xac/0x2ac
      pc : [<c04e33c8>]    lr : [<c04e33b8>]    psr: 60000013
      sp : c6c93f08  ip : 24004180  fp : 00000008
      r10: c8358000  r9 : c78b3e24  r8 : c6c92000
      r7 : 00000000  r6 : c7bb8680  r5 : c7bb86d4  r4 : c78b3de0
      r3 : 00002502  r2 : c090b2e0  r1 : 00000880  r0 : 00000000
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 0005317f  Table: a68a8000  DAC: 00000055
      Process kworker/0:2 (pid: 711, stack limit = 0x389543bc)
      Stack: (0xc6c93f08 to 0xc6c94000)
      3f00:                   c7bb86d4 00000000 00000000 c6cbfde0 c7bb86d4 c7ee4200
      3f20: 00000000 c0907ea8 00000000 c7bb86d8 c0907ea8 c012077c c6cbfde0 c7bb86d4
      3f40: c6cbfde0 c6c92000 c6cbfdf4 c09280ba c0907ea8 c090b2e0 c0907ebc c0120c18
      3f60: c6cbfde0 00000000 00000000 c6cbb580 c7ba7c40 c7837edc c6cbb598 00000000
      3f80: c6cbfde0 c01208f8 00000000 c01254fc c7ba7c40 c0125400 00000000 00000000
      3fa0: 00000000 00000000 00000000 c01010d0 00000000 00000000 00000000 00000000
      3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
      [<c04e33c8>] (mxcmci_datawork) from [<c012077c>] (process_one_work+0x1f0/0x338)
      [<c012077c>] (process_one_work) from [<c0120c18>] (worker_thread+0x320/0x474)
      [<c0120c18>] (worker_thread) from [<c01254fc>] (kthread+0xfc/0x118)
      [<c01254fc>] (kthread) from [<c01010d0>] (ret_from_fork+0x14/0x24)
      Exception stack(0xc6c93fb0 to 0xc6c93ff8)
      3fa0:                                     00000000 00000000 00000000 00000000
      3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
      Code: e3500000 1a000059 e5153050 e5933038 (e48a3004)
      ---[ end trace 54ca629b75f0e737 ]---
      note: kworker/0:2[711] exited with preempt_count 1
      Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
      Fixes: b189e758 ("mmc: mxcmmc: handle highmem pages")
      Cc: stable@vger.kernel.org
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      65a5c936
    • A
      mmc: pxamci: fix enum type confusion · 3b687015
      Arnd Bergmann 提交于
      commit e60a582bcde01158a64ff948fb799f21f5d31a11 upstream.
      
      clang points out several instances of mismatched types in this drivers,
      all coming from a single declaration:
      
      drivers/mmc/host/pxamci.c:193:15: error: implicit conversion from enumeration type 'enum dma_transfer_direction' to
            different enumeration type 'enum dma_data_direction' [-Werror,-Wenum-conversion]
                      direction = DMA_DEV_TO_MEM;
                                ~ ^~~~~~~~~~~~~~
      drivers/mmc/host/pxamci.c:212:62: error: implicit conversion from enumeration type 'enum dma_data_direction' to
            different enumeration type 'enum dma_transfer_direction' [-Werror,-Wenum-conversion]
              tx = dmaengine_prep_slave_sg(chan, data->sg, host->dma_len, direction,
      
      The behavior is correct, so this must be a simply typo from
      dma_data_direction and dma_transfer_direction being similarly named
      types with a similar purpose.
      
      Fixes: 6464b714 ("mmc: pxamci: switch over to dmaengine use")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
      Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      Cc: stable@vger.kernel.org
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3b687015
    • T
      ALSA: firewire-motu: use 'version' field of unit directory to identify model · 6339cc51
      Takashi Sakamoto 提交于
      commit 2d012c65a9ca26a0ef87ea0a42f1653dd37155f5 upstream.
      
      Current ALSA firewire-motu driver uses the value of 'model' field
      of unit directory in configuration ROM for modalias for MOTU
      FireWire models. However, as long as I checked, Pre8 and
      828mk3(Hybrid) have the same value for the field (=0x100800).
      
      unit            | version   | model
      --------------- | --------- | ----------
      828mkII         | 0x000003  | 0x101800
      Traveler        | 0x000009  | 0x107800
      Pre8            | 0x00000f  | 0x100800 <-
      828mk3(FW)      | 0x000015  | 0x106800
      AudioExpress    | 0x000033  | 0x104800
      828mk3(Hybrid)  | 0x000035  | 0x100800 <-
      
      When updating firmware for MOTU 8pre FireWire from v1.0.0 to v1.0.3,
      I got change of the value from 0x100800 to 0x103800. On the other
      hand, the value of 'version' field is fixed to 0x00000f. As a quick
      glance, the higher 12 bits of the value of 'version' field represent
      firmware version, while the lower 12 bits is unknown.
      
      By induction, the value of 'version' field represents actual model.
      
      This commit changes modalias to match the value of 'version' field,
      instead of 'model' field. For degug, long name of added sound card
      includes hexadecimal value of 'model' field.
      
      Fixes: 6c5e1ac0 ("ALSA: firewire-motu: add support for Motu Traveler")
      Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Cc: <stable@vger.kernel.org> # v4.19+
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6339cc51
    • J
      ALSA: hda - add Lenovo IdeaCentre B550 to the power_save_blacklist · 023a1b28
      Jaroslav Kysela 提交于
      commit 721f1e6c1fd137e7e2053d8e103b666faaa2d50c upstream.
      
      Another machine which does not like the power saving (noise):
        https://bugzilla.redhat.com/show_bug.cgi?id=1689623
      
      Also, reorder the Lenovo C50 entry to keep the table sorted.
      
      Reported-by: hs.guimaraes@outlook.com
      Signed-off-by: NJaroslav Kysela <perex@perex.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      023a1b28