commit 2a7cb228d29c3882c1414c10a44c5f3f59bfa44d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Dec 21 14:15:25 2018 +0100

    Linux 4.19.12

commit b4c7c826709b7d882ec9b264d5032e887e6bd720
Author: Omar Sandoval <osandov@fb.com>
Date:   Wed Oct 31 10:06:08 2018 -0700

    Btrfs: fix missing delayed iputs on unmount
    
    [ Upstream commit d6fd0ae25c6495674dc5a41a8d16bc8e0073276d ]
    
    There's a race between close_ctree() and cleaner_kthread().
    close_ctree() sets btrfs_fs_closing(), and the cleaner stops when it
    sees it set, but this is racy; the cleaner might have already checked
    the bit and could be cleaning stuff. In particular, if it deletes unused
    block groups, it will create delayed iputs for the free space cache
    inodes. As of "btrfs: don't run delayed_iputs in commit", we're no
    longer running delayed iputs after a commit. Therefore, if the cleaner
    creates more delayed iputs after delayed iputs are run in
    btrfs_commit_super(), we will leak inodes on unmount and get a busy
    inode crash from the VFS.
    
    Fix it by parking the cleaner before we actually close anything. Then,
    any remaining delayed iputs will always be handled in
    btrfs_commit_super(). This also ensures that the commit in close_ctree()
    is really the last commit, so we can get rid of the commit in
    cleaner_kthread().
    
    The fstest/generic/475 followed by 476 can trigger a crash that
    manifests as a slab corruption caused by accessing the freed kthread
    structure by a wake up function. Sample trace:
    
    [ 5657.077612] BUG: unable to handle kernel NULL pointer dereference at 00000000000000cc
    [ 5657.079432] PGD 1c57a067 P4D 1c57a067 PUD da10067 PMD 0
    [ 5657.080661] Oops: 0000 [#1] PREEMPT SMP
    [ 5657.081592] CPU: 1 PID: 5157 Comm: fsstress Tainted: G        W         4.19.0-rc8-default+ #323
    [ 5657.083703] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626cc-prebuilt.qemu-project.org 04/01/2014
    [ 5657.086577] RIP: 0010:shrink_page_list+0x2f9/0xe90
    [ 5657.091937] RSP: 0018:ffffb5c745c8f728 EFLAGS: 00010287
    [ 5657.092953] RAX: 0000000000000074 RBX: ffffb5c745c8f830 RCX: 0000000000000000
    [ 5657.094590] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff9a8747fdf3d0
    [ 5657.095987] RBP: ffffb5c745c8f9e0 R08: 0000000000000000 R09: 0000000000000000
    [ 5657.097159] R10: ffff9a8747fdf5e8 R11: 0000000000000000 R12: ffffb5c745c8f788
    [ 5657.098513] R13: ffff9a877f6ff2c0 R14: ffff9a877f6ff2c8 R15: dead000000000200
    [ 5657.099689] FS:  00007f948d853b80(0000) GS:ffff9a877d600000(0000) knlGS:0000000000000000
    [ 5657.101032] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 5657.101953] CR2: 00000000000000cc CR3: 00000000684bd000 CR4: 00000000000006e0
    [ 5657.103159] Call Trace:
    [ 5657.103776]  shrink_inactive_list+0x194/0x410
    [ 5657.104671]  shrink_node_memcg.constprop.84+0x39a/0x6a0
    [ 5657.105750]  shrink_node+0x62/0x1c0
    [ 5657.106529]  try_to_free_pages+0x1a4/0x500
    [ 5657.107408]  __alloc_pages_slowpath+0x2c9/0xb20
    [ 5657.108418]  __alloc_pages_nodemask+0x268/0x2b0
    [ 5657.109348]  kmalloc_large_node+0x37/0x90
    [ 5657.110205]  __kmalloc_node+0x236/0x310
    [ 5657.111014]  kvmalloc_node+0x3e/0x70
    
    Fixes: 30928e9baac2 ("btrfs: don't run delayed_iputs in commit")
    Signed-off-by: Omar Sandoval <osandov@fb.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    [ add trace ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f286ec243d3cf94674b7ffa281cbc2c09428a58
Author: Israel Rukshin <israelr@mellanox.com>
Date:   Wed Dec 5 16:54:57 2018 +0000

    nvmet-rdma: fix response use after free
    
    [ Upstream commit d7dcdf9d4e15189ecfda24cc87339a3425448d5c ]
    
    nvmet_rdma_release_rsp() may free the response before using it at error
    flow.
    
    Fixes: 8407879 ("nvmet-rdma: fix possible bogus dereference under heavy load")
    Signed-off-by: Israel Rukshin <israelr@mellanox.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2d58756858822778044de2a6a6f2e26bdc90873
Author: James Smart <jsmart2021@gmail.com>
Date:   Tue Nov 27 17:04:44 2018 -0800

    nvme: validate controller state before rescheduling keep alive
    
    [ Upstream commit 86880d646122240596d6719b642fee3213239994 ]
    
    Delete operations are seeing NULL pointer references in call_timer_fn.
    Tracking these back, the timer appears to be the keep alive timer.
    
    nvme_keep_alive_work() which is tied to the timer that is cancelled
    by nvme_stop_keep_alive(), simply starts the keep alive io but doesn't
    wait for it's completion. So nvme_stop_keep_alive() only stops a timer
    when it's pending. When a keep alive is in flight, there is no timer
    running and the nvme_stop_keep_alive() will have no affect on the keep
    alive io. Thus, if the io completes successfully, the keep alive timer
    will be rescheduled.   In the failure case, delete is called, the
    controller state is changed, the nvme_stop_keep_alive() is called while
    the io is outstanding, and the delete path continues on. The keep
    alive happens to successfully complete before the delete paths mark it
    as aborted as part of the queue termination, so the timer is restarted.
    The delete paths then tear down the controller, and later on the timer
    code fires and the timer entry is now corrupt.
    
    Fix by validating the controller state before rescheduling the keep
    alive. Testing with the fix has confirmed the condition above was hit.
    
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cab9d27671db270b9fb8f4ed5d3a52cbc94c6438
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Thu Dec 6 12:55:28 2018 +0900

    i2c: uniphier-f: fix violation of tLOW requirement for Fast-mode
    
    [ Upstream commit ece27a337d42a3197935711997f2880f0957ed7e ]
    
    Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode,
    tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us.
    
    tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode:
      Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us
      Fast-mode:     tLOW = 1.39 us, tHIGH = 1.11 us
    
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb296b2d315bcfaabe9dcd7c43b6795f1fd0f07a
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Thu Dec 6 12:55:27 2018 +0900

    i2c: uniphier: fix violation of tLOW requirement for Fast-mode
    
    [ Upstream commit 8469636ab5d8c77645b953746c10fda6983a8830 ]
    
    Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode,
    tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us.
    
    tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode:
      Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us
      Fast-mode:     tLOW = 1.39 us, tHIGH = 1.11 us
    
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d5db5becd74e2d968d846cf0818c0e3ddbad3d6
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Nov 21 10:19:55 2018 +0100

    i2c: scmi: Fix probe error on devices with an empty SMB0001 ACPI device node
    
    [ Upstream commit 0544ee4b1ad574aec3b6379af5f5cdee42840971 ]
    
    Some AMD based HP laptops have a SMB0001 ACPI device node which does not
    define any methods.
    
    This leads to the following error in dmesg:
    
    [    5.222731] cmi: probe of SMB0001:00 failed with error -5
    
    This commit makes acpi_smbus_cmi_add() return -ENODEV instead in this case
    silencing the error. In case of a failure of the i2c_add_adapter() call
    this commit now propagates the error from that call instead of -EIO.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9be9c23a507a52b864e8f1d9741d99fbc3572d59
Author: Adamski, Krzysztof (Nokia - PL/Wroclaw) <krzysztof.adamski@nokia.com>
Date:   Fri Nov 16 13:24:41 2018 +0000

    i2c: axxia: properly handle master timeout
    
    [ Upstream commit 6c7f25cae54b840302e4f1b371dbf318fbf09ab2 ]
    
    According to Intel (R) Axxia TM Lionfish Communication Processor
    Peripheral Subsystem Hardware Reference Manual, the AXXIA I2C module
    have a programmable Master Wait Timer, which among others, checks the
    time between commands send in manual mode. When a timeout (25ms) passes,
    TSS bit is set in Master Interrupt Status register and a Stop command is
    issued by the hardware.
    
    The axxia_i2c_xfer(), does not properly handle this situation, however.
    For each message a separate axxia_i2c_xfer_msg() is called and this
    function incorrectly assumes that any interrupt might happen only when
    waiting for completion. This is mostly correct but there is one
    exception - a master timeout can trigger if enough time has passed
    between individual transfers. It will, by definition, happen between
    transfers when the interrupts are disabled by the code. If that happens,
    the hardware issues Stop command.
    
    The interrupt indicating timeout will not be triggered as soon as we
    enable them since the Master Interrupt Status is cleared when master
    mode is entered again (which happens before enabling irqs) meaning this
    error is lost and the transfer is continued even though the Stop was
    issued on the bus. The subsequent operations completes without error but
    a bogus value (0xFF in case of read) is read as the client device is
    confused because aborted transfer. No error is returned from
    master_xfer() making caller believe that a valid value was read.
    
    To fix the problem, the TSS bit (indicating timeout) in Master Interrupt
    Status register is checked before each transfer. If it is set, there was
    a timeout before this transfer and (as described above) the hardware
    already issued Stop command so the transaction should be aborted thus
    -ETIMEOUT is returned from the master_xfer() callback. In order to be
    sure no timeout was issued we can't just read the status just before
    starting new transaction as there will always be a small window of time
    (few CPU cycles at best) where this might still happen. For this reason
    we have to temporally disable the timer before checking for TSS bit.
    Disabling it will, however, clear the TSS bit so in order to preserve
    that information, we have to read it in ISR so we have to ensure that
    the TSS interrupt is not masked between transfers of one transaction.
    There is no need to call bus recovery or controller reinitialization if
    that happens so it's skipped.
    
    Signed-off-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
    Reviewed-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8175f9d3978921a2e89d236fac2e07b64d59622d
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Thu Dec 6 17:44:53 2018 +0000

    mlxsw: spectrum_switchdev: Fix VLAN device deletion via ioctl
    
    [ Upstream commit 993107fea5eefdfdfde1ca38d3f01f0bebf76e77 ]
    
    When deleting a VLAN device using an ioctl the netdev is unregistered
    before the VLAN filter is updated via ndo_vlan_rx_kill_vid(). It can
    lead to a use-after-free in mlxsw in case the VLAN device is deleted
    while being enslaved to a bridge.
    
    The reason for the above is that when mlxsw receives the CHANGEUPPER
    event, it wrongly assumes that the VLAN device is no longer its upper
    and thus destroys the internal representation of the bridge port despite
    the reference count being non-zero.
    
    Fix this by checking if the VLAN device is our upper using its real
    device. In net-next I'm going to remove this trick and instead make
    mlxsw completely agnostic to the order of the events.
    
    Fixes: c57529e1d5d8 ("mlxsw: spectrum: Replace vPorts with Port-VLAN")
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reviewed-by: Petr Machata <petrm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50dc13e2b3c6d1187e4071838f82c16264b6015d
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date:   Thu Dec 6 19:14:34 2018 +0000

    vhost/vsock: fix reset orphans race with close timeout
    
    [ Upstream commit c38f57da428b033f2721b611d84b1f40bde674a8 ]
    
    If a local process has closed a connected socket and hasn't received a
    RST packet yet, then the socket remains in the table until a timeout
    expires.
    
    When a vhost_vsock instance is released with the timeout still pending,
    the socket is never freed because vhost_vsock has already set the
    SOCK_DONE flag.
    
    Check if the close timer is pending and let it close the socket.  This
    prevents the race which can leak sockets.
    
    Reported-by: Maximilian Riemensberger <riemensberger@cadami.net>
    Cc: Graham Whaley <graham.whaley@gmail.com>
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5a8028c25f3f3c3bbbe09646fe331a570189cbf
Author: Steve French <stfrench@microsoft.com>
Date:   Sat Nov 3 15:02:44 2018 -0500

    cifs: In Kconfig CONFIG_CIFS_POSIX needs depends on legacy (insecure cifs)
    
    [ Upstream commit 6e785302dad32228819d8066e5376acd15d0e6ba ]
    
    Missing a dependency.  Shouldn't show cifs posix extensions
    in Kconfig if CONFIG_CIFS_ALLOW_INSECURE_DIALECTS (ie SMB1
    protocol) is disabled.
    
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6a5c4948c2c6c8a288bf88b7937740d840c9d5e
Author: Sam Bobroff <sbobroff@linux.ibm.com>
Date:   Mon Dec 3 11:53:21 2018 +1100

    drm/ast: Fix connector leak during driver unload
    
    [ Upstream commit e594a5e349ddbfdaca1951bb3f8d72f3f1660d73 ]
    
    When unloading the ast driver, a warning message is printed by
    drm_mode_config_cleanup() because a reference is still held to one of
    the drm_connector structs.
    
    Correct this by calling drm_crtc_force_disable_all() in
    ast_fbdev_destroy().
    
    Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/1e613f3c630c7bbc72e04a44b178259b9164d2f6.1543798395.git.sbobroff@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 10197442f1fbddc95a397aed07a457bd66216fdb
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Mon Dec 3 10:30:25 2018 -0800

    acpi/nfit: Fix user-initiated ARS to be "ARS-long" rather than "ARS-short"
    
    [ Upstream commit b5fd2e00a60248902315fb32210550ac3cb9f44c ]
    
    A "short" ARS (address range scrub) instructs the platform firmware to
    return known errors. In contrast, a "long" ARS instructs platform
    firmware to arrange every data address on the DIMM to be read / checked
    for poisoned data.
    
    The conversion of the flags in commit d3abaf43bab8 "acpi, nfit: Fix
    Address Range Scrub completion tracking", changed the meaning of passing
    '0' to acpi_nfit_ars_rescan(). Previously '0' meant "not short", now '0'
    is ARS_REQ_SHORT. Pass ARS_REQ_LONG to restore the expected scrub-type
    behavior of user-initiated ARS sessions.
    
    Fixes: d3abaf43bab8 ("acpi, nfit: Fix Address Range Scrub completion tracking")
    Reported-by: Jacek Zloch <jacek.zloch@intel.com>
    Cc: Vishal Verma <vishal.l.verma@intel.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d689c1371d18eb00fd9d7233dcf795dfffc348ff
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Dec 5 14:11:48 2018 -0800

    tools/testing/nvdimm: Align test resources to 128M
    
    [ Upstream commit e3f5df762d4a6ef6326c3c09bc9f89ea8a2eab2c ]
    
    In preparation for libnvdimm growing new restrictions to detect section
    conflicts between persistent memory regions, enable nfit_test to
    allocate aligned resources. Use a gen_pool to allocate nfit_test's fake
    resources in a separate address space from the virtual translation of
    the same.
    
    Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
    Tested-by: Vishal Verma <vishal.l.verma@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 878275fa3e75d6ffd3062013526695a440283ed3
Author: James Zhu <James.Zhu@amd.com>
Date:   Mon Dec 3 22:04:28 2018 -0500

    drm/amdgpu/vcn: Update vcn.cur_state during suspend
    
    [ Upstream commit 0a9b89b2e2e7b6d90f81ddc47e489be1043e01b1 ]
    
    Replace vcn_v1_0_stop with vcn_v1_0_set_powergating_state during suspend,
    to keep adev->vcn.cur_state update. It will fix VCN S3 hung issue.
    
    Signed-off-by: James Zhu <James.Zhu@amd.com>
    Reviewed-by: Leo Liu <leo.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6a57a90b37140cc0c764f268f568660f0b9c70b
Author: Baruch Siach <baruch@tkos.co.il>
Date:   Tue Dec 4 16:03:53 2018 +0200

    net: mvpp2: fix phylink handling of invalid PHY modes
    
    [ Upstream commit 0fb628f0f250c74b1023edd0ca4a57c8b35b9b2c ]
    
    The .validate phylink callback should empty the supported bitmap when
    the interface mode is invalid.
    
    Cc: Maxime Chevallier <maxime.chevallier@bootlin.com>
    Cc: Antoine Tenart <antoine.tenart@bootlin.com>
    Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Baruch Siach <baruch@tkos.co.il>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f124acc92c839a862fb46a6cf049017f389a7637
Author: Baruch Siach <baruch@tkos.co.il>
Date:   Tue Dec 4 16:03:52 2018 +0200

    net: mvpp2: fix detection of 10G SFP modules
    
    [ Upstream commit 01b3fd5ac97caffb8e5d5bd85086da33db3b361f ]
    
    The mvpp2_phylink_validate() relies on the interface field of
    phylink_link_state to determine valid link modes. However, when called
    from phylink_sfp_module_insert() this field in not initialized. The
    default switch case then excludes 10G link modes. This allows 10G SFP
    modules that are detected correctly to be configured at max rate of
    2.5G.
    
    Catch the uninitialized PHY mode case, and allow 10G rates.
    
    Fixes: d97c9f4ab000b ("net: mvpp2: 1000baseX support")
    Cc: Maxime Chevallier <maxime.chevallier@bootlin.com>
    Cc: Antoine Tenart <antoine.tenart@bootlin.com>
    Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Baruch Siach <baruch@tkos.co.il>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 42d040e2c7b97ff2ff5c1cb5d097aa6a057d0ba2
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Fri Nov 9 16:44:14 2018 +0000

    thermal: armada: fix legacy validity test sense
    
    [ Upstream commit 70bb27b79adf63ea39e37371d09c823c7a8f93ce ]
    
    Commit 8c0e64ac4075 ("thermal: armada: get rid of the ->is_valid()
    pointer") removed the unnecessary indirection through a function
    pointer, but in doing so, also removed the negation operator too:
    
    -       if (priv->data->is_valid && !priv->data->is_valid(priv)) {
    +       if (armada_is_valid(priv)) {
    
    which results in:
    
    armada_thermal f06f808c.thermal: Temperature sensor reading not valid
    armada_thermal f2400078.thermal: Temperature sensor reading not valid
    armada_thermal f4400078.thermal: Temperature sensor reading not valid
    
    at boot, or whenever the "temp" sysfs file is read.  Replace the
    negation operator.
    
    Fixes: 8c0e64ac4075 ("thermal: armada: get rid of the ->is_valid() pointer")
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4c2efd8cf5d9138d83f772bab8f00d5f771c41a7
Author: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Date:   Mon Dec 3 13:21:01 2018 +0100

    ethernet: fman: fix wrong of_node_put() in probe function
    
    [ Upstream commit ecb239d96d369c23c33d41708646df646de669f4 ]
    
    After getting a reference to the platform device's of_node the probe
    function ends up calling of_find_matching_node() using the node as an
    argument. The function takes care of decreasing the refcount on it. We
    are then incorrectly decreasing the refcount on that node again.
    
    This patch removes the unwarranted call to of_node_put().
    
    Fixes: 414fd46e7762 ("fsl/fman: Add FMan support")
    Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80eaec9b94bccbd752b41523e160b63a4711a7f2
Author: Nathan Jones <nathanj439@gmail.com>
Date:   Tue Dec 4 10:05:32 2018 +0100

    ARM: 8816/1: dma-mapping: fix potential uninitialized return
    
    [ Upstream commit c2a3831df6dc164af66d8d86cf356a90c021b86f ]
    
    While trying to use the dma_mmap_*() interface, it was noticed that this
    interface returns strange values when passed an incorrect length.
    
    If neither of the if() statements fire then the return value is
    uninitialized. In the worst case it returns 0 which means the caller
    will think the function succeeded.
    
    Fixes: 1655cf8829d8 ("ARM: dma-mapping: Remove traces of NOMMU code")
    Signed-off-by: Nathan Jones <nathanj439@gmail.com>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Acked-by: Vladimir Murzin <vladimir.murzin@arm.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5cb9667104e8de4d0a7ae0a6e5647d7b9055cb94
Author: Vladimir Murzin <vladimir.murzin@arm.com>
Date:   Fri Nov 23 12:25:21 2018 +0100

    ARM: 8815/1: V7M: align v7m_dma_inv_range() with v7 counterpart
    
    [ Upstream commit 3d0358d0ba048c5afb1385787aaec8fa5ad78fcc ]
    
    Chris has discovered and reported that v7_dma_inv_range() may corrupt
    memory if address range is not aligned to cache line size.
    
    Since the whole cache-v7m.S was lifted form cache-v7.S the same
    observation applies to v7m_dma_inv_range(). So the fix just mirrors
    what has been done for v7 with a little specific of M-class.
    
    Cc: Chris Cole <chris@sageembedded.com>
    Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3d52556794c0ab021667b54551685d812d500ca
Author: Chris Cole <chris@sageembedded.com>
Date:   Fri Nov 23 12:20:45 2018 +0100

    ARM: 8814/1: mm: improve/fix ARM v7_dma_inv_range() unaligned address handling
    
    [ Upstream commit a1208f6a822ac29933e772ef1f637c5d67838da9 ]
    
    This patch addresses possible memory corruption when
    v7_dma_inv_range(start_address, end_address) address parameters are not
    aligned to whole cache lines. This function issues "invalidate" cache
    management operations to all cache lines from start_address (inclusive)
    to end_address (exclusive). When start_address and/or end_address are
    not aligned, the start and/or end cache lines are first issued "clean &
    invalidate" operation. The assumption is this is done to ensure that any
    dirty data addresses outside the address range (but part of the first or
    last cache lines) are cleaned/flushed so that data is not lost, which
    could happen if just an invalidate is issued.
    
    The problem is that these first/last partial cache lines are issued
    "clean & invalidate" and then "invalidate". This second "invalidate" is
    not required and worse can cause "lost" writes to addresses outside the
    address range but part of the cache line. If another component writes to
    its part of the cache line between the "clean & invalidate" and
    "invalidate" operations, the write can get lost. This fix is to remove
    the extra "invalidate" operation when unaligned addressed are used.
    
    A kernel module is available that has a stress test to reproduce the
    issue and a unit test of the updated v7_dma_inv_range(). It can be
    downloaded from
    http://ftp.sageembedded.com/outgoing/linux/cache-test-20181107.tgz.
    
    v7_dma_inv_range() is call by dmac_[un]map_area(addr, len, direction)
    when the direction is DMA_FROM_DEVICE. One can (I believe) successfully
    argue that DMA from a device to main memory should use buffers aligned
    to cache line size, because the "clean & invalidate" might overwrite
    data that the device just wrote using DMA. But if a driver does use
    unaligned buffers, at least this fix will prevent memory corruption
    outside the buffer.
    
    Signed-off-by: Chris Cole <chris@sageembedded.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ffd9f25c0e957ade0afb0a437cfc08cd31deffc
Author: Alexei Starovoitov <ast@kernel.org>
Date:   Mon Dec 3 22:46:04 2018 -0800

    bpf: check pending signals while verifying programs
    
    [ Upstream commit c3494801cd1785e2c25f1a5735fa19ddcf9665da ]
    
    Malicious user space may try to force the verifier to use as much cpu
    time and memory as possible. Hence check for pending signals
    while verifying the program.
    Note that suspend of sys_bpf(PROG_LOAD) syscall will lead to EAGAIN,
    since the kernel has to release the resources used for program verification.
    
    Reported-by: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Edward Cree <ecree@solarflare.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit efda3b1d90e50e9af078a7248909acfd8f13cc0a
Author: Saeed Mahameed <saeedm@mellanox.com>
Date:   Sun Dec 2 14:34:37 2018 +0200

    net/mlx4_en: Fix build break when CONFIG_INET is off
    
    [ Upstream commit 1b603f9e4313348608f256b564ed6e3d9e67f377 ]
    
    MLX4_EN depends on NETDEVICES, ETHERNET and INET Kconfigs.
    Make sure they are listed in MLX4_EN Kconfig dependencies.
    
    This fixes the following build break:
    
    drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18: warning: ‘struct iphdr’ declared inside parameter list [enabled by default]
    struct iphdr *iph)
    ^
    drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
    drivers/net/ethernet/mellanox/mlx4/en_rx.c: In function ‘get_fixed_ipv4_csum’:
    drivers/net/ethernet/mellanox/mlx4/en_rx.c:586:20: error: dereferencing pointer to incomplete type
    _u8 ipproto = iph->protocol;
    
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ae4046a124689e2808363bf5fe736b25ca6464d
Author: Anderson Luiz Alves <alacn1@gmail.com>
Date:   Fri Nov 30 21:58:36 2018 -0200

    mv88e6060: disable hardware level MAC learning
    
    [ Upstream commit a74515604a7b171f2702bdcbd1e231225fb456d0 ]
    
    Disable hardware level MAC learning because it breaks station roaming.
    When enabled it drops all frames that arrive from a MAC address
    that is on a different port at learning table.
    
    Signed-off-by: Anderson Luiz Alves <alacn1@gmail.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ef6e0fe383f797a5c492767b7ade124430e9018
Author: Matteo Croce <mcroce@redhat.com>
Date:   Sat Dec 1 00:26:27 2018 +0100

    macvlan: return correct error value
    
    [ Upstream commit 59f997b088d26a774958cb7b17b0763cd82de7ec ]
    
    A MAC address must be unique among all the macvlan devices with the same
    lower device. The only exception is the passthru [sic] mode,
    which shares the lower device address.
    
    When duplicate addresses are detected, EBUSY is returned when bringing
    the interface up:
    
        # ip link add macvlan0 link eth0 type macvlan
        # read addr </sys/class/net/eth0/address
        # ip link set macvlan0 address $addr
        # ip link set macvlan0 up
        RTNETLINK answers: Device or resource busy
    
    Use correct error code which is EADDRINUSE, and do the check also
    earlier, on address change:
    
        # ip link set macvlan0 address $addr
        RTNETLINK answers: Address already in use
    
    Signed-off-by: Matteo Croce <mcroce@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ed4392b0bb3e80bdf9d0bfeffc2651910951ff1
Author: Juha-Matti Tilli <juha-matti.tilli@iki.fi>
Date:   Sun Dec 2 12:47:08 2018 +0200

    libata: whitelist all SAMSUNG MZ7KM* solid-state disks
    
    [ Upstream commit fd6f32f78645db32b6b95a42e45da2ddd6de0e67 ]
    
    These devices support read zero after trim (RZAT), as they advertise to
    the OS. However, the OS doesn't believe the SSDs unless they are
    explicitly whitelisted.
    
    Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Juha-Matti Tilli <juha-matti.tilli@iki.fi>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62a866ed4c4860a2fbd3420f90660371324ae3e5
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Dec 3 11:24:30 2018 -0800

    Input: omap-keypad - fix keyboard debounce configuration
    
    [ Upstream commit 6c3516fed7b61a3527459ccfa67fab130d910610 ]
    
    I noticed that the Android v3.0.8 kernel on droid4 is using different
    keypad values from the mainline kernel and does not have issues with
    keys occasionally being stuck until pressed again. Turns out there was
    an earlier patch posted to fix this as "Input: omap-keypad: errata i689:
    Correct debounce time", but it was never reposted to fix use macros
    for timing calculations.
    
    This updated version is using macros, and also fixes the use of the
    input clock rate to use 32768KiHz instead of 32000KiHz. And we want to
    use the known good Android kernel values of 3 and 6 instead of 2 and 6
    in the earlier patch.
    
    Reported-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 65905f7b90332944c3baf6cbc45e1da50065f7ba
Author: Teika Kazura <teika@gmx.com>
Date:   Mon Dec 3 11:26:03 2018 -0800

    Input: synaptics - enable SMBus for HP 15-ay000
    
    [ Upstream commit 5a6dab15f7a79817cab4af612ddd99eda793fce6 ]
    
    SMBus works fine for the touchpad with id SYN3221, used in the HP 15-ay000
    series,
    
    This device has been reported in these messages in the "linux-input"
    mailing list:
    * https://marc.info/?l=linux-input&m=152016683003369&w=2
    * https://www.spinics.net/lists/linux-input/msg52525.html
    
    Reported-by: Nitesh Debnath <niteshkd1999@gmail.com>
    Reported-by: Teika Kazura <teika@gmx.com>
    Signed-off-by: Teika Kazura <teika@gmx.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e09f402321ebf81ac5ae1dd0b55e2265339706e
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Dec 3 17:51:43 2018 +0300

    clk: mmp: Off by one in mmp_clk_add()
    
    [ Upstream commit 2e85c57493e391b93445c1e0d530b36b95becc64 ]
    
    The > comparison should be >= or we write one element beyond the end of
    the unit->clk_table[] array.
    
    (The unit->clk_table[] array is allocated in the mmp_clk_init() function
    and it has unit->nr_clks elements).
    
    Fixes: 4661fda10f8b ("clk: mmp: add basic support functions for DT support")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70c8839464419610b969dbeb90d4f0bf854ec9a3
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Dec 3 17:50:55 2018 +0300

    clk: mvebu: Off by one bugs in cp110_of_clk_get()
    
    [ Upstream commit d9f5b7f5dd0fa74a89de5a7ac1e26366f211ccee ]
    
    These > comparisons should be >= to prevent reading beyond the end of
    of the clk_data->hws[] buffer.
    
    The clk_data->hws[] array is allocated in cp110_syscon_common_probe()
    when we do:
            cp110_clk_data = devm_kzalloc(dev, sizeof(*cp110_clk_data) +
                                          sizeof(struct clk_hw *) * CP110_CLK_NUM,
                                          GFP_KERNEL);
    As you can see, it has CP110_CLK_NUM elements which is equivalent to
    CP110_MAX_CORE_CLOCKS + CP110_MAX_GATABLE_CLOCKS.
    
    Fixes: d3da3eaef7f4 ("clk: mvebu: new driver for Armada CP110 system controller")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92bc065001a67af993c582f332d166c72109e499
Author: Evan Quan <evan.quan@amd.com>
Date:   Wed Nov 28 16:36:12 2018 +0800

    drm/amd/powerplay: issue pre-display settings for display change event
    
    [ Upstream commit 10cb3e6b63bf4266a5198813526fdd7259ffb8be ]
    
    For display config change event only, pre-display config settings are
    needed.
    
    Signed-off-by: Evan Quan <evan.quan@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee404810e01ed63c927e5667de9f40f2f1f0fd07
Author: Wen Yang <wen.yang99@zte.com.cn>
Date:   Thu Nov 29 14:01:50 2018 +0800

    drm/msm: Fix error return checking
    
    [ Upstream commit 098336deb946f37a70afc0979af388b615c378bf ]
    
    The error checks on ret for a negative error return always fails because
    the return value of iommu_map_sg() is unsigned and can never be negative.
    
    Detected with Coccinelle:
    drivers/gpu/drm/msm/msm_iommu.c:69:9-12: WARNING: Unsigned expression
    compared with zero: ret < 0
    
    Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
    CC: Rob Clark <robdclark@gmail.com>
    CC: David Airlie <airlied@linux.ie>
    CC: Julia Lawall <julia.lawall@lip6.fr>
    CC: linux-arm-msm@vger.kernel.org
    CC: dri-devel@lists.freedesktop.org
    CC: freedreno@lists.freedesktop.org
    CC: linux-kernel@vger.kernel.org
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 38b579de0b9ac3919475819d6fb2e543c5dbf5eb
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Fri Nov 16 19:25:26 2018 +0800

    drm/msm: dpu: Fix "WARNING: invalid free of devm_ allocated data"
    
    [ Upstream commit ce25aa3ee6939d83979cccf7adc5737cba9a0cb7 ]
    
    'dpu_enc' is a member of 'drm_enc'
    And 'drm_enc' got allocated with devm_kzalloc in dpu_encoder_init.
    
    This gives this error message:
    ./drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:459:1-6:
     WARNING: invalid free of devm_ allocated data
    
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7c819a03ae804839fc32314a6dd63ceaf329f4c
Author: Sean Paul <seanpaul@chromium.org>
Date:   Tue Oct 16 11:52:45 2018 -0400

    drm/msm: dpu: Don't set legacy plane->crtc pointer
    
    [ Upstream commit 081679c51ef2fd7b23cf9ddb7d775b17f75de18c ]
    
    It causes a WARN in drm_atomic_get_plane_state(), and is not used by
    atomic (or dpu).
    
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80f68af97440d05e2aea9b9b9d3da16e278ebb4f
Author: Todor Tomov <todor.tomov@linaro.org>
Date:   Fri Oct 19 17:07:22 2018 +0300

    drm/msm/hdmi: Enable HPD after HDMI IRQ is set up
    
    [ Upstream commit ee4456359640defe3f51cc6b728bfce4bc444c9e ]
    
    SoCs that contain MDP5 have a top level wrapper called MDSS that
    manages locks, power and irq for the sub-blocks within it.
    
    Irq for HDMI is also routed through the MDSS.
    
    Shortly after the Hot Plug Detection (HPD) is enabled in HDMI,
    HDMI interrupts are recieved by the MDSS interrupt handler.
    However at this moment the HDMI irq is still not mapped to
    the MDSS irq domain so the HDMI irq handler cannot be called
    to process the interrupts.
    
    This leads to a flood of HDMI interrupts on CPU 0.
    
    If we are lucky to have the HDMI initialization running on a
    different CPU, it will eventually map the HDMI irq to MDSS irq
    domain, the next HDMI interrupt will be handled by the HDMI irq
    handler, the interrupt flood will stop and we will recover.
    
    If the HDMI initialization is running on CPU 0, then it cannot
    complete and there is nothing to stop the interrupt flood on
    CPU 0. The system is stuck.
    
    Fix this by moving the HPD enablement after the HDMI irq is
    mapped to the MDSS irq domain.
    
    Signed-off-by: Todor Tomov <todor.tomov@linaro.org>
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 580fd7b5452c311f28c2e554e50d8cf335a96af3
Author: Yangtao Li <tiny.windzz@gmail.com>
Date:   Tue Nov 20 08:02:49 2018 -0500

    ide: pmac: add of_node_put()
    
    [ Upstream commit a51921c0db3fd26c4ed83dc0ec5d32988fa02aa5 ]
    
    use of_node_put() to release the refcount.
    
    Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b37b7d5b9086ed417bd0ac7eeb7f927346a059c9
Author: Yangtao Li <tiny.windzz@gmail.com>
Date:   Wed Nov 21 10:22:54 2018 -0500

    drivers/tty: add missing of_node_put()
    
    [ Upstream commit dac097c4546e4c5b16dd303a1e97c1d319c8ab3e ]
    
    of_find_node_by_path() acquires a reference to the node
    returned by it and that reference needs to be dropped by its caller.
    This place is not doing this, so fix it.
    
    Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78e974363bbc9371f51cec4faec340c517b1f311
Author: Yangtao Li <tiny.windzz@gmail.com>
Date:   Tue Nov 20 08:38:26 2018 -0500

    drivers/sbus/char: add of_node_put()
    
    [ Upstream commit 6bd520ab7cf69486ea81fd3cdfd2d5a390ad1100 ]
    
    use of_node_put() to release the refcount.
    
    Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 90d62a36352a679a9bfadaf2068b2f897409054e
Author: Yangtao Li <tiny.windzz@gmail.com>
Date:   Tue Nov 20 08:30:40 2018 -0500

    sbus: char: add of_node_put()
    
    [ Upstream commit 87d81a23e24f24ebe014891e8bdf3ff8785031e8 ]
    
    use of_node_put() to release the refcount.
    
    Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 20595815b058dc7d7ae9d16169e20407f71be2d6
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Sat Dec 1 23:18:00 2018 -0500

    SUNRPC: Fix a potential race in xprt_connect()
    
    [ Upstream commit 0a9a4304f3614e25d9de9b63502ca633c01c0d70 ]
    
    If an asynchronous connection attempt completes while another task is
    in xprt_connect(), then the call to rpc_sleep_on() could end up
    racing with the call to xprt_wake_pending_tasks().
    So add a second test of the connection state after we've put the
    task to sleep and set the XPRT_CONNECTING flag, when we know that there
    can be no asynchronous connection attempts still in progress.
    
    Fixes: 0b9e79431377d ("SUNRPC: Move the test for XPRT_CONNECTING into...")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de956d40781191903c7eb8e6843b0cb506ab1f43
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Tue Nov 27 19:31:30 2018 +0000

    nfs: don't dirty kernel pages read by direct-io
    
    [ Upstream commit ad3cba223ac02dc769c3bbe88efe277bbb457566 ]
    
    When we use direct_IO with an NFS backing store, we can trigger a
    WARNING in __set_page_dirty(), as below, since we're dirtying the page
    unnecessarily in nfs_direct_read_completion().
    
    To fix, replicate the logic in commit 53cbf3b157a0 ("fs: direct-io:
    don't dirtying pages for ITER_BVEC/ITER_KVEC direct read").
    
    Other filesystems that implement direct_IO handle this; most use
    blockdev_direct_IO(). ceph and cifs have similar logic.
    
    mount 127.0.0.1:/export /nfs
    dd if=/dev/zero of=/nfs/image bs=1M count=200
    losetup --direct-io=on -f /nfs/image
    mkfs.btrfs /dev/loop0
    mount -t btrfs /dev/loop0 /mnt/
    
    kernel: WARNING: CPU: 0 PID: 8067 at fs/buffer.c:580 __set_page_dirty+0xaf/0xd0
    kernel: Modules linked in: loop(E) nfsv3(E) rpcsec_gss_krb5(E) nfsv4(E) dns_resolver(E) nfs(E) fscache(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) fuse(E) tun(E) ip6t_rpfilter(E) ipt_REJECT(E) nf_
    kernel:  snd_seq(E) snd_seq_device(E) snd_pcm(E) video(E) snd_timer(E) snd(E) soundcore(E) ip_tables(E) xfs(E) libcrc32c(E) sd_mod(E) sr_mod(E) cdrom(E) ata_generic(E) pata_acpi(E) crc32c_intel(E) ahci(E) li
    kernel: CPU: 0 PID: 8067 Comm: kworker/0:2 Tainted: G            E     4.20.0-rc1.master.20181111.ol7.x86_64 #1
    kernel: Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
    kernel: Workqueue: nfsiod rpc_async_release [sunrpc]
    kernel: RIP: 0010:__set_page_dirty+0xaf/0xd0
    kernel: Code: c3 48 8b 02 f6 c4 04 74 d4 48 89 df e8 ba 05 f7 ff 48 89 c6 eb cb 48 8b 43 08 a8 01 75 1f 48 89 d8 48 8b 00 a8 04 74 02 eb 87 <0f> 0b eb 83 48 83 e8 01 eb 9f 48 83 ea 01 0f 1f 00 eb 8b 48 83 e8
    kernel: RSP: 0000:ffffc1c8825b7d78 EFLAGS: 00013046
    kernel: RAX: 000fffffc0020089 RBX: fffff2b603308b80 RCX: 0000000000000001
    kernel: RDX: 0000000000000001 RSI: ffff9d11478115c8 RDI: ffff9d11478115d0
    kernel: RBP: ffffc1c8825b7da0 R08: 0000646f6973666e R09: 8080808080808080
    kernel: R10: 0000000000000001 R11: 0000000000000000 R12: ffff9d11478115d0
    kernel: R13: ffff9d11478115c8 R14: 0000000000003246 R15: 0000000000000001
    kernel: FS:  0000000000000000(0000) GS:ffff9d115ba00000(0000) knlGS:0000000000000000
    kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    kernel: CR2: 00007f408686f640 CR3: 0000000104d8e004 CR4: 00000000000606f0
    kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    kernel: Call Trace:
    kernel:  __set_page_dirty_buffers+0xb6/0x110
    kernel:  set_page_dirty+0x52/0xb0
    kernel:  nfs_direct_read_completion+0xc4/0x120 [nfs]
    kernel:  nfs_pgio_release+0x10/0x20 [nfs]
    kernel:  rpc_free_task+0x30/0x70 [sunrpc]
    kernel:  rpc_async_release+0x12/0x20 [sunrpc]
    kernel:  process_one_work+0x174/0x390
    kernel:  worker_thread+0x4f/0x3e0
    kernel:  kthread+0x102/0x140
    kernel:  ? drain_workqueue+0x130/0x130
    kernel:  ? kthread_stop+0x110/0x110
    kernel:  ret_from_fork+0x35/0x40
    kernel: ---[ end trace 01341980905412c9 ]---
    
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    
    [forward-ported to v4.20]
    Signed-off-by: Calum Mackay <calum.mackay@oracle.com>
    Reviewed-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b0cf59188ec238b2110332d3ead4ac7910968403
Author: Pan Bian <bianpan2016@163.com>
Date:   Thu Nov 29 07:54:22 2018 +0800

    liquidio: read sc->iq_no before release sc
    
    [ Upstream commit c0f53771ba45745e5870daf880127925c93f232f ]
    
    The function lio_vf_rep_packet_sent_callback releases the occupation of
    sc via octeon_free_soft_command. sc should not be used after that.
    Unfortunately, sc->iq_no is read. To fix this, the patch stores sc->iq_no
    into a local variable before releasing sc and then uses the local variable
    instead of sc->iq_no.
    
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 85099bea974387501dcde072e2eccb7317ec59ee
Author: David Miller <davem@davemloft.net>
Date:   Wed Nov 28 22:33:53 2018 -0800

    bpf: Fix verifier log string check for bad alignment.
    
    [ Upstream commit c01ac66b38660f2b507ccd0b75d28e3002d56fbb ]
    
    The message got changed a lot time ago.
    
    This was responsible for 36 test case failures on sparc64.
    
    Fixes: f1174f77b50c ("bpf/verifier: rework value tracking")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aa4540d8cc87a51bb257984cbaf510f4961f5ffc
Author: Toni Peltonen <peltzi@peltzi.fi>
Date:   Tue Nov 27 16:56:57 2018 +0200

    bonding: fix 802.3ad state sent to partner when unbinding slave
    
    [ Upstream commit 3b5b3a3331d141e8f2a7aaae3a94dfa1e61ecbe4 ]
    
    Previously when unbinding a slave the 802.3ad implementation only told
    partner that the port is not suitable for aggregation by setting the port
    aggregation state from aggregatable to individual. This is not enough. If the
    physical layer still stays up and we only unbinded this port from the bond there
    is nothing in the aggregation status alone to prevent the partner from sending
    traffic towards us. To ensure that the partner doesn't consider this
    port at all anymore we should also disable collecting and distributing to
    signal that this actor is going away. Also clear AD_STATE_SYNCHRONIZATION to
    ensure partner exits collecting + distributing state.
    
    I have tested this behaviour againts Arista EOS switches with mlx5 cards
    (physical link stays up even when interface is down) and simulated
    the same situation virtually Linux <-> Linux with two network namespaces
    running two veth device pairs. In both cases setting aggregation to
    individual doesn't alone prevent traffic from being to sent towards this
    port given that the link stays up in partners end. Partner still keeps
    it's end in collecting + distributing state and continues until timeout is
    reached. In most cases this means we are losing the traffic partner sends
    towards our port while we wait for timeout. This is most visible with slow
    periodic time (LACP rate slow).
    
    Other open source implementations like Open VSwitch and libreswitch, and
    vendor implementations like Arista EOS, seem to disable collecting +
    distributing to when doing similar port disabling/detaching/removing change.
    With this patch kernel implementation would behave the same way and ensure
    partner doesn't consider our actor viable anymore.
    
    Signed-off-by: Toni Peltonen <peltzi@peltzi.fi>
    Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Acked-by: Jonathan Toppins <jtoppins@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43f5afa3eaae85126c8aa9140b89c88849337dbd
Author: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
Date:   Tue Nov 27 14:51:17 2018 +0000

    net: aquantia: fix rx checksum offload bits
    
    [ Upstream commit 37c4b91f955fdd5f4ad771956b97d35f1321098e ]
    
    The last set of csum offload fixes had a leak:
    
    Checksum enabled status bits from rx descriptor were incorrectly
    interpreted. Consequently all the other valid logic worked on zero bits.
    That caused rx checksum offloads never to trigger.
    
    Tested by dumping rx descriptors and validating resulting csum_level.
    
    Reported-by: Igor Russkikh <igor.russkikh@aquantia.com>
    Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
    Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
    Fixes: ad703c2b9127f ("net: aquantia: invalid checksumm offload implementation")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0df6d609c5d288e7557ac22af9e0f167216ae813
Author: Thierry Reding <treding@nvidia.com>
Date:   Tue Nov 27 14:21:43 2018 +0100

    net: stmmac: Move debugfs init/exit to ->probe()/->remove()
    
    [ Upstream commit 5f2b8b62786853341a20d4cd4948f9cbca3db002 ]
    
    Setting up and tearing down debugfs is current unbalanced, as seen by
    this error during resume from suspend:
    
        [  752.134067] dwc-eth-dwmac 2490000.ethernet eth0: ERROR failed to create debugfs directory
        [  752.134347] dwc-eth-dwmac 2490000.ethernet eth0: stmmac_hw_setup: failed debugFS registration
    
    The imbalance happens because the driver creates the debugfs hierarchy
    when the device is opened and tears it down when the device is closed.
    There's little gain in that, and it could be argued that it is even
    surprising because it's not usually done for other devices. Fix the
    imbalance by moving the debugfs creation and teardown to the driver's
    ->probe() and ->remove() implementations instead.
    
    Note that the ring descriptors cannot be read while the interface is
    down, so make sure to return an empty file when the descriptors_status
    debugfs file is read.
    
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Acked-by: Jose Abreu <joabreu@synopsys.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf69dc3cb1b8a72652ed44020678b6dbefa713fc
Author: Jose Abreu <joabreu@synopsys.com>
Date:   Fri Nov 30 09:47:31 2018 +0000

    ARC: io.h: Implement reads{x}()/writes{x}()
    
    [ Upstream commit 10d443431dc2bb733cf7add99b453e3fb9047a2e ]
    
    Some ARC CPU's do not support unaligned loads/stores. Currently, generic
    implementation of reads{b/w/l}()/writes{b/w/l}() is being used with ARC.
    This can lead to misfunction of some drivers as generic functions do a
    plain dereference of a pointer that can be unaligned.
    
    Let's use {get/put}_unaligned() helpers instead of plain dereference of
    pointer in order to fix. The helpers allow to get and store data from an
    unaligned address whilst preserving the CPU internal alignment.
    According to [1], the use of these helpers are costly in terms of
    performance so we added an initial check for a buffer already aligned so
    that the usage of the helpers can be avoided, when possible.
    
    [1] Documentation/unaligned-memory-access.txt
    
    Cc: Alexey Brodkin <abrodkin@synopsys.com>
    Cc: Joao Pinto <jpinto@synopsys.com>
    Cc: David Laight <David.Laight@ACULAB.COM>
    Tested-by: Vitor Soares <soares@synopsys.com>
    Signed-off-by: Jose Abreu <joabreu@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dbb0f9e74655a636f415c37dd66d92deb5237a65
Author: Christian König <christian.koenig@amd.com>
Date:   Fri Oct 26 15:59:05 2018 +0200

    drm/amdgpu: wait for IB test on first device open
    
    [ Upstream commit 3bfa8897e4d08f822d1d58cf6cbbffbccef82e08 ]
    
    Instead of delaying that to the first query. Otherwise we could try to use the
    SDMA for VM updates before the IB tests are done.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
    Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 546486c5b196423d7a2109583ae4c516954b2932
Author: Christian König <christian.koenig@amd.com>
Date:   Thu Nov 29 16:25:10 2018 +0100

    drm/ttm: fix LRU handling in ttm_buffer_object_transfer
    
    [ Upstream commit d6e820fcd4cf08b11d291a1dd7bbd0636914647c ]
    
    We need to set the NO_EVICT flag on the ghost object or otherwise we are
    adding it to the LRU.
    
    When it is added to the LRU we can run into a race between destroying
    and evicting it again.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01ba4fd989471609f84ff1cd1cc24e928d8cb3e6
Author: Sean Paul <seanpaul@chromium.org>
Date:   Wed Oct 3 16:22:31 2018 -0400

    drm/msm: Grab a vblank reference when waiting for commit_done
    
    [ Upstream commit 3b712e43e3876b42b38321ecf790a1f5fe59c834 ]
    
    Similar to the atomic helpers, we should enable vblank while we're
    waiting for the commit to finish. DPU needs this, MDP5 seems to work
    fine without it.
    
    Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 801f12d991bcbceff9f61e0380c34d51375f697c
Author: Abhinav Kumar <abhinavk@codeaurora.org>
Date:   Thu Jun 14 21:01:10 2018 -0700

    drm/msm/dsi: configure VCO rate for 10nm PLL driver
    
    [ Upstream commit 8531f0587f5c9e1a74cd9543a97617349f5e0706 ]
    
    Currenty the VCO rate in the 10nm PLL driver relies
    on the parent rate which is not configured.
    
    Configure the VCO rate to 19.2 Mhz as required by
    the 10nm PLL driver.
    
    Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d60ec2e702980d197a24819f7daa5c8671d55ec0
Author: Rob Clark <robdclark@gmail.com>
Date:   Mon Oct 15 11:22:57 2018 -0400

    drm/msm: fix handling of cmdstream offset
    
    [ Upstream commit 47e7f506ee6590ceb2efa1f08aca7f9f2ee5c1d3 ]
    
    Userspace hasn't used submit cmds with submit_offset != 0 for a while,
    but this starts cropping up again with cmdstream sub-buffer-allocation
    in libdrm_freedreno.
    
    Doesn't do much good to increment the buf ptr before assigning it.
    
    Fixes: 78b8e5b847b4 drm/msm: dump a rd GPUADDR header for all buffers in the command
    Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7de8218615d3f9dc82b2e0950e034e6fcc3a516e
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat Oct 13 13:28:06 2018 +0300

    drm/msm/gpu: Fix a couple memory leaks in debugfs
    
    [ Upstream commit 51270de91412b819f654b849db3bf92dac0a0855 ]
    
    The msm_gpu_open() function should free "show_priv" on error or it
    causes static checker warnings.
    
    Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU state")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 35516413ae5a3b3b133e34d072c2608706b5b585
Author: Sharat Masetty <smasetty@codeaurora.org>
Date:   Fri Oct 12 14:26:56 2018 +0530

    drm/msm: Fix task dump in gpu recovery
    
    [ Upstream commit 482f96324a4e08818db7d75bb12beaaea6c9561d ]
    
    The current recovery code gets a pointer to the task struct and does a
    few things all within the rcu_read_lock. This puts constraints on the
    types of gfp flags that can be used within the rcu lock. This patch
    instead gets a reference to the task within the rcu lock and releases
    the lock immediately, this way the task stays afloat until we need it and
    we also get to use the desired gfp flags.
    
    Signed-off-by: Sharat Masetty <smasetty@codeaurora.org>
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 985dea32ba5745bdf41aa2edd7cf86470ca8901b
Author: YiFei Zhu <zhuyifei1999@gmail.com>
Date:   Thu Nov 29 18:12:30 2018 +0100

    x86/earlyprintk/efi: Fix infinite loop on some screen widths
    
    [ Upstream commit 79c2206d369b87b19ac29cb47601059b6bf5c291 ]
    
    An affected screen resolution is 1366 x 768, which width is not
    divisible by 8, the default font width. On such screens, when longer
    lines are earlyprintk'ed, overflow-to-next-line can never trigger,
    due to the left-most x-coordinate of the next character always less
    than the screen width. Earlyprintk will infinite loop in trying to
    print the rest of the string but unable to, due to the line being
    full.
    
    This patch makes the trigger consider the right-most x-coordinate,
    instead of left-most, as the value to compare against the screen
    width threshold.
    
    Signed-off-by: YiFei Zhu <zhuyifei1999@gmail.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
    Cc: Bhupesh Sharma <bhsharma@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Eric Snowberg <eric.snowberg@oracle.com>
    Cc: Hans de Goede <hdegoede@redhat.com>
    Cc: Joe Perches <joe@perches.com>
    Cc: Jon Hunter <jonathanh@nvidia.com>
    Cc: Julien Thierry <julien.thierry@arm.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Matt Fleming <matt@codeblueprint.co.uk>
    Cc: Nathan Chancellor <natechancellor@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
    Cc: Sedat Dilek <sedat.dilek@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-efi@vger.kernel.org
    Link: http://lkml.kernel.org/r/20181129171230.18699-12-ard.biesheuvel@linaro.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3965b4f0c37f4bd92304c9cde538f02cd509ac2c
Author: Roman Li <Roman.Li@amd.com>
Date:   Tue Nov 27 17:16:37 2018 -0500

    drm/amd/display: Fix 6x4K displays light-up on Vega20 (v2)
    
    [ Upstream commit c6888879fd55b1ba903c2a770127edbf6aef6f27 ]
    
    [Why]
    More than 4x4K didn't lightup on Vega20 due to low dcfclk value.
    Powerplay expects valid min requirement for dcfclk from DC.
    
    [How]
    Update min_dcfclock_khz based on min_engine_clock value.
    
    v2: backport to 4.20 (Alex)
    
    Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
    Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
    Reviewed-by: Evan Quan <evan.quan@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Roman Li <Roman.Li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bdf7c4c84bea8be6403bf448a9da72f3cc8313ed
Author: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Date:   Thu Nov 29 17:08:37 2018 +0900

    net: ethernet: ave: Replace NET_IP_ALIGN with AVE_FRAME_HEADROOM
    
    [ Upstream commit 88113957ddb7b7d5451e28cd708c82ea7e63b097 ]
    
    In commit 26a4676faa1a ("arm64: mm: define NET_IP_ALIGN to 0"),
    AVE controller affects this modification because the controller forces
    to ignore lower 2bits of buffer start address, and make 2-byte headroom,
    that is, data reception starts from (buffer + 2).
    
    This patch defines AVE_FRAME_HEADROOM macro as hardware-specific value,
    and replaces NET_IP_ALIGN with it.
    
    Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 112a7f8e0540795ca80a42f061ab85cd6f1d5333
Author: Yonghong Song <yhs@fb.com>
Date:   Tue Nov 27 13:23:30 2018 -0800

    tools/bpf: add addition type tests to test_btf
    
    [ Upstream commit d08489125e04a9f73d9323caea43270fd22d395f ]
    
    The following additional unit testcases are added to test_btf:
    ...
    BTF raw test[42] (typedef (invalid name, name_off = 0)): OK
    BTF raw test[43] (typedef (invalid name, invalid identifier)): OK
    BTF raw test[44] (ptr type (invalid name, name_off <> 0)): OK
    BTF raw test[45] (volatile type (invalid name, name_off <> 0)): OK
    BTF raw test[46] (const type (invalid name, name_off <> 0)): OK
    BTF raw test[47] (restrict type (invalid name, name_off <> 0)): OK
    BTF raw test[48] (fwd type (invalid name, name_off = 0)): OK
    BTF raw test[49] (fwd type (invalid name, invalid identifier)): OK
    BTF raw test[50] (array type (invalid name, name_off <> 0)): OK
    BTF raw test[51] (struct type (name_off = 0)): OK
    BTF raw test[52] (struct type (invalid name, invalid identifier)): OK
    BTF raw test[53] (struct member (name_off = 0)): OK
    BTF raw test[54] (struct member (invalid name, invalid identifier)): OK
    BTF raw test[55] (enum type (name_off = 0)): OK
    BTF raw test[56] (enum type (invalid name, invalid identifier)): OK
    BTF raw test[57] (enum member (invalid name, name_off = 0)): OK
    BTF raw test[58] (enum member (invalid name, invalid identifier)): OK
    ...
    
    Fixes: c0fa1b6c3efc ("bpf: btf: Add BTF tests")
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Signed-off-by: Yonghong Song <yhs@fb.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b26fd26d69f55d9e54117dd79552c2ebacc00fa
Author: Martin KaFai Lau <kafai@fb.com>
Date:   Tue Nov 27 13:23:29 2018 -0800

    tools/bpf: fix two test_btf unit test cases
    
    [ Upstream commit 8800cd031af085807028656c6ba7eb7908d78262 ]
    
    There are two unit test cases, which should encode
    TYPEDEF type, but instead encode PTR type.
    The error is flagged out after enforcing name
    checking in the previous patch.
    
    Fixes: c0fa1b6c3efc ("bpf: btf: Add BTF tests")
    Signed-off-by: Martin KaFai Lau <kafai@fb.com>
    Signed-off-by: Yonghong Song <yhs@fb.com>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a58fb8346d3c24658c6b6cd25658cd7adace08c6
Author: Cathy Avery <cavery@redhat.com>
Date:   Tue Nov 27 14:28:53 2018 -0500

    scsi: vmw_pscsi: Rearrange code to avoid multiple calls to free_irq during unload
    
    [ Upstream commit 02f425f811cefcc4d325d7a72272651e622dc97e ]
    
    Currently pvscsi_remove calls free_irq more than once as
    pvscsi_release_resources and __pvscsi_shutdown both call
    pvscsi_shutdown_intr. This results in a 'Trying to free already-free IRQ'
    warning and stack trace. To solve the problem pvscsi_shutdown_intr has been
    moved out of pvscsi_release_resources.
    
    Signed-off-by: Cathy Avery <cavery@redhat.com>
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 13b968d59bb5b26c696af43ef9688f2989acf618
Author: Fred Herard <fred.herard@oracle.com>
Date:   Tue Nov 20 20:22:45 2018 -0500

    scsi: libiscsi: Fix NULL pointer dereference in iscsi_eh_session_reset
    
    [ Upstream commit 5db6dd14b31397e8cccaaddab2ff44ebec1acf25 ]
    
    This commit addresses NULL pointer dereference in iscsi_eh_session_reset.
    Reference should not be made to session->leadconn when session->state is
    set to ISCSI_STATE_TERMINATE.
    
    Signed-off-by: Fred Herard <fred.herard@oracle.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b288daf8e1da57ecc94d25dcf43bf32405be6a2e
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Tue Nov 13 12:15:42 2018 +0100

    i2c: rcar: check bus state before reinitializing
    
    [ Upstream commit 0b57436f15bf40e432487086c4f2d01fd3529393 ]
    
    We should check the bus state before reinitializing the IP core.
    Otherwise, the internal bus busy state which also tracks multi-master
    activity is lost.
    
    Credits go to the Renesas BSP team for suggesting this change.
    
    Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Fixes: ae481cc13965 ("i2c: rcar: fix resume by always initializing registers before transfer")
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 53e0d8ecc83f00612f18d9071e9e15d6ac252205
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Thu Nov 15 11:05:10 2018 -0800

    Input: hyper-v - fix wakeup from suspend-to-idle
    
    [ Upstream commit 10f91c73cc41ceead210a905dbd196398e99c7d2 ]
    
    It makes little sense but still possible to put Hyper-V guests into
    suspend-to-idle state. To wake them up two wakeup sources were registered
    in the past: hyperv-keyboard and hid-hyperv. However, since
    commit eed4d47efe95 ("ACPI / sleep: Ignore spurious SCI wakeups from
    suspend-to-idle") pm_wakeup_event() from these devices is ignored. Switch
    to pm_wakeup_hard_event() API as these devices are actually the only
    possible way to wakeup Hyper-V guests.
    
    Fixes: eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle)
    Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: K. Y. Srinivasan <kys@microsoft.com>
    Acked-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ff7d99c424ae7efc3b81497ab83345ff74d3a6b7
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Fri Oct 5 23:22:06 2018 +0300

    mac80211_hwsim: fix module init error paths for netlink
    
    [ Upstream commit 05cc09de4c017663a217630682041066f2f9a5cd ]
    
    There is no unregister netlink notifier and family on error paths
    in init_mac80211_hwsim(). Also there is an error path where
    hwsim_class is not destroyed.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Fixes: 62759361eb49 ("mac80211-hwsim: Provide multicast event for HWSIM_CMD_NEW_RADIO")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70b0baddd09bbbc7c0de5e30b9a6b35d8b6493d5
Author: Michael J. Ruhl <michael.j.ruhl@intel.com>
Date:   Tue Dec 18 16:00:22 2018 -0500

    IB/hfi1: Remove race conditions in user_sdma send path
    
    commit 28a9a9e83ceae2cee25b9af9ad20d53aaa9ab951 upstream
    
    Packet queue state is over used to determine SDMA descriptor
    availablitity and packet queue request state.
    
    cpu 0  ret = user_sdma_send_pkts(req, pcount);
    cpu 0  if (atomic_read(&pq->n_reqs))
    cpu 1  IRQ user_sdma_txreq_cb calls pq_update() (state to _INACTIVE)
    cpu 0        xchg(&pq->state, SDMA_PKT_Q_ACTIVE);
    
    At this point pq->n_reqs == 0 and pq->state is incorrectly
    SDMA_PKT_Q_ACTIVE.  The close path will hang waiting for the state
    to return to _INACTIVE.
    
    This can also change the state from _DEFERRED to _ACTIVE.  However,
    this is a mostly benign race.
    
    Remove the racy code path.
    
    Use n_reqs to determine if a packet queue is active or not.
    
    Cc: <stable@vger.kernel.org> # 4.19.x
    Reviewed-by: Mitko Haralanov <mitko.haralanov@intel.com>
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2658687568cd36cc1250106032d540454c0046c9
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Dec 18 18:48:28 2018 +0100

    locking/qspinlock, x86: Provide liveness guarantee
    
    commit 7aa54be2976550f17c11a1c3e3630002dea39303 upstream.
    
    On x86 we cannot do fetch_or() with a single instruction and thus end up
    using a cmpxchg loop, this reduces determinism. Replace the fetch_or()
    with a composite operation: tas-pending + load.
    
    Using two instructions of course opens a window we previously did not
    have. Consider the scenario:
    
            CPU0            CPU1            CPU2
    
     1)     lock
              trylock -> (0,0,1)
    
     2)                     lock
                              trylock /* fail */
    
     3)     unlock -> (0,0,0)
    
     4)                                     lock
                                              trylock -> (0,0,1)
    
     5)                       tas-pending -> (0,1,1)
                              load-val <- (0,1,0) from 3
    
     6)                       clear-pending-set-locked -> (0,0,1)
    
                              FAIL: _2_ owners
    
    where 5) is our new composite operation. When we consider each part of
    the qspinlock state as a separate variable (as we can when
    _Q_PENDING_BITS == 8) then the above is entirely possible, because
    tas-pending will only RmW the pending byte, so the later load is able
    to observe prior tail and lock state (but not earlier than its own
    trylock, which operates on the whole word, due to coherence).
    
    To avoid this we need 2 things:
    
     - the load must come after the tas-pending (obviously, otherwise it
       can trivially observe prior state).
    
     - the tas-pending must be a full word RmW instruction, it cannot be an XCHGB for
       example, such that we cannot observe other state prior to setting
       pending.
    
    On x86 we can realize this by using "LOCK BTS m32, r32" for
    tas-pending followed by a regular load.
    
    Note that observing later state is not a problem:
    
     - if we fail to observe a later unlock, we'll simply spin-wait for
       that store to become visible.
    
     - if we observe a later xchg_tail(), there is no difference from that
       xchg_tail() having taken place before the tas-pending.
    
    Suggested-by: Will Deacon <will.deacon@arm.com>
    Reported-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Will Deacon <will.deacon@arm.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: andrea.parri@amarulasolutions.com
    Cc: longman@redhat.com
    Fixes: 59fb586b4a07 ("locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath")
    Link: https://lkml.kernel.org/r/20181003130957.183726335@infradead.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bigeasy: GEN_BINARY_RMWcc macro redo]
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 150f038c9382e92de446caee1754d65c47127341
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Dec 18 18:48:27 2018 +0100

    locking/qspinlock: Re-order code
    
    commit 53bf57fab7321fb42b703056a4c80fc9d986d170 upstream.
    
    Flip the branch condition after atomic_fetch_or_acquire(_Q_PENDING_VAL)
    such that we loose the indent. This also result in a more natural code
    flow IMO.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Will Deacon <will.deacon@arm.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: andrea.parri@amarulasolutions.com
    Cc: longman@redhat.com
    Link: https://lkml.kernel.org/r/20181003130257.156322446@infradead.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>