MISC:https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.0.5


Download: text/plain
Original: cdn.kernel.org archive.org
commit 1f6f316a537d4310747b08f89fb32565317b288b
Author: Greg Kroah-Hartman <[email protected]>
Date:   Wed Mar 27 14:18:00 2019 +0900

    Linux 5.0.5

commit a57af6d07512716b78f1a32d9426bcdf6aafc50c
Author: Hui Wang <[email protected]>
Date:   Tue Mar 19 09:28:44 2019 +0800

    ALSA: hda - Enforces runtime_resume after S3 and S4 for each codec
    
    commit b5a236c175b0d984552a5f7c9d35141024c2b261 upstream.
    
    Recently we found the audio jack detection stop working after suspend
    on many machines with Realtek codec. Sometimes the audio selection
    dialogue didn't show up after users plugged headhphone/headset into
    the headset jack, sometimes after uses plugged headphone/headset, then
    click the sound icon on the upper-right corner of gnome-desktop, it
    also showed the speaker rather than the headphone.
    
    The root cause is that before suspend, the codec already call the
    runtime_suspend since this codec is not used by any apps, then in
    resume, it will not call runtime_resume for this codec. But for some
    realtek codec (so far, alc236, alc255 and alc891) with the specific
    BIOS, if it doesn't run runtime_resume after suspend, all codec
    functions including jack detection stop working anymore.
    
    This problem existed for a long time, but it was not exposed, that is
    because when problem happens, if users play sound or open
    sound-setting to check audio device, this will trigger calling to
    runtime_resume (via snd_hda_power_up), then the codec starts working
    again before users notice this problem.
    
    Since we don't know how many codec and BIOS combinations have this
    problem, to fix it, let the driver call runtime_resume for all codecs
    in pm_resume, maybe for some codecs, this is not needed, but it is
    harmless. After a codec is runtime resumed, if it is not used by any
    apps, it will be runtime suspended soon and furthermore we don't run
    suspend frequently, this change will not add much power consumption.
    
    Fixes: cc72da7d4d06 ("ALSA: hda - Use standard runtime PM for codec power-save control")
    Signed-off-by: Hui Wang <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6c77789fb46e9ef076fb688383fcc6766e44d288
Author: Takashi Iwai <[email protected]>
Date:   Tue Jan 29 14:03:33 2019 +0100

    ALSA: hda - Record the current power state before suspend/resume calls
    
    commit 98081ca62cbac31fb0f7efaf90b2e7384ce22257 upstream.
    
    Currently we deal with single codec and suspend codec callbacks for
    all S3, S4 and runtime PM handling.  But it turned out that we want
    distinguish the call patterns sometimes, e.g. for applying some init
    sequence only at probing and restoring from hibernate.
    
    This patch slightly modifies the common PM callbacks for HD-audio
    codec and stores the currently processed PM event in power_state of
    the codec's device.power field, which is currently unused.  The codec
    callback can take a look at this event value and judges which purpose
    it's being called.
    
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8bc3816d65668a4ce2b7347fdecc95bebdce6ff6
Author: Waiman Long <[email protected]>
Date:   Wed Jan 9 23:03:25 2019 -0500

    locking/lockdep: Add debug_locks check in __lock_downgrade()
    
    commit 71492580571467fb7177aade19c18ce7486267f5 upstream.
    
    Tetsuo Handa had reported he saw an incorrect "downgrading a read lock"
    warning right after a previous lockdep warning. It is likely that the
    previous warning turned off lock debugging causing the lockdep to have
    inconsistency states leading to the lock downgrade warning.
    
    Fix that by add a check for debug_locks at the beginning of
    __lock_downgrade().
    
    Debugged-by: Tetsuo Handa <[email protected]>
    Reported-by: Tetsuo Handa <[email protected]>
    Reported-by: [email protected]
    Signed-off-by: Waiman Long <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Cc: Andrew Morton <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Cc: Paul E. McKenney <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: Will Deacon <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ingo Molnar <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0830cf62f5290b2f878faacc2b6f32e77bc2ea12
Author: Jann Horn <[email protected]>
Date:   Fri Mar 1 04:12:01 2019 +0100

    x86/unwind: Add hardcoded ORC entry for NULL
    
    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: Jann Horn <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Acked-by: Josh Poimboeuf <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: Andrew Morton <[email protected]>
    Cc: syzbot <[email protected]>
    Cc: "H. Peter Anvin" <[email protected]>
    Cc: Masahiro Yamada <[email protected]>
    Cc: Michal Marek <[email protected]>
    Cc: [email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0312f3032e35670043fd14f5773f450ae13bd09c
Author: Jann Horn <[email protected]>
Date:   Fri Mar 1 04:12:00 2019 +0100

    x86/unwind: Handle NULL pointer calls better in frame unwinder
    
    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: Jann Horn <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Acked-by: Josh Poimboeuf <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: Andrew Morton <[email protected]>
    Cc: syzbot <[email protected]>
    Cc: "H. Peter Anvin" <[email protected]>
    Cc: Masahiro Yamada <[email protected]>
    Cc: Michal Marek <[email protected]>
    Cc: [email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1e641e63fe0c969ae21f46d739bc5b181911f1ba
Author: Dongli Zhang <[email protected]>
Date:   Mon Mar 18 20:23:17 2019 +0800

    loop: access lo_backing_file only when the loop device is Lo_bound
    
    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: [email protected]
    Signed-off-by: Dongli Zhang <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit da75d37754011753db79d5d93fb9a2517446c3e6
Author: Florian Westphal <[email protected]>
Date:   Tue Feb 19 00:37:21 2019 +0100

    netfilter: ebtables: remove BUGPRINT messages
    
    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: Florian Westphal <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a179695eddd9f94e89ede2cbbf2b27cf748d5070
Author: Linus Torvalds <[email protected]>
Date:   Sun Mar 3 14:23:33 2019 -0800

    aio: simplify - and fix - fget/fput for io_submit()
    
    commit 84c4e1f89fefe70554da0ab33be72c9be7994379 upstream.
    
    Al Viro root-caused a race where the IOCB_CMD_POLL handling of
    fget/fput() could cause us to access the file pointer after it had
    already been freed:
    
     "In more details - normally IOCB_CMD_POLL handling looks so:
    
       1) io_submit(2) allocates aio_kiocb instance and passes it to
          aio_poll()
    
       2) aio_poll() resolves the descriptor to struct file by req->file =
          fget(iocb->aio_fildes)
    
       3) aio_poll() sets ->woken to false and raises ->ki_refcnt of that
          aio_kiocb to 2 (bumps by 1, that is).
    
       4) aio_poll() calls vfs_poll(). After sanity checks (basically,
          "poll_wait() had been called and only once") it locks the queue.
          That's what the extra reference to iocb had been for - we know we
          can safely access it.
    
       5) With queue locked, we check if ->woken has already been set to
          true (by aio_poll_wake()) and, if it had been, we unlock the
          queue, drop a reference to aio_kiocb and bugger off - at that
          point it's a responsibility to aio_poll_wake() and the stuff
          called/scheduled by it. That code will drop the reference to file
          in req->file, along with the other reference to our aio_kiocb.
    
       6) otherwise, we see whether we need to wait. If we do, we unlock the
          queue, drop one reference to aio_kiocb and go away - eventual
          wakeup (or cancel) will deal with the reference to file and with
          the other reference to aio_kiocb
    
       7) otherwise we remove ourselves from waitqueue (still under the
          queue lock), so that wakeup won't get us. No async activity will
          be happening, so we can safely drop req->file and iocb ourselves.
    
      If wakeup happens while we are in vfs_poll(), we are fine - aio_kiocb
      won't get freed under us, so we can do all the checks and locking
      safely. And we don't touch ->file if we detect that case.
    
      However, vfs_poll() most certainly *does* touch the file it had been
      given. So wakeup coming while we are still in ->poll() might end up
      doing fput() on that file. That case is not too rare, and usually we
      are saved by the still present reference from descriptor table - that
      fput() is not the final one.
    
      But if another thread closes that descriptor right after our fget()
      and wakeup does happen before ->poll() returns, we are in trouble -
      final fput() done while we are in the middle of a method:
    
    Al also wrote a patch to take an extra reference to the file descriptor
    to fix this, but I instead suggested we just streamline the whole file
    pointer handling by submit_io() so that the generic aio submission code
    simply keeps the file pointer around until the aio has completed.
    
    Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
    Acked-by: Al Viro <[email protected]>
    Reported-by: [email protected]
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1c0fc5e9cb408b41ff7c5f3c1ed102c94ce98f50
Author: Chao Yu <[email protected]>
Date:   Mon Feb 25 17:11:03 2019 +0800

    f2fs: fix to avoid deadlock of atomic file operations
    
    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: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 648562c0a9583ec4927c7d5eba5259fe7785d314
Author: Myungho Jung <[email protected]>
Date:   Wed Jan 9 22:27:31 2019 -0800

    RDMA/cma: Rollback source IP address if failing to acquire device
    
    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: [email protected]
    Signed-off-by: Myungho Jung <[email protected]>
    Reviewed-by: Parav Pandit <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 244594c5f5c80c6505b4dd6a94bd1b847d24f38e
Author: Tetsuo Handa <[email protected]>
Date:   Sat Jan 19 01:43:43 2019 +0900

    drm/vkms: Fix flush_work() without INIT_WORK().
    
    commit b30b61ff6b1dc37f276cf56a8328b80086a3ffca upstream.
    
    syzbot is hitting a lockdep warning [1] because flush_work() is called
    without INIT_WORK() after kzalloc() at vkms_atomic_crtc_reset().
    
    Commit 6c234fe37c57627a ("drm/vkms: Implement CRC debugfs API") added
    INIT_WORK() to only vkms_atomic_crtc_duplicate_state() side. Assuming
    that lifecycle of crc_work is appropriately managed, fix this problem
    by adding INIT_WORK() to vkms_atomic_crtc_reset() side.
    
    [1] https://syzkaller.appspot.com/bug?id=a5954455fcfa51c29ca2ab55b203076337e1c770
    
    Reported-and-tested-by: syzbot <[email protected]>
    Signed-off-by: Tetsuo Handa <[email protected]>
    Reviewed-by: Shayenne Moura <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected].jp
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 35228ce61a8160199d1ea4ced956116bba686192
Author: Kefeng Wang <[email protected]>
Date:   Sat Feb 23 12:33:27 2019 +0800

    Bluetooth: hci_ldisc: Postpone HCI_UART_PROTO_READY bit set in hci_uart_set_proto()
    
    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: [email protected]
    Signed-off-by: Kefeng Wang <[email protected]>
    Reviewed-by: Jeremy Cline <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c8d311117c3e45b55794ace66e098f6b622c356e
Author: Jeremy Cline <[email protected]>
Date:   Wed Feb 6 12:54:16 2019 -0500

    Bluetooth: hci_ldisc: Initialize hci_dev before open()
    
    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: [email protected]
    Signed-off-by: Jeremy Cline <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4d18023ade55906b1e1f4983f59082f747499778
Author: Myungho Jung <[email protected]>
Date:   Sat Feb 2 16:56:36 2019 -0800

    Bluetooth: Fix decrementing reference count twice in releasing socket
    
    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: [email protected]
    Signed-off-by: Myungho Jung <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 572ae5c7646b36b06d8431682ebfca66229b2ff4
Author: Myungho Jung <[email protected]>
Date:   Tue Jan 22 00:33:26 2019 -0800

    Bluetooth: hci_uart: Check if socket buffer is ERR_PTR in h4_recv_buf()
    
    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: [email protected]
    Signed-off-by: Myungho Jung <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c35a32eb2339531f0ecd502c397f9cc2b87c4c54
Author: Hans Verkuil <[email protected]>
Date:   Tue Dec 18 08:37:08 2018 -0500

    media: v4l2-ctrls.c/uvc: zero v4l2_event
    
    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: Hans Verkuil <[email protected]>
    Reported-by: [email protected]
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c29313c07f2d956c4c6c34ce998beabeddc1f5ff
Author: zhangyi (F) <[email protected]>
Date:   Sat Mar 23 11:43:05 2019 -0400

    ext4: brelse all indirect buffer in ext4_ind_remove_space()
    
    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: Hulk Robot <[email protected]>
    Signed-off-by: zhangyi (F) <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit f1902fd02d56a912b56a5eaa43d51221d8d3224b
Author: Lukas Czerner <[email protected]>
Date:   Thu Mar 14 23:20:25 2019 -0400

    ext4: fix data corruption caused by unaligned direct AIO
    
    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: Frank Sorenson <[email protected]>
    Signed-off-by: Lukas Czerner <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>
    Fixes: e9e3bcecf44c ("ext4: serialize unaligned asynchronous DIO")
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 635218fee409e6f02f220d12a86b3ef79a9c9170
Author: Jiufei Xue <[email protected]>
Date:   Thu Mar 14 23:19:22 2019 -0400

    ext4: fix NULL pointer dereference while journal is aborted
    
    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: b436b9bef84d ("ext4: Wait for proper transaction commit on fsync")
    Signed-off-by: Jiufei Xue <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>
    Reviewed-by: Joseph Qi <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5b099547f29d0e21c2982a4697ababd2f9dd55ea
Author: Takashi Iwai <[email protected]>
Date:   Mon Feb 18 14:38:06 2019 +0100

    ALSA: ac97: Fix of-node refcount unbalance
    
    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: 2225a3e6af78 ("ALSA: ac97: add codecs devicetree binding")
    Reviewed-by: Robert Jarzmik <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1fa1bfef5f4c526ab707101f900cc09587f1dd9a
Author: Hui Wang <[email protected]>
Date:   Tue Mar 19 09:28:43 2019 +0800

    ALSA: hda - Don't trigger jackpoll_work in azx_resume
    
    commit 744c67ffeb06f2d2493f4049ba0bd19698ce0adf upstream.
    
    The commit 3baffc4a84d7 (ALSA: hda/intel: Refactoring PM code) changed
    the behaviour of azx_resume(), it triggers the jackpoll_work after
    applying this commit.
    
    This change introduced a new issue, all codecs are runtime active
    after S3, and will not call runtime_suspend() automatically.
    
    The root cause is the jackpoll_work calls snd_hda_power_up/down_pm,
    and it calls up_pm before snd_hdac_enter_pm is called, while calls
    the down_pm in the middle of enter_pm and leave_pm is called. This
    makes the dev->power.usage_count unbalanced after S3.
    
    To fix it, let azx_resume() don't trigger jackpoll_work as before
    it did.
    
    Fixes: 3baffc4a84d7 ("ALSA: hda/intel: Refactoring PM code")
    Signed-off-by: Hui Wang <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2b1cf1a17a41c356981f25d31bb658df53d970dc
Author: Steve French <[email protected]>
Date:   Fri Mar 22 22:31:17 2019 -0500

    SMB3: Fix SMB3.1.1 guest mounts to Samba
    
    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: 6188f28bf608 ("Tree connect for SMB3.1.1 must be signed for non-encrypted shares")
    
    Reviewed-by: Ronnie Sahlberg <[email protected]>
    Reviewed-by: Paulo Alcantara <[email protected]>
    CC: Stable <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 809ecabb6d418d0f711d0cb0d58743c41d4be9f4
Author: Atish Patra <[email protected]>
Date:   Fri Mar 22 14:54:11 2019 -0700

    clocksource/drivers/riscv: Fix clocksource mask
    
    commit 32d0be018f6f5ee2d5d19c4795304613560814cf upstream.
    
    For all riscv architectures (RV32, RV64 and RV128), the clocksource
    is a 64 bit incrementing counter.
    
    Fix the clock source mask accordingly.
    
    Tested on both 64bit and 32 bit virt machine in QEMU.
    
    Fixes: 62b019436814 ("clocksource: new RISC-V SBI timer driver")
    Signed-off-by: Atish Patra <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Anup Patel <[email protected]>
    Cc: Albert Ou <[email protected]>
    Cc: Daniel Lezcano <[email protected]>
    Cc: [email protected]
    Cc: Palmer Dabbelt <[email protected]>
    Cc: Anup Patel <[email protected]>
    Cc: Damien Le Moal <[email protected]>
    Cc: [email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 70c1b15faf8b1885a89072d959869cd22a7bfafb
Author: Rasmus Villemoes <[email protected]>
Date:   Tue Mar 12 18:33:46 2019 +0100

    irqchip/gic-v3-its: Fix comparison logic in lpi_range_cmp
    
    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: 880cb3cddd16 (irqchip/gic-v3-its: Refactor LPI allocator)
    Cc: [email protected] (v4.19+)
    Signed-off-by: Rasmus Villemoes <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit dfa011546d27afb6c189261b5fb78db0bf9f44f3
Author: Josh Poimboeuf <[email protected]>
Date:   Mon Mar 18 19:09:38 2019 -0500

    objtool: Move objtool_file struct off the stack
    
    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: 042ba73fe7eb ("objtool: Add several performance improvements")
    Reported-by: Vassili Karpov <[email protected]>
    Signed-off-by: Josh Poimboeuf <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: [email protected]
    Link: https://lkml.kernel.org/r/d[email protected]redhat.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 198092b82db30f959e4999153d7a99f80b31f6f8
Author: Adrian Hunter <[email protected]>
Date:   Mon Mar 4 15:13:21 2019 +0200

    perf probe: Fix getting the kernel map
    
    commit eaeffeb9838a7c0dec981d258666bfcc0fa6a947 upstream.
    
    Since commit 4d99e4136580 ("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: Adrian Hunter <[email protected]>
    Tested-by: Joseph Qi <[email protected]>
    Acked-by: Masami Hiramatsu <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Andy Lutomirski <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Jiufei Xue <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: [email protected]
    Cc: Xu Yu <[email protected]>
    Fixes: 4d99e4136580 ("perf machine: Workaround missing maps for x86 PTI entry trampolines")
    Fixes: d83212d5dd67 ("kallsyms, x86: Export addresses of PTI entry trampolines")
    Link: http://lkml.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3bff3aabd58634b437a1dd7a7c099c4f270abf89
Author: Ronnie Sahlberg <[email protected]>
Date:   Thu Mar 21 14:59:02 2019 +1000

    cifs: allow guest mounts to work for smb3.11
    
    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: 6188f28bf608 ("Tree connect for SMB3.1.1 must be signed for non-encrypted shares")
    
    Signed-off-by: Ronnie Sahlberg <[email protected]>
    CC: Stable <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8dfb1e702caa46124669964fac5ebdab040137f3
Author: Chen Jie <[email protected]>
Date:   Fri Mar 15 03:44:38 2019 +0000

    futex: Ensure that futex address is aligned in handle_futex_death()
    
    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: 0771dfefc9e5 ("[PATCH] lightweight robust futexes: core")
    Signed-off-by: Chen Jie <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Cc: <[email protected]>
    Cc: <[email protected]>
    Cc: <[email protected]>
    Cc: [email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 72b8c5492f48c8bdee1dddef1c0ef4020a31dd4c
Author: Tyrel Datwyler <[email protected]>
Date:   Wed Mar 20 13:41:51 2019 -0500

    scsi: ibmvscsi: Fix empty event pool access during host removal
    
    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: <[email protected]> # v2.6.12+
    Signed-off-by: Tyrel Datwyler <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit bc1bf16d7defec622e3d9a13b841d079e73063eb
Author: Tyrel Datwyler <[email protected]>
Date:   Wed Mar 20 13:41:50 2019 -0500

    scsi: ibmvscsi: Protect ibmvscsi_head from concurrent modificaiton
    
    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: 32d6e4b6e4ea ("scsi: ibmvscsi: add vscsi hosts to global list_head")
    Cc: <[email protected]> # v4.10+
    Signed-off-by: Tyrel Datwyler <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e109bf21f4c61a869237a107249687d3c0f7e9ea
Author: Quinn Tran <[email protected]>
Date:   Fri Mar 15 15:04:18 2019 -0700

    scsi: qla2xxx: Fix FC-AL connection target discovery
    
    commit 4705f10e82c63924bd84a9b31d15839ec9ba3d06 upstream.
    
    Commit 7f147f9bfd44 ("scsi: qla2xxx: Fix N2N target discovery with Local
    loop") fixed N2N target discovery for local loop.  However, same code is
    used for FC-AL discovery as well. Added check to make sure we are bypassing
    area and domain check only in N2N topology for target discovery.
    
    Fixes: 7f147f9bfd44 ("scsi: qla2xxx: Fix N2N target discovery with Local loop")
    Cc: [email protected] # 5.0+
    Signed-off-by: Quinn Tran <[email protected]>
    Signed-off-by: Himanshu Madhani <[email protected]>
    Reviewed-by: Ewan D. Milne <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit abe481cfe98329a4bed82f3d7d910c8c638a4e77
Author: Bart Van Assche <[email protected]>
Date:   Fri Mar 15 16:27:58 2019 -0700

    scsi: core: Avoid that a kernel warning appears during system resume
    
    commit 17605afaae825b0291f80c62a7f6565879edaa8a upstream.
    
    Since scsi_device_quiesce() skips SCSI devices that have another state than
    RUNNING, OFFLINE or TRANSPORT_OFFLINE, scsi_device_resume() should not
    complain about SCSI devices that have been skipped. Hence this patch.  This
    patch avoids that the following warning appears during resume:
    
    WARNING: CPU: 3 PID: 1039 at blk_clear_pm_only+0x2a/0x30
    CPU: 3 PID: 1039 Comm: kworker/u8:49 Not tainted 5.0.0+ #1
    Hardware name: LENOVO 4180F42/4180F42, BIOS 83ET75WW (1.45 ) 05/10/2013
    Workqueue: events_unbound async_run_entry_fn
    RIP: 0010:blk_clear_pm_only+0x2a/0x30
    Call Trace:
     ? scsi_device_resume+0x28/0x50
     ? scsi_dev_type_resume+0x2b/0x80
     ? async_run_entry_fn+0x2c/0xd0
     ? process_one_work+0x1f0/0x3f0
     ? worker_thread+0x28/0x3c0
     ? process_one_work+0x3f0/0x3f0
     ? kthread+0x10c/0x130
     ? __kthread_create_on_node+0x150/0x150
     ? ret_from_fork+0x1f/0x30
    
    Cc: Christoph Hellwig <[email protected]>
    Cc: Hannes Reinecke <[email protected]>
    Cc: Ming Lei <[email protected]>
    Cc: Johannes Thumshirn <[email protected]>
    Cc: Oleksandr Natalenko <[email protected]>
    Cc: Martin Steigerwald <[email protected]>
    Cc: <[email protected]>
    Reported-by: Jisheng Zhang <[email protected]>
    Tested-by: Jisheng Zhang <[email protected]>
    Fixes: 3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work reliably") # v4.15
    Signed-off-by: Bart Van Assche <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e846d79bc1ba095482c3a2472c1a7cd2ef962e19
Author: Yishai Hadas <[email protected]>
Date:   Wed Mar 6 19:20:50 2019 +0200

    net/mlx5: Fix DCT creation bad flow
    
    commit f84b66b9cce78e8f9d38204fdaa75f07c75f4911 upstream.
    
    In case the DCT creation command has succeeded a DRAIN must be issued
    before calling DESTROY.
    
    In addition, the original code used the wrong parameter for the DESTROY
    command, 'in' instead of 'din', which caused another creation try instead
    of destroying.
    
    Cc: <[email protected]> # 4.15
    Fixes: 57cda166bbe0 ("net/mlx5: Add DCT command interface")
    Signed-off-by: Yishai Hadas <[email protected]>
    Reviewed-by: Artemy Kovalyov <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 62362ccdd45c741ac82c1a9cb033669b4e591154
Author: Michael Ellerman <[email protected]>
Date:   Thu Mar 21 15:24:33 2019 +1100

    powerpc/security: Fix spectre_v2 reporting
    
    commit 92edf8df0ff2ae86cc632eeca0e651fd8431d40d upstream.
    
    When I updated the spectre_v2 reporting to handle software count cache
    flush I got the logic wrong when there's no software count cache
    enabled at all.
    
    The result is that on systems with the software count cache flush
    disabled we print:
    
      Mitigation: Indirect branch cache disabled, Software count cache flush
    
    Which correctly indicates that the count cache is disabled, but
    incorrectly says the software count cache flush is enabled.
    
    The root of the problem is that we are trying to handle all
    combinations of options. But we know now that we only expect to see
    the software count cache flush enabled if the other options are false.
    
    So split the two cases, which simplifies the logic and fixes the bug.
    We were also missing a space before "(hardware accelerated)".
    
    The result is we see one of:
    
      Mitigation: Indirect branch serialisation (kernel only)
      Mitigation: Indirect branch cache disabled
      Mitigation: Software count cache flush
      Mitigation: Software count cache flush (hardware accelerated)
    
    Fixes: ee13cb249fab ("powerpc/64s: Add support for software count cache flush")
    Cc: [email protected] # v4.19+
    Signed-off-by: Michael Ellerman <[email protected]>
    Reviewed-by: Michael Neuling <[email protected]>
    Reviewed-by: Diana Craciun <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7f5ffb4c7a710c1f441817cbeca7ca5aecc5f4ef
Author: Michael Ellerman <[email protected]>
Date:   Thu Mar 14 00:14:38 2019 +1100

    powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038
    
    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
    a7f290dad32e ("[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 0c37ec2aa88b ("[PATCH] powerpc: vdso
    fixes (take #2)"), and the bug has existed since then AFAICS.
    
    Fixes: 0c37ec2aa88b ("[PATCH] powerpc: vdso fixes (take #2)")
    Cc: [email protected] # v2.6.15+
    Link: http://lkml.kernel.org/r/[email protected]
    Reported-by: Jakub Drnec <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 9e063d979422bced2e0783f66943e70055e2540b
Author: Archer Yan <[email protected]>
Date:   Fri Mar 8 03:29:19 2019 +0000

    MIPS: Fix kernel crash for R6 in jump label branch function
    
    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: Archer Yan <[email protected]>
    Reviewed-by: Paul Burton <[email protected]>
    [[email protected]:
      - Add MIPS prefix to subject.
      - Mark for stable from v4.0, which introduced r6 support, onwards.]
    Signed-off-by: Paul Burton <[email protected]>
    Cc: [email protected]
    Cc: [email protected] # v4.0+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit de21552cc84833d72598d54a552ca3b291cc6ca3
Author: Yasha Cherikovsky <[email protected]>
Date:   Fri Mar 8 14:58:51 2019 +0200

    MIPS: Ensure ELF appended dtb is relocated
    
    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: 069fd766271d ("MIPS: Reserve space for relocation table")
    Signed-off-by: Yasha Cherikovsky <[email protected]>
    Signed-off-by: Paul Burton <[email protected]>
    Cc: Ralf Baechle <[email protected]>
    Cc: Paul Burton <[email protected]>
    Cc: James Hogan <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected] # v4.7+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 63703e8fd2af25f5b946eff504d7e74fc19fe16d
Author: Yifeng Li <[email protected]>
Date:   Tue Mar 5 06:00:22 2019 +0800

    mips: loongson64: lemote-2f: Add IRQF_NO_SUSPEND to "cascade" irqaction.
    
    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 a3e6c1eff5 ("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 0add9c2f1cff ("MIPS:
    Loongson-3: Add IRQF_NO_SUSPEND to Cascade irqaction"), but it forgot
    to apply the same fix to Loongson2.
    
    Signed-off-by: Yifeng Li <[email protected]>
    Signed-off-by: Paul Burton <[email protected]>
    Cc: [email protected]
    Cc: Jiaxun Yang <[email protected]>
    Cc: Huacai Chen <[email protected]>
    Cc: Ralf Baechle <[email protected]>
    Cc: James Hogan <[email protected]>
    Cc: [email protected]
    Cc: [email protected] # v3.19+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit e88f693e6e8d43678c1af5d7305755098ea4d26b
Author: Jan Kara <[email protected]>
Date:   Mon Mar 11 15:04:18 2019 +0100

    udf: Fix crash on IO error during truncate
    
    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: [email protected]
    Reported-by: jean-luc malet <[email protected]>
    Signed-off-by: Jan Kara <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 48cce130d485275c0b04e4031629d3c9d62326be
Author: Ilya Dryomov <[email protected]>
Date:   Wed Mar 20 09:46:58 2019 +0100

    libceph: wait for latest osdmap in ceph_monc_blacklist_add()
    
    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: [email protected]
    Fixes: 6305a3b41515 ("libceph: support for blacklisting clients")
    Signed-off-by: Ilya Dryomov <[email protected]>
    Reviewed-by: Jason Dillaman <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 027584c8ef01eececbb4eca218ebcf301ab1231d
Author: Robert Richter <[email protected]>
Date:   Wed Mar 20 18:57:23 2019 +0000

    iommu/iova: Fix tracking of recently failed iova address
    
    commit 80ef4464d5e27408685e609d389663aad46644b9 upstream.
    
    If a 32 bit allocation request is too big to possibly succeed, it
    early exits with a failure and then should never update max32_alloc_
    size. This patch fixes current code, now the size is only updated if
    the slow path failed while walking the tree. Without the fix the
    allocation may enter the slow path again even if there was a failure
    before of a request with the same or a smaller size.
    
    Cc: <[email protected]> # 4.20+
    Fixes: bee60e94a1e2 ("iommu/iova: Optimise attempts to allocate iova from 32bit address range")
    Reviewed-by: Robin Murphy <[email protected]>
    Signed-off-by: Robert Richter <[email protected]>
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 98e2c51c1ac3d1599c221944c5aecb5868c1605d
Author: Stanislaw Gruszka <[email protected]>
Date:   Wed Mar 13 10:03:17 2019 +0100

    iommu/amd: fix sg->dma_address for sg->offset bigger than PAGE_SIZE
    
    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: [email protected]
    Reported-and-tested-by: Jan Viktorin <[email protected]>
    Reviewed-by: Alexander Duyck <[email protected]>
    Signed-off-by: Stanislaw Gruszka <[email protected]>
    Fixes: 80187fd39dcb ('iommu/amd: Optimize map_sg and unmap_sg')
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0c113ec08d71ad237ea87d3d6b55f20d0ab1a42c
Author: Deepak Rawat <[email protected]>
Date:   Thu Feb 28 10:29:54 2019 -0800

    drm/vmwgfx: Return 0 when gmrid::get_node runs out of ID's
    
    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: <[email protected]>
    Fixes: 4eb085e42fde ("drm/vmwgfx: Convert to new IDA API")
    Signed-off-by: Deepak Rawat <[email protected]>
    Reviewed-by: Thomas Hellstrom <[email protected]>
    Signed-off-by: Thomas Hellstrom <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5618b16763ce38b53aa3677744771f971c145322
Author: Thomas Zimmermann <[email protected]>
Date:   Mon Mar 18 15:47:58 2019 +0100

    drm/vmwgfx: Don't double-free the mode stored in par->set_mode
    
    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: <[email protected]>
    Fixes: a278724aa23c ("drm/vmwgfx: Implement fbdev on kms v2")
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Reviewed-by: Deepak Rawat <[email protected]>
    Signed-off-by: Thomas Hellstrom <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 109f5f9dff14a5a9d28a48218d04cdf81c370d6b
Author: Christian König <[email protected]>
Date:   Mon Mar 18 11:09:54 2019 +0100

    drm/amdgpu: fix invalid use of change_bit
    
    commit 72464382fc2d3673eb51f21a57f2c0a320c1552f upstream.
    
    We only need to clear the bit in a 32bit integer.
    
    This fixes a crah on ARM64 and PPC64LE caused by
    "drm/amdgpu: update the vm invalidation engine layout V2"
    
    Signed-off-by: Christian König <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit cdb57f82a4bc54d3de2108eec8f855b46ead6934
Author: Wolfram Sang <[email protected]>
Date:   Tue Mar 19 11:12:59 2019 +0100

    mmc: renesas_sdhi: limit block count to 16 bit for old revisions
    
    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: Yoshihiro Shimoda <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Phong Hoang <[email protected]>
    Cc: [email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1494408bf8638fdfeb4cdce923ae0645c62ca0a9
Author: Alexander Shiyan <[email protected]>
Date:   Sun Mar 17 12:58:25 2019 +0300

    mmc: mxcmmc: "Revert mmc: mxcmmc: handle highmem pages"
    
    commit 2b77158ffa92b820a0c5da9a3c6ead7aa069c71c upstream.
    
    This reverts commit b189e7589f6d3411e85c6b7ae6eef158f08f388f.
    
    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: Alexander Shiyan <[email protected]>
    Fixes: b189e7589f6d ("mmc: mxcmmc: handle highmem pages")
    Cc: [email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7e682a01b11110f0193c5808930149d7ac2826c9
Author: Daniel Drake <[email protected].com>
Date:   Wed Mar 20 14:36:53 2019 +0800

    mmc: alcor: fix DMA reads
    
    commit 5ea47691bd99e1100707ec63364aff72324e2af4 upstream.
    
    Setting max_blk_count to 1 here was causing the mmc block layer
    to always use the MMC_READ_SINGLE_BLOCK command here, which the
    driver does not DMA-accelerate.
    
    Drop the max_blk_ settings here. The mmc host defaults suffice,
    along with the max_segs and max_seg_size settings, which I have
    now documented in more detail.
    
    Now each MMC command reads 4 512-byte blocks, using DMA instead of
    PIO. On my SD card, this increases read performance (measured with dd)
    from 167kb/sec to 4.6mb/sec.
    
    Link: http://lkml.kernel.org/r/[email protected]om
    Signed-off-by: Daniel Drake <[email protected]>
    Reviewed-by: Oleksij Rempel <[email protected]>
    Fixes: c5413ad815a6 ("mmc: add new Alcor Micro Cardreader SD/MMC driver")
    Cc: [email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit cc8cd197411baebacec3a31c319d86c2ace4bfdd
Author: Arnd Bergmann <[email protected]>
Date:   Thu Mar 7 11:09:19 2019 +0100

    mmc: pxamci: fix enum type confusion
    
    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: 6464b7140951 ("mmc: pxamci: switch over to dmaengine use")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Reviewed-by: Nathan Chancellor <[email protected]>
    Acked-by: Robert Jarzmik <[email protected]>
    Cc: [email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ae833c3eefaf9b1e08978048d460bb9ae406acad
Author: Takashi Sakamoto <[email protected]>
Date:   Sun Mar 17 15:49:29 2019 +0900

    ALSA: firewire-motu: use 'version' field of unit directory to identify model
    
    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: 6c5e1ac0e144 ("ALSA: firewire-motu: add support for Motu Traveler")
    Signed-off-by: Takashi Sakamoto <[email protected]>
    Cc: <[email protected]> # v4.19+
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3c09233b5dee8b1d9503b9c1399fca2fac4b1ff8
Author: Jaroslav Kysela <[email protected]>
Date:   Mon Mar 18 13:45:43 2019 +0100

    ALSA: hda - add Lenovo IdeaCentre B550 to the power_save_blacklist
    
    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: [email protected]
    Signed-off-by: Jaroslav Kysela <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
© CVE.report 2022 Twitter Nitter Twitter Viewer |

Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. It is the responsibility of user to evaluate the accuracy, completeness or usefulness of any information, opinion, advice or other content. EACH USER WILL BE SOLELY RESPONSIBLE FOR ANY consequences of his or her direct or indirect use of this web site. ALL WARRANTIES OF ANY KIND ARE EXPRESSLY DISCLAIMED. This site will NOT BE LIABLE FOR ANY DIRECT, INDIRECT or any other kind of loss.

CVE, CWE, and OVAL are registred trademarks of The MITRE Corporation and the authoritative source of CVE content is MITRE's CVE web site. This site includes MITRE data granted under the following license.

CVE.report and Source URL Uptime Status status.cve.report