commit 1848c32fad1666bdc04d40f857284ffcb55f694a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Mar 27 14:13:56 2019 +0900

    Linux 4.14.109

commit 0cc17a7a320324a84f7b4731841b0ec10e65214e
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Mar 29 00:06:10 2018 +0200

    ath10k: avoid possible string overflow
    
    commit 6707ba0105a2d350710bc0a537a98f49eb4b895d upstream.
    
    The way that 'strncat' is used here raised a warning in gcc-8:
    
    drivers/net/wireless/ath/ath10k/wmi.c: In function 'ath10k_wmi_tpc_stats_final_disp_tables':
    drivers/net/wireless/ath/ath10k/wmi.c:4649:4: error: 'strncat' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
    
    Effectively, this is simply a strcat() but the use of strncat() suggests
    some form of overflow check. Regardless of whether this might actually
    overflow, using strlcat() instead of strncat() avoids the warning and
    makes the code more robust.
    
    Fixes: bc64d05220f3 ("ath10k: debugfs support to get final TPC stats for 10.4 variants")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69ef9ca4677e0e83ef8dc08f4eec8c466d218ba9
Author: Baolin Wang <baolin.wang@linaro.org>
Date:   Fri Nov 16 19:01:10 2018 +0800

    power: supply: charger-manager: Fix incorrect return value
    
    commit f25a646fbe2051527ad9721853e892d13a99199e upstream.
    
    Fix incorrect return value.
    
    Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c5f91cc9b2e8d4637182e9b43124af31803abbe
Author: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Date:   Wed Mar 28 19:03:23 2018 +0200

    pwm-backlight: Enable/disable the PWM before/after LCD enable toggle.
    
    commit 5fb5caee92ba35a4a3baa61d45a78eb057e2c031 upstream.
    
    Before this patch the enable signal was set before the PWM signal and
    vice-versa on power off. This sequence is wrong, at least, it is on
    the different panels datasheets that I checked, so I inverted the sequence
    to follow the specs.
    
    For reference the following panels have the mentioned sequence:
      - N133HSE-EA1 (Innolux)
      - N116BGE (Innolux)
      - N156BGE-L21 (Innolux)
      - B101EAN0 (Auo)
      - B101AW03 (Auo)
      - LTN101NT05 (Samsung)
      - CLAA101WA01A (Chunghwa)
    
    Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
    Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
    Acked-by: Jingoo Han <jingoohan1@gmail.com>
    Acked-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 423f2c97a25392635216d349b85a4c2440de3a45
Author: Jules Maselbas <jules.maselbas@arm.com>
Date:   Thu Mar 29 15:43:01 2018 +0100

    sched/cpufreq/schedutil: Fix error path mutex unlock
    
    commit 1b5d43cfb69759d8ef8d30469cea31d0c037aed5 upstream.
    
    This patch prevents the 'global_tunables_lock' mutex from being
    unlocked before being locked.  This mutex is not locked if the
    sugov_kthread_create() function fails.
    
    Signed-off-by: Jules Maselbas <jules.maselbas@arm.com>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Chris Redpath <chris.redpath@arm.com>
    Cc: Dietmar Eggermann <dietmar.eggemann@arm.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Patrick Bellasi <patrick.bellasi@arm.com>
    Cc: Stephen Kyle <stephen.kyle@arm.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-kernel@vger.kernel.org
    Cc: nd@arm.com
    Link: http://lkml.kernel.org/r/20180329144301.38419-1-jules.maselbas@arm.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c492471db905b6c7c673ae5630dd0a27c8cd00b0
Author: Baolin Wang <baolin.wang@linaro.org>
Date:   Mon Dec 25 19:10:37 2017 +0800

    rtc: Fix overflow when converting time64_t to rtc_time
    
    commit 36d46cdb43efea74043e29e2a62b13e9aca31452 upstream.
    
    If we convert one large time values to rtc_time, in the original formula
    'days * 86400' can be overflowed in 'unsigned int' type to make the formula
    get one incorrect remain seconds value. Thus we can use div_s64_rem()
    function to avoid this situation.
    
    Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 421abdcc909322d6595504cf8d20c1adf74bc1cd
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date:   Thu Jan 11 14:00:57 2018 +0530

    PCI: endpoint: Use EPC's device in dma_alloc_coherent()/dma_free_coherent()
    
    commit b330104fa76df3eae6e199a23791fed5d35f06b4 upstream.
    
    After commit 723288836628 ("of: restrict DMA configuration"),
    of_dma_configure() doesn't configure the coherent_dma_mask/dma_mask
    of endpoint function device (since it doesn't have a DT node associated
    with and hence no dma-ranges property), resulting in
    dma_alloc_coherent() (used in pci_epf_alloc_space()) to fail.
    
    Fix it by making dma_alloc_coherent() use EPC's device for allocating
    memory address.
    
    Link: http://lkml.kernel.org/r/64d63468-d28f-8fcd-a6f3-cf2a6401c8cb@ti.com
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    [lorenzo.pieralisi@arm.com: tweaked commit log]
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: Rob Herring <robh@kernel.org>
    Cc: Christoph Hellwig <hch@lst.de>
    Tested-by: Cyrille Pitchen <cyrille.pitchen@free-electrons.com>
    Tested-by: Niklas Cassel <niklas.cassel@axis.com>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd913d610e214b97bba81b1b76883d0f29d63a37
Author: Niklas Cassel <niklas.cassel@axis.com>
Date:   Wed Dec 20 00:29:24 2017 +0100

    PCI: designware-ep: Read-only registers need DBI_RO_WR_EN to be writable
    
    commit 1cab826b30c6275d479a6ab1dea1067e15dbec62 upstream.
    
    Certain registers that pcie-designware-ep tries to write to are read-only
    registers. However, these registers can become read/write if we first
    enable the DBI_RO_WR_EN bit. Set/unset the DBI_RO_WR_EN bit before/after
    writing these registers.
    
    Tested-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
    Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Acked-by: Joao Pinto <jpinto@synopsys.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a9d76f59faffc0447701b902ed8322d35c45a983
Author: Niklas Cassel <niklas.cassel@axis.com>
Date:   Wed Dec 20 00:29:23 2017 +0100

    PCI: designware-ep: dw_pcie_ep_set_msi() should only set MMC bits
    
    commit 099a95f3591ade29da52131895a3ba9f92a0e82c upstream.
    
    Previously, dw_pcie_ep_set_msi() wrote all bits in the Message Control
    register, thus overwriting the PCI_MSI_FLAGS_64BIT bit.
    By clearing the PCI_MSI_FLAGS_64BIT bit, we break MSI
    on systems where the RC has set a 64 bit MSI address.
    Fix dw_pcie_ep_set_msi() so that it only sets MMC bits.
    
    Tested-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
    Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Acked-by: Joao Pinto <jpinto@synopsys.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4aac26ecb4ace3df840af95408f2279c85684f62
Author: kehuanlin <chgokhl@gmail.com>
Date:   Wed Sep 6 17:58:39 2017 +0800

    scsi: ufs: fix wrong command type of UTRD for UFSHCI v2.1
    
    commit 83dc7e3dea76b77b6bcc289eb86c5b5c145e8dff upstream.
    
    Since the command type of UTRD in UFS 2.1 specification is the same with
    UFS 2.0. And it assumes the future UFS specification will follow the
    same definition.
    
    Signed-off-by: kehuanlin <kehuanlin@pinecone.net>
    Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a4aed9055e8e8e6e7becf10821d5f2e1c90c3a8
Author: Andrey Konovalov <andreyknvl@google.com>
Date:   Mon Dec 11 22:48:41 2017 +0100

    USB: core: only clean up what we allocated
    
    commit 32fd87b3bbf5f7a045546401dfe2894dbbf4d8c3 upstream.
    
    When cleaning up the configurations, make sure we only free the number
    of configurations and interfaces that we could have allocated.
    
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aab86217763b06bcb563cb69dbbff8d598b52a39
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Nov 17 15:28:04 2017 -0800

    lib/int_sqrt: optimize small argument
    
    commit 3f3295709edea6268ff1609855f498035286af73 upstream.
    
    The current int_sqrt() computation is sub-optimal for the case of small
    @x.  Which is the interesting case when we're going to do cumulative
    distribution functions on idle times, which we assume to be a random
    variable, where the target residency of the deepest idle state gives an
    upper bound on the variable (5e6ns on recent Intel chips).
    
    In the case of small @x, the compute loop:
    
            while (m != 0) {
                    b = y + m;
                    y >>= 1;
    
                    if (x >= b) {
                            x -= b;
                            y += m;
                    }
                    m >>= 2;
            }
    
    can be reduced to:
    
            while (m > x)
                    m >>= 2;
    
    Because y==0, b==m and until x>=m y will remain 0.
    
    And while this is computationally equivalent, it runs much faster
    because there's less code, in particular less branches.
    
          cycles:                 branches:              branch-misses:
    
    OLD:
    
    hot:   45.109444 +- 0.044117  44.333392 +- 0.002254  0.018723 +- 0.000593
    cold: 187.737379 +- 0.156678  44.333407 +- 0.002254  6.272844 +- 0.004305
    
    PRE:
    
    hot:   67.937492 +- 0.064124  66.999535 +- 0.000488  0.066720 +- 0.001113
    cold: 232.004379 +- 0.332811  66.999527 +- 0.000488  6.914634 +- 0.006568
    
    POST:
    
    hot:   43.633557 +- 0.034373  45.333132 +- 0.002277  0.023529 +- 0.000681
    cold: 207.438411 +- 0.125840  45.333132 +- 0.002277  6.976486 +- 0.004219
    
    Averages computed over all values <128k using a LFSR to generate order.
    Cold numbers have a LFSR based branch trace buffer 'confuser' ran between
    each int_sqrt() invocation.
    
    Link: http://lkml.kernel.org/r/20171020164644.876503355@infradead.org
    Fixes: 30493cc9dddb ("lib/int_sqrt.c: optimize square root algorithm")
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Suggested-by: Anshul Garg <aksgarg1989@gmail.com>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Joe Perches <joe@perches.com>
    Cc: David Miller <davem@davemloft.net>
    Cc: Matthew Wilcox <mawilcox@microsoft.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Michael Davidson <md@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c622e33da8febc0de0512344cd5a35c17a7676f
Author: Hui Wang <hui.wang@canonical.com>
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 <hui.wang@canonical.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 886e8316b599a1f704f90e768547cc63725a8474
Author: Takashi Iwai <tiwai@suse.de>
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 <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a195a0bc2e954b91085d5c82eb20c51835ee7b0
Author: Waiman Long <longman@redhat.com>
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 <penguin-kernel@i-love.sakura.ne.jp>
    Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Reported-by: syzbot+53383ae265fb161ef488@syzkaller.appspotmail.com
    Signed-off-by: Waiman Long <longman@redhat.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Will Deacon <will.deacon@arm.com>
    Link: https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-longman@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5befc25f5cd2a1ec90bca48d4e03270b1005c70b
Author: Jann Horn <jannh@google.com>
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 <jannh@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Josh 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.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c60f18c6653fe6675bd66fb2b7008d3fc14e957a
Author: Jann Horn <jannh@google.com>
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 <jannh@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Josh 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.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b763bd262a792684cdca3040ad9f45106304df62
Author: Florian Westphal <fw@strlen.de>
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 <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f160d8dd684f8bb12f3a21bfe88ad37667246c4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Dec 30 12:28:42 2018 +0000

    drm: Reorder set_property_atomic to avoid returning with an active ww_ctx
    
    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: 144a7999d633 ("drm: Handle properties in the core for atomic drivers")
    Signed-off-by: Chris 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: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20181230122842.21917-1-chris@chris-wilson.co.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1dbb34da6f2edf321df5023cb2accd92579269b
Author: Kefeng Wang <wangkefeng.wang@huawei.com>
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: syzbot+899a33dc0fa0dbaf06a6@syzkaller.appspotmail.com
    Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
    Reviewed-by: Jeremy Cline <jcline@redhat.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ea83d9338c181de28ca60cbf221b0a4b94c4fd9
Author: Jeremy Cline <jcline@redhat.com>
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: syzbot+257790c15bcdef6fe00c@syzkaller.appspotmail.com
    Signed-off-by: Jeremy Cline <jcline@redhat.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3df00eb895f8ea16ccbfb6db49dc905f99ac9d17
Author: Myungho Jung <mhjungk@gmail.com>
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: syzbot+fdc00003f4efff43bc5b@syzkaller.appspotmail.com
    Signed-off-by: Myungho Jung <mhjungk@gmail.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86384a1fa3e5389e58d8a6673ed09143abe1354e
Author: Myungho Jung <mhjungk@gmail.com>
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: syzbot+017a32f149406df32703@syzkaller.appspotmail.com
    Signed-off-by: Myungho Jung <mhjungk@gmail.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3616a46e4622df40e2d9c1a22c305e769eff9775
Author: Hans Verkuil <hverkuil@xs4all.nl>
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 <hverkuil-cisco@xs4all.nl>
    Reported-by: syzbot+4f021cf3697781dbd9fb@syzkaller.appspotmail.com
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33fb49969357376c93a20ba6fd55087b8c181ae6
Author: zhangyi (F) <yi.zhang@huawei.com>
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 <hulkci@huawei.com>
    Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 766b823eafb885aaa25ac979f5e5a10f051c9634
Author: Lukas Czerner <lczerner@redhat.com>
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 <fsorenso@redhat.com>
    Signed-off-by: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Fixes: e9e3bcecf44c ("ext4: serialize unaligned asynchronous DIO")
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 03c5cdb620217763e3ef0012e54508f4ec6f88ef
Author: Jiufei Xue <jiufei.xue@linux.alibaba.com>
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 <jiufei.xue@linux.alibaba.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a37fe2be55b6c965e616f5d46e2490005355d427
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Oct 24 18:48:24 2018 +0300

    ALSA: x86: Fix runtime PM for hdmi-lpe-audio
    
    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: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20181024154825.18185-1-ville.syrjala@linux.intel.com
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Acked-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d431ba69113dd23256b5f23d98c06ceb5ef5f056
Author: Josh Poimboeuf <jpoimboe@redhat.com>
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 <moosotc@gmail.com>
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas 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.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 060c8899d4f992f35a5a0e9306e07da4160a270e
Author: Adrian Hunter <adrian.hunter@intel.com>
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 <adrian.hunter@intel.com>
    Tested-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Acked-by: Masami 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: 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/2ed432de-e904-85d2-5c36-5897ddc5b23b@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7e830047886221d314096183159cd52fc1d7a31
Author: Chen Jie <chenjie6@huawei.com>
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 <chenjie6@huawei.com>
    Signed-off-by: Thomas 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.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95712a194a80d54817a5edaf54cf761e002e6d55
Author: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
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: <stable@vger.kernel.org> # v2.6.12+
    Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d00ccc555ff606d6a9fc1473447946962fb54f0
Author: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
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: <stable@vger.kernel.org> # v4.10+
    Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88870813ee29e346b5e831987f677060fda384f9
Author: Archer Yan <ayan@wavecomp.com>
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 <ayan@wavecomp.com>
    Reviewed-by: Paul 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: Paul Burton <paul.burton@mips.com>
    Cc: linux-mips@vger.kernel.org
    Cc: stable@vger.kernel.org # v4.0+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 005b0a33163e4436e0d80d24d35d38f782fc80a7
Author: Yasha Cherikovsky <yasha.che3@gmail.com>
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 <yasha.che3@gmail.com>
    Signed-off-by: Paul 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3c6248c8a2ea18a151da77ea09bbbf7dc96ce59
Author: Yifeng Li <tomli@tomli.me>
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 <tomli@tomli.me>
    Signed-off-by: Paul 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a502107f716ba502d681d23afa779a28b83ca0f
Author: Jan Kara <jack@suse.cz>
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: stable@vger.kernel.org
    Reported-by: jean-luc malet <jeanluc.malet@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e5522ad5c1cca8848525721643f824cc651ca16
Author: Ilya Dryomov <idryomov@gmail.com>
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: stable@vger.kernel.org
    Fixes: 6305a3b41515 ("libceph: support for blacklisting clients")
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Jason Dillaman <dillaman@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e7b9a3143ad2a24c909351acecfdeafe17d0a9d
Author: Stanislaw Gruszka <sgruszka@redhat.com>
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: stable@vger.kernel.org
    Reported-and-tested-by: Jan Viktorin <jan.viktorin@gmail.com>
    Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Fixes: 80187fd39dcb ('iommu/amd: Optimize map_sg and unmap_sg')
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47248fde59a60a31a55d489f4851836f0ac94295
Author: Thomas Zimmermann <tzimmermann@suse.de>
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: <stable@vger.kernel.org>
    Fixes: a278724aa23c ("drm/vmwgfx: Implement fbdev on kms v2")
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Reviewed-by: Deepak Rawat <drawat@vmware.com>
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ce190bbca8cbacf3796aacad2f2f441725799d7
Author: Arnd Bergmann <arnd@arndb.de>
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 <arnd@arndb.de>
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Cc: stable@vger.kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>