commit e692f66fab3019ca8f45463df165177505f38caa
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jul 3 11:23:18 2018 +0200

    Linux 4.9.111

commit 35fd10aeb2248cc7f8d3d48ccc2eff1cf19918f4
Author: Bjørn Mork <bjorn@mork.no>
Date:   Fri Jun 8 09:15:24 2018 +0200

    cdc_ncm: avoid padding beyond end of skb
    
    commit 49c2c3f246e2fc3009039e31a826333dcd0283cd upstream.
    
    Commit 4a0e3e989d66 ("cdc_ncm: Add support for moving NDP to end
    of NCM frame") added logic to reserve space for the NDP at the
    end of the NTB/skb.  This reservation did not take the final
    alignment of the NDP into account, causing us to reserve too
    little space. Additionally the padding prior to NDP addition did
    not ensure there was enough space for the NDP.
    
    The NTB/skb with the NDP appended would then exceed the configured
    max size. This caused the final padding of the NTB to use a
    negative count, padding to almost INT_MAX, and resulting in:
    
    [60103.825970] BUG: unable to handle kernel paging request at ffff9641f2004000
    [60103.825998] IP: __memset+0x24/0x30
    [60103.826001] PGD a6a06067 P4D a6a06067 PUD 4f65a063 PMD 72003063 PTE 0
    [60103.826013] Oops: 0002 [#1] SMP NOPTI
    [60103.826018] Modules linked in: (removed(
    [60103.826158] CPU: 0 PID: 5990 Comm: Chrome_DevTools Tainted: G           O 4.14.0-3-amd64 #1 Debian 4.14.17-1
    [60103.826162] Hardware name: LENOVO 20081 BIOS 41CN28WW(V2.04) 05/03/2012
    [60103.826166] task: ffff964193484fc0 task.stack: ffffb2890137c000
    [60103.826171] RIP: 0010:__memset+0x24/0x30
    [60103.826174] RSP: 0000:ffff964316c03b68 EFLAGS: 00010216
    [60103.826178] RAX: 0000000000000000 RBX: 00000000fffffffd RCX: 000000001ffa5000
    [60103.826181] RDX: 0000000000000005 RSI: 0000000000000000 RDI: ffff9641f2003ffc
    [60103.826184] RBP: ffff964192f6c800 R08: 00000000304d434e R09: ffff9641f1d2c004
    [60103.826187] R10: 0000000000000002 R11: 00000000000005ae R12: ffff9642e6957a80
    [60103.826190] R13: ffff964282ff2ee8 R14: 000000000000000d R15: ffff9642e4843900
    [60103.826194] FS:  00007f395aaf6700(0000) GS:ffff964316c00000(0000) knlGS:0000000000000000
    [60103.826197] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [60103.826200] CR2: ffff9641f2004000 CR3: 0000000013b0c000 CR4: 00000000000006f0
    [60103.826204] Call Trace:
    [60103.826212]  <IRQ>
    [60103.826225]  cdc_ncm_fill_tx_frame+0x5e3/0x740 [cdc_ncm]
    [60103.826236]  cdc_ncm_tx_fixup+0x57/0x70 [cdc_ncm]
    [60103.826246]  usbnet_start_xmit+0x5d/0x710 [usbnet]
    [60103.826254]  ? netif_skb_features+0x119/0x250
    [60103.826259]  dev_hard_start_xmit+0xa1/0x200
    [60103.826267]  sch_direct_xmit+0xf2/0x1b0
    [60103.826273]  __dev_queue_xmit+0x5e3/0x7c0
    [60103.826280]  ? ip_finish_output2+0x263/0x3c0
    [60103.826284]  ip_finish_output2+0x263/0x3c0
    [60103.826289]  ? ip_output+0x6c/0xe0
    [60103.826293]  ip_output+0x6c/0xe0
    [60103.826298]  ? ip_forward_options+0x1a0/0x1a0
    [60103.826303]  tcp_transmit_skb+0x516/0x9b0
    [60103.826309]  tcp_write_xmit+0x1aa/0xee0
    [60103.826313]  ? sch_direct_xmit+0x71/0x1b0
    [60103.826318]  tcp_tasklet_func+0x177/0x180
    [60103.826325]  tasklet_action+0x5f/0x110
    [60103.826332]  __do_softirq+0xde/0x2b3
    [60103.826337]  irq_exit+0xae/0xb0
    [60103.826342]  do_IRQ+0x81/0xd0
    [60103.826347]  common_interrupt+0x98/0x98
    [60103.826351]  </IRQ>
    [60103.826355] RIP: 0033:0x7f397bdf2282
    [60103.826358] RSP: 002b:00007f395aaf57d8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff6e
    [60103.826362] RAX: 0000000000000000 RBX: 00002f07bc6d0900 RCX: 00007f39752d7fe7
    [60103.826365] RDX: 0000000000000022 RSI: 0000000000000147 RDI: 00002f07baea02c0
    [60103.826368] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
    [60103.826371] R10: 00000000ffffffff R11: 0000000000000000 R12: 00002f07baea02c0
    [60103.826373] R13: 00002f07bba227a0 R14: 00002f07bc6d090c R15: 0000000000000000
    [60103.826377] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 f9 48 89 d1 83
    e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 <f3> 48
    ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1
    [60103.826442] RIP: __memset+0x24/0x30 RSP: ffff964316c03b68
    [60103.826444] CR2: ffff9641f2004000
    
    Commit e1069bbfcf3b ("net: cdc_ncm: Reduce memory use when kernel
    memory low") made this bug much more likely to trigger by reducing
    the NTB size under memory pressure.
    
    Link: https://bugs.debian.org/893393
    Reported-by: Горбешко Богдан <bodqhrohro@gmail.com>
    Reported-and-tested-by: Dennis Wassenberg <dennis.wassenberg@secunet.com>
    Cc: Enrico Mioso <mrkiko.rs@gmail.com>
    Fixes: 4a0e3e989d66 ("cdc_ncm: Add support for moving NDP to end of NCM frame")
    [ bmork:  tx_curr_size => tx_max and context fixup for v4.12 and older ]
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2bc5d18d26350423446fcc073ad8750c20ec498
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Tue Jun 26 12:04:23 2018 -0400

    dm thin: handle running out of data space vs concurrent discard
    
    commit a685557fbbc3122ed11e8ad3fa63a11ebc5de8c3 upstream.
    
    Discards issued to a DM thin device can complete to userspace (via
    fstrim) _before_ the metadata changes associated with the discards is
    reflected in the thinp superblock (e.g. free blocks).  As such, if a
    user constructs a test that loops repeatedly over these steps, block
    allocation can fail due to discards not having completed yet:
    1) fill thin device via filesystem file
    2) remove file
    3) fstrim
    
    From initial report, here:
    https://www.redhat.com/archives/dm-devel/2018-April/msg00022.html
    
    "The root cause of this issue is that dm-thin will first remove
    mapping and increase corresponding blocks' reference count to prevent
    them from being reused before DISCARD bios get processed by the
    underlying layers. However. increasing blocks' reference count could
    also increase the nr_allocated_this_transaction in struct sm_disk
    which makes smd->old_ll.nr_allocated +
    smd->nr_allocated_this_transaction bigger than smd->old_ll.nr_blocks.
    In this case, alloc_data_block() will never commit metadata to reset
    the begin pointer of struct sm_disk, because sm_disk_get_nr_free()
    always return an underflow value."
    
    While there is room for improvement to the space-map accounting that
    thinp is making use of: the reality is this test is inherently racey and
    will result in the previous iteration's fstrim's discard(s) completing
    vs concurrent block allocation, via dd, in the next iteration of the
    loop.
    
    No amount of space map accounting improvements will be able to allow
    user's to use a block before a discard of that block has completed.
    
    So the best we can really do is allow DM thinp to gracefully handle such
    aggressive use of all the pool's data by degrading the pool into
    out-of-data-space (OODS) mode.  We _should_ get that behaviour already
    (if space map accounting didn't falsely cause alloc_data_block() to
    believe free space was available).. but short of that we handle the
    current reality that dm_pool_alloc_data_block() can return -ENOSPC.
    
    Reported-by: Dennis Yang <dennisyang@qnap.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17057c59bd11911cff0f62715efcb556bab05ade
Author: Keith Busch <keith.busch@intel.com>
Date:   Tue Jun 26 09:14:58 2018 -0600

    block: Fix transfer when chunk sectors exceeds max
    
    commit 15bfd21fbc5d35834b9ea383dc458a1f0c9e3434 upstream.
    
    A device may have boundary restrictions where the number of sectors
    between boundaries exceeds its max transfer size. In this case, we need
    to cap the max size to the smaller of the two limits.
    
    Reported-by: Jitendra Bhivare <jitendra.bhivare@broadcom.com>
    Tested-by: Jitendra Bhivare <jitendra.bhivare@broadcom.com>
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Keith Busch <keith.busch@intel.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afd82d0757b37a346fbc557c5974c0f0de1bb0d2
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Jun 22 12:17:45 2018 +0200

    ALSA: hda/realtek - Add a quirk for FSC ESPRIMO U9210
    
    commit 275ec0cb946cb75ac8977f662e608fce92f8b8a8 upstream.
    
    Fujitsu Seimens ESPRIMO Mobile U9210 requires the same fixup as H270
    for the correct pin configs.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200107
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6008de291a2beab8028d04df9b0ea930e4fe4ce0
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jun 13 12:43:10 2018 +0200

    ALSA: hda/realtek - Fix pop noise on Lenovo P50 & co
    
    commit d5a6cabf02210b896a60eee7c04c670ee9ba6dca upstream.
    
    Some Lenovo laptops, e.g. Lenovo P50, showed the pop noise at resume
    or runtime resume.  It turned out to be reduced by applying
    alc_no_shutup() just like TPT440 quirk does.
    
    Since there are many Lenovo models showing the same behavior, put this
    workaround in ALC269_FIXUP_THINKPAD_ACPI entry so that it's applied
    commonly to all such Lenovo machines.
    
    Reported-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Benjamin Berg <bberg@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58d8103113ea911ed23cfd31c866f14c43773fb7
Author: ??? <kt.liao@emc.com.tw>
Date:   Thu Jun 21 17:15:32 2018 -0700

    Input: elantech - fix V4 report decoding for module with middle key
    
    commit e0ae2519ca004a628fa55aeef969c37edce522d3 upstream.
    
    Some touchpad has middle key and it will be indicated in bit 2 of packet[0].
    We need to fix V4 formation's byte mask to prevent error decoding.
    
    Signed-off-by: KT Liao <kt.liao@emc.com.tw>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 465e965f64358fdeeb35287bd7a6dc06b261fb7b
Author: Aaron Ma <aaron.ma@canonical.com>
Date:   Thu Jun 21 17:14:01 2018 -0700

    Input: elantech - enable middle button of touchpads on ThinkPad P52
    
    commit 24bb555e6e46d96e2a954aa0295029a81cc9bbaa upstream.
    
    PNPID is better way to identify the type of touchpads.
    Enable middle button support on 2 types of touchpads on Lenovo P52.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54ae564b35423f25b763bc9e01b489d9f11c034e
Author: Ben Hutchings <ben.hutchings@codethink.co.uk>
Date:   Tue Jun 19 11:17:32 2018 -0700

    Input: elan_i2c_smbus - fix more potential stack buffer overflows
    
    commit 50fc7b61959af4b95fafce7fe5dd565199e0b61a upstream.
    
    Commit 40f7090bb1b4 ("Input: elan_i2c_smbus - fix corrupted stack")
    fixed most of the functions using i2c_smbus_read_block_data() to
    allocate a buffer with the maximum block size.  However three
    functions were left unchanged:
    
    * In elan_smbus_initialize(), increase the buffer size in the same
      way.
    * In elan_smbus_calibrate_result(), the buffer is provided by the
      caller (calibrate_store()), so introduce a bounce buffer.  Also
      name the result buffer size.
    * In elan_smbus_get_report(), the buffer is provided by the caller
      but happens to be the right length.  Add a compile-time assertion
      to ensure this remains the case.
    
    Cc: <stable@vger.kernel.org> # 3.19+
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a1b1234d0502237872f6a11016061328528b86d
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jun 13 12:09:22 2018 +0200

    udf: Detect incorrect directory size
    
    commit fa65653e575fbd958bdf5fb9c4a71a324e39510d upstream.
    
    Detect when a directory entry is (possibly partially) beyond directory
    size and return EIO in that case since it means the filesystem is
    corrupted. Otherwise directory operations can further corrupt the
    directory and possibly also oops the kernel.
    
    CC: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
    CC: stable@vger.kernel.org
    Reported-and-tested-by: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3cac26f2a2c66f755e033ca944d02433be684556
Author: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date:   Thu Jun 21 13:29:44 2018 -0400

    xen: Remove unnecessary BUG_ON from __unbind_from_irq()
    
    commit eef04c7b3786ff0c9cb1019278b6c6c2ea0ad4ff upstream.
    
    Commit 910f8befdf5b ("xen/pirq: fix error path cleanup when binding
    MSIs") fixed a couple of errors in error cleanup path of
    xen_bind_pirq_msi_to_irq(). This cleanup allowed a call to
    __unbind_from_irq() with an unbound irq, which would result in
    triggering the BUG_ON there.
    
    Since there is really no reason for the BUG_ON (xen_free_irq() can
    operate on unbound irqs) we can remove it.
    
    Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d28f2d64cf5ddf6c55f7a3a954dd9a34b72862b
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Jun 14 15:26:24 2018 -0700

    mm: fix devmem_is_allowed() for sub-page System RAM intersections
    
    commit 2bdce74412c249ac01dfe36b6b0043ffd7a5361e upstream.
    
    Hussam reports:
    
        I was poking around and for no real reason, I did cat /dev/mem and
        strings /dev/mem.  Then I saw the following warning in dmesg. I saved it
        and rebooted immediately.
    
         memremap attempted on mixed range 0x000000000009c000 size: 0x1000
         ------------[ cut here ]------------
         WARNING: CPU: 0 PID: 11810 at kernel/memremap.c:98 memremap+0x104/0x170
         [..]
         Call Trace:
          xlate_dev_mem_ptr+0x25/0x40
          read_mem+0x89/0x1a0
          __vfs_read+0x36/0x170
    
    The memremap() implementation checks for attempts to remap System RAM
    with MEMREMAP_WB and instead redirects those mapping attempts to the
    linear map.  However, that only works if the physical address range
    being remapped is page aligned.  In low memory we have situations like
    the following:
    
        00000000-00000fff : Reserved
        00001000-0009fbff : System RAM
        0009fc00-0009ffff : Reserved
    
    ...where System RAM intersects Reserved ranges on a sub-page page
    granularity.
    
    Given that devmem_is_allowed() special cases any attempt to map System
    RAM in the first 1MB of memory, replace page_is_ram() with the more
    precise region_intersects() to trap attempts to map disallowed ranges.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=199999
    Link: http://lkml.kernel.org/r/152856436164.18127.2847888121707136898.stgit@dwillia2-desk3.amr.corp.intel.com
    Fixes: 92281dee825f ("arch: introduce memremap()")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Reported-by: Hussam Al-Tayeb <me@hussam.eu.org>
    Tested-by: Hussam Al-Tayeb <me@hussam.eu.org>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f00b1fc77752bb27b6b696fd7fceeda921ac0fa
Author: Dongsheng Yang <dongsheng.yang@easystack.cn>
Date:   Mon Jun 4 06:24:37 2018 -0400

    rbd: flush rbd_dev->watch_dwork after watch is unregistered
    
    commit 23edca864951250af845a11da86bb3ea63522ed2 upstream.
    
    There is a problem if we are going to unmap a rbd device and the
    watch_dwork is going to queue delayed work for watch:
    
    unmap Thread                    watch Thread                  timer
    do_rbd_remove
      cancel_tasks_sync(rbd_dev)
                                    queue_delayed_work for watch
      destroy_workqueue(rbd_dev->task_wq)
        drain_workqueue(wq)
        destroy other resources in wq
                                                                  call_timer_fn
                                                                    __queue_work()
    
    Then the delayed work escape the cancel_tasks_sync() and
    destroy_workqueue() and we will get an user-after-free call trace:
    
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
      PGD 0 P4D 0
      Oops: 0000 [#1] SMP PTI
      Modules linked in:
      CPU: 7 PID: 0 Comm: swapper/7 Tainted: G           OE     4.17.0-rc6+ #13
      Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
      RIP: 0010:__queue_work+0x6a/0x3b0
      RSP: 0018:ffff9427df1c3e90 EFLAGS: 00010086
      RAX: ffff9427deca8400 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: ffff9427deca8400 RSI: ffff9427df1c3e50 RDI: 0000000000000000
      RBP: ffff942783e39e00 R08: ffff9427deca8400 R09: ffff9427df1c3f00
      R10: 0000000000000004 R11: 0000000000000005 R12: ffff9427cfb85970
      R13: 0000000000002000 R14: 000000000001eca0 R15: 0000000000000007
      FS:  0000000000000000(0000) GS:ffff9427df1c0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 00000004c900a005 CR4: 00000000000206e0
      Call Trace:
       <IRQ>
       ? __queue_work+0x3b0/0x3b0
       call_timer_fn+0x2d/0x130
       run_timer_softirq+0x16e/0x430
       ? tick_sched_timer+0x37/0x70
       __do_softirq+0xd2/0x280
       irq_exit+0xd5/0xe0
       smp_apic_timer_interrupt+0x6c/0x130
       apic_timer_interrupt+0xf/0x20
    
    [ Move rbd_dev->watch_dwork cancellation so that rbd_reregister_watch()
      either bails out early because the watch is UNREGISTERED at that point
      or just gets cancelled. ]
    
    Cc: stable@vger.kernel.org
    Fixes: 99d1694310df ("rbd: retry watch re-registration periodically")
    Signed-off-by: Dongsheng Yang <dongsheng.yang@easystack.cn>
    Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 037aca0e2fc22dcff17c38b38d9efab5e0d4b96e
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Apr 26 14:10:23 2018 +0200

    pwm: lpss: platform: Save/restore the ctrl register over a suspend/resume
    
    commit 1d375b58c12f08d8570b30b865def4734517f04f upstream.
    
    On some devices the contents of the ctrl register get lost over a
    suspend/resume and the PWM comes back up disabled after the resume.
    
    This is seen on some Bay Trail devices with the PWM in ACPI enumerated
    mode, so it shows up as a platform device instead of a PCI device.
    
    If we still think it is enabled and then try to change the duty-cycle
    after this, we end up with a "PWM_SW_UPDATE was not cleared" error and
    the PWM is stuck in that state from then on.
    
    This commit adds suspend and resume pm callbacks to the pwm-lpss-platform
    code, which save/restore the ctrl register over a suspend/resume, fixing
    this.
    
    Note that:
    
    1) There is no need to do this over a runtime suspend, since we
    only runtime suspend when disabled and then we properly set the enable
    bit and reprogram the timings when we re-enable the PWM.
    
    2) This may be happening on more systems then we realize, but has been
    covered up sofar by a bug in the acpi-lpss.c code which was save/restoring
    the regular device registers instead of the lpss private registers due to
    lpss_device_desc.prv_offset not being set. This is fixed by a later patch
    in this series.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c38bac75d1c21b09764a882b520b0ad33749ac10
Author: Alexandr Savca <alexandr.savca@saltedge.com>
Date:   Thu Jun 21 17:12:54 2018 -0700

    Input: elan_i2c - add ELAN0618 (Lenovo v330 15IKB) ACPI ID
    
    commit 8938fc7b8fe9ccfa11751ead502a8d385b607967 upstream.
    
    Add ELAN0618 to the list of supported touchpads; this ID is used in
    Lenovo v330 15IKB devices.
    
    Signed-off-by: Alexandr Savca <alexandr.savca@saltedge.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7673ca3c93414faf90fa2a3c339f1f625415fecb
Author: Kees Cook <keescook@chromium.org>
Date:   Fri May 11 18:24:12 2018 +1000

    video: uvesafb: Fix integer overflow in allocation
    
    commit 9f645bcc566a1e9f921bdae7528a01ced5bc3713 upstream.
    
    cmap->len can get close to INT_MAX/2, allowing for an integer overflow in
    allocation. This uses kmalloc_array() instead to catch the condition.
    
    Reported-by: Dr Silvio Cesare of InfoSect <silvio.cesare@gmail.com>
    Fixes: 8bdb3a2d7df48 ("uvesafb: the driver core")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cdc83c366977044d7717d56f6bb1aa247e1dc582
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Sat Jun 9 12:43:06 2018 -0400

    NFSv4: Revert commit 5f83d86cf531d ("NFSv4.x: Fix wraparound issues..")
    
    commit fc40724fc6731d90cc7fb6d62d66135f85a33dd2 upstream.
    
    The correct behaviour for NFSv4 sequence IDs is to wrap around
    to the value 0 after 0xffffffff.
    See https://tools.ietf.org/html/rfc5661#section-2.10.6.1
    
    Fixes: 5f83d86cf531d ("NFSv4.x: Fix wraparound issues when validing...")
    Cc: stable@vger.kernel.org # 4.6+
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b7f582e808d6b39eb0751deb1b6685813b05847
Author: Dave Wysochanski <dwysocha@redhat.com>
Date:   Tue May 29 17:47:30 2018 -0400

    NFSv4: Fix possible 1-byte stack overflow in nfs_idmap_read_and_verify_message
    
    commit d68894800ec5712d7ddf042356f11e36f87d7f78 upstream.
    
    In nfs_idmap_read_and_verify_message there is an incorrect sprintf '%d'
    that converts the __u32 'im_id' from struct idmap_msg to 'id_str', which
    is a stack char array variable of length NFS_UINT_MAXLEN == 11.
    If a uid or gid value is > 2147483647 = 0x7fffffff, the conversion
    overflows into a negative value, for example:
    crash> p (unsigned) (0x80000000)
    $1 = 2147483648
    crash> p (signed) (0x80000000)
    $2 = -2147483648
    The '-' sign is written to the buffer and this causes a 1 byte overflow
    when the NULL byte is written, which corrupts kernel stack memory.  If
    CONFIG_CC_STACKPROTECTOR_STRONG is set we see a stack-protector panic:
    
    [11558053.616565] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffffa05b8a8c
    [11558053.639063] CPU: 6 PID: 9423 Comm: rpc.idmapd Tainted: G        W      ------------ T 3.10.0-514.el7.x86_64 #1
    [11558053.641990] Hardware name: Red Hat OpenStack Compute, BIOS 1.10.2-3.el7_4.1 04/01/2014
    [11558053.644462]  ffffffff818c7bc0 00000000b1f3aec1 ffff880de0f9bd48 ffffffff81685eac
    [11558053.646430]  ffff880de0f9bdc8 ffffffff8167f2b3 ffffffff00000010 ffff880de0f9bdd8
    [11558053.648313]  ffff880de0f9bd78 00000000b1f3aec1 ffffffff811dcb03 ffffffffa05b8a8c
    [11558053.650107] Call Trace:
    [11558053.651347]  [<ffffffff81685eac>] dump_stack+0x19/0x1b
    [11558053.653013]  [<ffffffff8167f2b3>] panic+0xe3/0x1f2
    [11558053.666240]  [<ffffffff811dcb03>] ? kfree+0x103/0x140
    [11558053.682589]  [<ffffffffa05b8a8c>] ? idmap_pipe_downcall+0x1cc/0x1e0 [nfsv4]
    [11558053.689710]  [<ffffffff810855db>] __stack_chk_fail+0x1b/0x30
    [11558053.691619]  [<ffffffffa05b8a8c>] idmap_pipe_downcall+0x1cc/0x1e0 [nfsv4]
    [11558053.693867]  [<ffffffffa00209d6>] rpc_pipe_write+0x56/0x70 [sunrpc]
    [11558053.695763]  [<ffffffff811fe12d>] vfs_write+0xbd/0x1e0
    [11558053.702236]  [<ffffffff810acccc>] ? task_work_run+0xac/0xe0
    [11558053.704215]  [<ffffffff811fec4f>] SyS_write+0x7f/0xe0
    [11558053.709674]  [<ffffffff816964c9>] system_call_fastpath+0x16/0x1b
    
    Fix this by calling the internally defined nfs_map_numeric_to_string()
    function which properly uses '%u' to convert this __u32.  For consistency,
    also replace the one other place where snprintf is called.
    
    Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
    Reported-by: Stephen Johnston <sjohnsto@redhat.com>
    Fixes: cf4ab538f1516 ("NFSv4: Fix the string length returned by the idmapper")
    Cc: stable@vger.kernel.org # v3.4+
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40d79a61957a7d59b079d30fbbc5e51c3b9b239a
Author: Scott Mayhew <smayhew@redhat.com>
Date:   Mon May 7 09:01:08 2018 -0400

    nfsd: restrict rd_maxcount to svc_max_payload in nfsd_encode_readdir
    
    commit 9c2ece6ef67e9d376f32823086169b489c422ed0 upstream.
    
    nfsd4_readdir_rsize restricts rd_maxcount to svc_max_payload when
    estimating the size of the readdir reply, but nfsd_encode_readdir
    restricts it to INT_MAX when encoding the reply.  This can result in log
    messages like "kernel: RPC request reserved 32896 but used 1049444".
    
    Restrict rd_dircount similarly (no reason it should be larger than
    svc_max_payload).
    
    Signed-off-by: Scott Mayhew <smayhew@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc00f08645be1f6a1319af6c6c1117137f787efc
Author: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Date:   Thu Apr 5 05:30:52 2018 -0400

    media: dvb_frontend: fix locking issues at dvb_frontend_get_event()
    
    commit 76d81243a487c09619822ef8e7201a756e58a87d upstream.
    
    As warned by smatch:
            drivers/media/dvb-core/dvb_frontend.c:314 dvb_frontend_get_event() warn: inconsistent returns 'sem:&fepriv->sem'.
              Locked on:   line 288
                           line 295
                           line 306
                           line 314
              Unlocked on: line 303
    
    The lock implementation for get event is wrong, as, if an
    interrupt occurs, down_interruptible() will fail, and the
    routine will call up() twice when userspace calls the ioctl
    again.
    
    The bad code is there since when Linux migrated to git, in
    2005.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a4726ba1dedcdb92bc15a70e65150e9222ceed1
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Mon Mar 26 02:06:16 2018 -0400

    media: cx231xx: Add support for AverMedia DVD EZMaker 7
    
    commit 29e61d6ef061b012d320327af7dbb3990e75be45 upstream.
    
    User reports AverMedia DVD EZMaker 7 can be driven by VIDEO_GRABBER.
    Add the device to the id_table to make it work.
    
    BugLink: https://bugs.launchpad.net/bugs/1620762
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Hans Verkuil <hansverk@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e6b50b6b68e25a8ff972a1e1279a40cd7adc4fd
Author: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Date:   Wed Apr 11 11:47:32 2018 -0400

    media: v4l2-compat-ioctl32: prevent go past max size
    
    commit ea72fbf588ac9c017224dcdaa2019ff52ca56fee upstream.
    
    As warned by smatch:
            drivers/media/v4l2-core/v4l2-compat-ioctl32.c:879 put_v4l2_ext_controls32() warn: check for integer overflow 'count'
    
    The access_ok() logic should check for too big arrays too.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6a267b4c5f9bb3db42e3fe6092d1059f08d03bf
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Thu Jun 7 14:30:02 2018 +0300

    perf intel-pt: Fix packet decoding of CYC packets
    
    commit 621a5a327c1e36ffd7bb567f44a559f64f76358f upstream.
    
    Use a 64-bit type so that the cycle count is not limited to 32-bits.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/1528371002-8862-1-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d129ab791de910a81bb53f0053d3476c26982aea
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Thu May 31 13:23:45 2018 +0300

    perf intel-pt: Fix "Unexpected indirect branch" error
    
    commit 9fb523363f6e3984457fee95bb7019395384ffa7 upstream.
    
    Some Atom CPUs can produce FUP packets that contain NLIP (next linear
    instruction pointer) instead of CLIP (current linear instruction
    pointer).  That will result in "Unexpected indirect branch" errors. Fix
    by comparing IP to NLIP in that case.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/1527762225-26024-5-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4213d9b8cdb10d4d29fd232898692a1a56c1fd58
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Thu May 31 13:23:44 2018 +0300

    perf intel-pt: Fix MTC timing after overflow
    
    commit dd27b87ab5fcf3ea1c060b5e3ab5d31cc78e9f4c upstream.
    
    On some platforms, overflows will clear before MTC wraparound, and there
    is no following TSC/TMA packet. In that case the previous TMA is valid.
    Since there will be a valid TMA either way, stop setting 'have_tma' to
    false upon overflow.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/1527762225-26024-4-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 282f1f66b5a0f4875f2562144f5e5c80bc86dfc1
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Thu May 31 13:23:43 2018 +0300

    perf intel-pt: Fix decoding to accept CBR between FUP and corresponding TIP
    
    commit bd2e49ec48feb1855f7624198849eea4610e2286 upstream.
    
    It is possible to have a CBR packet between a FUP packet and
    corresponding TIP packet. Stop treating it as an error.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/1527762225-26024-3-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31606f7f56de573470f0b7037b764df381a87fa6
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Thu May 31 13:23:42 2018 +0300

    perf intel-pt: Fix sync_switch INTEL_PT_SS_NOT_TRACING
    
    commit dbcb82b93f3e8322891e47472c89e63058b81e99 upstream.
    
    sync_switch is a facility to synchronize decoding more closely with the
    point in the kernel when the context actually switched.
    
    In one case, INTEL_PT_SS_NOT_TRACING state was not correctly
    transitioning to INTEL_PT_SS_TRACING state due to a missing case clause.
    Add it.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/1527762225-26024-2-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dfd2eff6f457f2193f0dfd0de5cb3aa49df3d3e9
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Mon Jun 4 15:56:54 2018 +0300

    perf tools: Fix symbol and object code resolution for vdso32 and vdsox32
    
    commit aef4feace285f27c8ed35830a5d575bec7f3e90a upstream.
    
    Fix __kmod_path__parse() so that perf tools does not treat vdso32 and
    vdsox32 as kernel modules and fail to find the object.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Wang Nan <wangnan0@huawei.com>
    Cc: stable@vger.kernel.org
    Fixes: 1f121b03d058 ("perf tools: Deal with kernel module names in '[]' correctly")
    Link: http://lkml.kernel.org/r/1528117014-30032-3-git-send-email-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49d98a8e1f55f8406c45ce2b88eb4912d9877f67
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Tue Apr 24 18:00:10 2018 +0300

    mfd: intel-lpss: Program REMAP register in PIO mode
    
    commit d28b62520830b2d0bffa2d98e81afc9f5e537e8b upstream.
    
    According to documentation REMAP register has to be programmed in
    either DMA or PIO mode of the slice.
    
    Move the DMA capability check below to let REMAP register be programmed
    in PIO mode.
    
    Cc: stable@vger.kernel.org # 4.3+
    Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS devices")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 099fae46d8dfed70744321bbbd265cc7af2982f3
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Nov 20 11:45:46 2017 +0100

    backlight: tps65217_bl: Fix Device Tree node lookup
    
    commit 2b12dfa124dbadf391cb9a616aaa6b056823bf75 upstream.
    
    Fix child-node lookup during probe, which ended up searching the whole
    device tree depth-first starting at the parent rather than just matching
    on its children.
    
    This would only cause trouble if the child node is missing while there
    is an unrelated node named "backlight" elsewhere in the tree.
    
    Cc: stable <stable@vger.kernel.org>     # 3.7
    Fixes: eebfdc17cc6c ("backlight: Add TPS65217 WLED driver")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a89e596f129117b902210c57599e198d1441ee93
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Nov 20 11:45:45 2017 +0100

    backlight: max8925_bl: Fix Device Tree node lookup
    
    commit d1cc0ec3da23e44c23712579515494b374f111c9 upstream.
    
    Fix child-node lookup during probe, which ended up searching the whole
    device tree depth-first starting at the parent rather than just matching
    on its children.
    
    To make things worse, the parent mfd node was also prematurely freed,
    while the child backlight node was leaked.
    
    Cc: stable <stable@vger.kernel.org>     # 3.9
    Fixes: 47ec340cb8e2 ("mfd: max8925: Support dt for backlight")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47f764c65c561ba1dcf7c6a9688c82202ede58ca
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Nov 20 11:45:44 2017 +0100

    backlight: as3711_bl: Fix Device Tree node lookup
    
    commit 4a9c8bb2aca5b5a2a15744333729745dd9903562 upstream.
    
    Fix child-node lookup during probe, which ended up searching the whole
    device tree depth-first starting at the parent rather than just matching
    on its children.
    
    To make things worse, the parent mfd node was also prematurely freed.
    
    Cc: stable <stable@vger.kernel.org>     # 3.10
    Fixes: 59eb2b5e57ea ("drivers/video/backlight/as3711_bl.c: add OF support")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da05be555697c3fdd3f1507b59917c1cc3b03566
Author: Silvio Cesare <silvio.cesare@gmail.com>
Date:   Fri May 4 13:44:02 2018 +1000

    UBIFS: Fix potential integer overflow in allocation
    
    commit 353748a359f1821ee934afc579cf04572406b420 upstream.
    
    There is potential for the size and len fields in ubifs_data_node to be
    too large causing either a negative value for the length fields or an
    integer overflow leading to an incorrect memory allocation. Likewise,
    when the len field is small, an integer underflow may occur.
    
    Signed-off-by: Silvio Cesare <silvio.cesare@gmail.com>
    Fixes: 1e51764a3c2ac ("UBIFS: add new flash file system")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df15c6eeab46aac3622821e2659677c3eb4abf9d
Author: Richard Weinberger <richard@nod.at>
Date:   Mon May 28 22:04:32 2018 +0200

    ubi: fastmap: Correctly handle interrupted erasures in EBA
    
    commit 781932375ffc6411713ee0926ccae8596ed0261c upstream.
    
    Fastmap cannot track the LEB unmap operation, therefore it can
    happen that after an interrupted erasure the mapping still looks
    good from Fastmap's point of view, while reading from the PEB will
    cause an ECC error and confuses the upper layer.
    
    Instead of teaching users of UBI how to deal with that, we read back
    the VID header and check for errors. If the PEB is empty or shows ECC
    errors we fixup the mapping and schedule the PEB for erasure.
    
    Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
    Cc: <stable@vger.kernel.org>
    Reported-by: martin bayern <Martinbayern@outlook.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9eb99e738beb405cb69ce0c244e6bb0ee9666588
Author: Richard Weinberger <richard@nod.at>
Date:   Wed May 16 22:17:03 2018 +0200

    ubi: fastmap: Cancel work upon detach
    
    commit 6e7d80161066c99d12580d1b985cb1408bb58cf1 upstream.
    
    Ben Hutchings pointed out that 29b7a6fa1ec0 ("ubi: fastmap: Don't flush
    fastmap work on detach") does not really fix the problem, it just
    reduces the risk to hit the race window where fastmap work races against
    free()'ing ubi->volumes[].
    
    The correct approach is making sure that no more fastmap work is in
    progress before we free ubi data structures.
    So we cancel fastmap work right after the ubi background thread is
    stopped.
    By setting ubi->thread_enabled to zero we make sure that no further work
    tries to wake the thread.
    
    Fixes: 29b7a6fa1ec0 ("ubi: fastmap: Don't flush fastmap work on detach")
    Fixes: 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL sub-system")
    Cc: stable@vger.kernel.org
    Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Cc: Martin Townsend <mtownsend1973@gmail.com>
    
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec7ee4d60f25f9a4ba264090b2671346d078ed2a
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Mon Jun 4 10:39:01 2018 +0100

    rpmsg: smd: do not use mananged resources for endpoints and channels
    
    commit 4a2e84c6ed85434ce7843e4844b4d3263f7e233b upstream.
    
    All the managed resources would be freed by the time release function
    is invoked. Handling such memory in qcom_smd_edge_release() would do
    bad things.
    
    Found this issue while testing Audio usecase where the dsp is started up
    and shutdown in a loop.
    
    This patch fixes this issue by using simple kzalloc for allocating
    channel->name and channel which is then freed in qcom_smd_edge_release().
    
    Without this patch restarting a remoteproc would crash the system.
    Fixes: 53e2822e56c7 ("rpmsg: Introduce Qualcomm SMD backend")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 486684887ab588309c3497785412bb67e162b7a6
Author: NeilBrown <neilb@suse.com>
Date:   Thu Apr 26 14:46:29 2018 +1000

    md: fix two problems with setting the "re-add" device state.
    
    commit 011abdc9df559ec75779bb7c53a744c69b2a94c6 upstream.
    
    If "re-add" is written to the "state" file for a device
    which is faulty, this has an effect similar to removing
    and re-adding the device.  It should take up the
    same slot in the array that it previously had, and
    an accelerated (e.g. bitmap-based) rebuild should happen.
    
    The slot that "it previously had" is determined by
    rdev->saved_raid_disk.
    However this is not set when a device fails (only when a device
    is added), and it is cleared when resync completes.
    This means that "re-add" will normally work once, but may not work a
    second time.
    
    This patch includes two fixes.
    1/ when a device fails, record the ->raid_disk value in
        ->saved_raid_disk before clearing ->raid_disk
    2/ when "re-add" is written to a device for which
        ->saved_raid_disk is not set, fail.
    
    I think this is suitable for stable as it can
    cause re-adding a device to be forced to do a full
    resync which takes a lot longer and so puts data at
    more risk.
    
    Cc: <stable@vger.kernel.org> (v4.1)
    Fixes: 97f6cd39da22 ("md-cluster: re-add capabilities")
    Signed-off-by: NeilBrown <neilb@suse.com>
    Reviewed-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
    Signed-off-by: Shaohua Li <shli@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0eb205dfe159d02bd7821288765ac0a40a0695c
Author: Marcin Ziemianowicz <marcin@ziemianowicz.com>
Date:   Sun Apr 29 15:01:11 2018 -0400

    clk: at91: PLL recalc_rate() now using cached MUL and DIV values
    
    commit a982e45dc150da3a08907b6dd676b735391704b4 upstream.
    
    When a USB device is connected to the USB host port on the SAM9N12 then
    you get "-62" error which seems to indicate USB replies from the device
    are timing out. Based on a logic sniffer, I saw the USB bus was running
    at half speed.
    
    The PLL code uses cached MUL and DIV values which get set in set_rate()
    and applied in prepare(), but the recalc_rate() function instead
    queries the hardware instead of using these cached values. Therefore,
    if recalc_rate() is called between a set_rate() and prepare(), the
    wrong frequency is calculated and later the USB clock divider for the
    SAM9N12 SOC will be configured for an incorrect clock.
    
    In my case, the PLL hardware was set to 96 Mhz before the OHCI
    driver loads, and therefore the usb clock divider was being set
    to /2 even though the OHCI driver set the PLL to 48 Mhz.
    
    As an alternative explanation, I noticed this was fixed in the past by
    87e2ed338f1b ("clk: at91: fix recalc_rate implementation of PLL
    driver") but the bug was later re-introduced by 1bdf02326b71 ("clk:
    at91: make use of syscon/regmap internally").
    
    Fixes: 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally)
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Marcin Ziemianowicz <marcin@ziemianowicz.com>
    Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f216d1e9339dfb2981d2a0e44a15501cfa76f4ad
Author: Robert Elliott <elliott@hpe.com>
Date:   Thu May 31 18:36:36 2018 -0500

    linvdimm, pmem: Preserve read-only setting for pmem devices
    
    commit 254a4cd50b9fe2291a12b8902e08e56dcc4e9b10 upstream.
    
    The pmem driver does not honor a forced read-only setting for very long:
            $ blockdev --setro /dev/pmem0
            $ blockdev --getro /dev/pmem0
            1
    
    followed by various commands like these:
            $ blockdev --rereadpt /dev/pmem0
            or
            $ mkfs.ext4 /dev/pmem0
    
    results in this in the kernel serial log:
             nd_pmem namespace0.0: region0 read-write, marking pmem0 read-write
    
    with the read-only setting lost:
            $ blockdev --getro /dev/pmem0
            0
    
    That's from bus.c nvdimm_revalidate_disk(), which always applies the
    setting from nd_region (which is initially based on the ACPI NFIT
    NVDIMM state flags not_armed bit).
    
    In contrast, commit 20bd1d026aac ("scsi: sd: Keep disk read-only when
    re-reading partition") fixed this issue for SCSI devices to preserve
    the previous setting if it was set to read-only.
    
    This patch modifies bus.c to preserve any previous read-only setting.
    It also eliminates the kernel serial log print except for cases where
    read-write is changed to read-only, so it doesn't print read-only to
    read-only non-changes.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 581388209405 ("libnvdimm, nfit: handle unarmed dimms, mark namespaces read-only")
    Signed-off-by: Robert Elliott <elliott@hpe.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6751cb1e828d7aa93cedfcee65534318278713e
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Thu May 17 19:14:49 2018 +0200

    scsi: zfcp: fix missing REC trigger trace on enqueue without ERP thread
    
    commit 6a76550841d412330bd86aed3238d1888ba70f0e upstream.
    
    Example trace record formatted with zfcpdbf from s390-tools:
    
    Timestamp      : ...
    Area           : REC
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU ID         : ..
    Caller         : 0x...
    Record ID      : 1                      ZFCP_DBF_REC_TRIG
    Tag            : .......
    LUN            : 0x...
    WWPN           : 0x...
    D_ID           : 0x...
    Adapter status : 0x...
    Port status    : 0x...
    LUN status     : 0x...
    Ready count    : 0x...
    Running count  : 0x...
    ERP want       : 0x0.                   ZFCP_ERP_ACTION_REOPEN_...
    ERP need       : 0xc0                   ZFCP_ERP_ACTION_NONE
    
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Cc: <stable@vger.kernel.org> #2.6.38+
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2df7e6f33c64c61e9a33dbbed6bed4af78e94d67
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Thu May 17 19:14:48 2018 +0200

    scsi: zfcp: fix missing REC trigger trace for all objects in ERP_FAILED
    
    commit 8c3d20aada70042a39c6a6625be037c1472ca610 upstream.
    
    That other commit introduced an inconsistency because it would trace on
    ERP_FAILED for all callers of port forced reopen triggers (not just
    terminate_rport_io), but it would not trace on ERP_FAILED for all callers of
    other ERP triggers such as adapter, port regular, LUN.
    
    Therefore, generalize that other commit. zfcp_erp_action_enqueue() already
    had two early outs which re-used the one zfcp_dbf_rec_trig() call.  All ERP
    trigger functions finally run through zfcp_erp_action_enqueue().  So move
    the special handling for ZFCP_STATUS_COMMON_ERP_FAILED into
    zfcp_erp_action_enqueue() and add another early out with new trace marker
    for pseudo ERP need in this case. This removes all early returns from all
    ERP trigger functions so we always end up at zfcp_dbf_rec_trig().
    
    Example trace record formatted with zfcpdbf from s390-tools:
    
    Timestamp      : ...
    Area           : REC
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU ID         : ..
    Caller         : 0x...
    Record ID      : 1                      ZFCP_DBF_REC_TRIG
    Tag            : .......
    LUN            : 0x...
    WWPN           : 0x...
    D_ID           : 0x...
    Adapter status : 0x...
    Port status    : 0x...
    LUN status     : 0x...
    Ready count    : 0x...
    Running count  : 0x...
    ERP want       : 0x0.                   ZFCP_ERP_ACTION_REOPEN_...
    ERP need       : 0xe0                   ZFCP_ERP_ACTION_FAILED
    
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Cc: <stable@vger.kernel.org> #2.6.38+
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21224f6f135ab267b07729f3274fcfc028b3ace0
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Thu May 17 19:14:47 2018 +0200

    scsi: zfcp: fix missing REC trigger trace on terminate_rport_io for ERP_FAILED
    
    commit d70aab55924b44f213fec2b900b095430b33eec6 upstream.
    
    For problem determination we always want to see when we were invoked on the
    terminate_rport_io callback whether we perform something or not.
    
    Temporal event sequence of interest with a long fast_io_fail_tmo of 27 sec:
    
    loose remote port
    
    t   workqueue
    [s] zfcp_q_<dev>       IRQ                 zfcperp<dev>
    
    === ================== =================== ============================
    
      0                    recv RSCN
                           q p.test_link_work
        block rport
         start fast_io_fail_tmo
        send ADISC ELS
      4                    recv ADISC fail
                           block zfcp_port
                                               port forced reopen
                                               send open port
     12                    recv open port fail
                                               q p.gid_pn_work
                                               zfcp_erp_wakeup
                                               (zfcp_erp_wait would return)
        GID_PN fail
    
    Before this point, we got a SCSI trace with tag "sctrpi1" on fast_io_fail,
    e.g. with the typical 5 sec setting.
    
        port.status |= ERP_FAILED
    
    If fast_io_fail_tmo triggers after this point, we missed a SCSI trace.
    
        workqueue
        fc_dl_<host>
        ==================
     27 fc_timeout_fail_rport_io
        fc_terminate_rport_io
        zfcp_scsi_terminate_rport_io
        zfcp_erp_port_forced_reopen
        _zfcp_erp_port_forced_reopen
         if (port.status & ERP_FAILED)
          return;
    
    Therefore, write a trace before above early return.
    
    Example trace record formatted with zfcpdbf from s390-tools:
    
    Timestamp      : ...
    Area           : REC
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU ID         : ..
    Caller         : 0x...
    Record ID      : 1                      ZFCP_DBF_REC_TRIG
    Tag            : sctrpi1                SCSI terminate rport I/O
    LUN            : 0xffffffffffffffff                     none (invalid)
    WWPN           : 0x<wwpn>
    D_ID           : 0x<n_port_id>
    Adapter status : 0x...
    Port status    : 0x...
    LUN status     : 0x00000000                             none (invalid)
    Ready count    : 0x...
    Running count  : 0x...
    ERP want       : 0x03                   ZFCP_ERP_ACTION_REOPEN_PORT_FORCED
    ERP need       : 0xe0                   ZFCP_ERP_ACTION_FAILED
    
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Cc: <stable@vger.kernel.org> #2.6.38+
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48ae373c57f009b32a03637e0809fabd9132fe81
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Thu May 17 19:14:46 2018 +0200

    scsi: zfcp: fix missing REC trigger trace on terminate_rport_io early return
    
    commit 96d9270499471545048ed8a6d7f425a49762283d upstream.
    
    get_device() and its internally used kobject_get() only return NULL if they
    get passed NULL as argument. zfcp_get_port_by_wwpn() loops over
    adapter->port_list so the iteration variable port is always non-NULL.
    Struct device is embedded in struct zfcp_port so &port->dev is always
    non-NULL. This is the argument to get_device().  However, if we get an
    fc_rport in terminate_rport_io() for which we cannot find a match within
    zfcp_get_port_by_wwpn(), the latter can return NULL.  v2.6.30 commit
    70932935b61e ("[SCSI] zfcp: Fix oops when port disappears") introduced an
    early return without adding a trace record for this case.  Even if we don't
    need recovery in this case, for debugging we should still see that our
    callback was invoked originally by scsi_transport_fc.
    
    Example trace record formatted with zfcpdbf from s390-tools:
    
    Timestamp      : ...
    Area           : REC
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU ID         : ..
    Caller         : 0x...
    Record ID      : 1
    Tag            : sctrpin        SCSI terminate rport I/O, no zfcp port
    LUN            : 0xffffffffffffffff                     none (invalid)
    WWPN           : 0x<wwpn>               WWPN
    D_ID           : 0x<n_port_id>          N_Port-ID
    Adapter status : 0x...
    Port status    : 0xffffffff             unknown (-1)
    LUN status     : 0x00000000                             none (invalid)
    Ready count    : 0x...
    Running count  : 0x...
    ERP want       : 0x03                   ZFCP_ERP_ACTION_REOPEN_PORT_FORCED
    ERP need       : 0xc0                   ZFCP_ERP_ACTION_NONE
    
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Fixes: 70932935b61e ("[SCSI] zfcp: Fix oops when port disappears")
    Cc: <stable@vger.kernel.org> #2.6.38+
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0c2fc11ced965b01f174f69ecfac7feca48bc84
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Thu May 17 19:14:45 2018 +0200

    scsi: zfcp: fix misleading REC trigger trace where erp_action setup failed
    
    commit 512857a795cbbda5980efa4cdb3c0b6602330408 upstream.
    
    If a SCSI device is deleted during scsi_eh host reset, we cannot get a
    reference to the SCSI device anymore since scsi_device_get returns !=0 by
    design. Assuming the recovery of adapter and port(s) was successful,
    zfcp_erp_strategy_followup_success() attempts to trigger a LUN reset for the
    half-gone SCSI device. Unfortunately, it causes the following confusing
    trace record which states that zfcp will do a LUN recovery as "ERP need" is
    ZFCP_ERP_ACTION_REOPEN_LUN == 1 and equals "ERP want".
    
    Old example trace record formatted with zfcpdbf from s390-tools:
    
    Tag:           : ersfs_3 ERP, trigger, unit reopen, port reopen succeeded
    LUN            : 0x<FCP_LUN>
    WWPN           : 0x<WWPN>
    D_ID           : 0x<N_Port-ID>
    Adapter status : 0x5400050b
    Port status    : 0x54000001
    LUN status     : 0x40000000     ZFCP_STATUS_COMMON_RUNNING
                                    but not ZFCP_STATUS_COMMON_UNBLOCKED as it
                                    was closed on close part of adapter reopen
    ERP want       : 0x01
    ERP need       : 0x01           misleading
    
    However, zfcp_erp_setup_act() returns NULL as it cannot get the reference.
    Hence, zfcp_erp_action_enqueue() takes an early goto out and _NO_ recovery
    actually happens.
    
    We always do want the recovery trigger trace record even if no erp_action
    could be enqueued as in this case. For other cases where we did not enqueue
    an erp_action, 'need' has always been zero to indicate this. In order to
    indicate above goto out, introduce an eyecatcher "flag" to mark the "ERP
    need" as 'not needed' but still keep the information which erp_action type,
    that zfcp_erp_required_act() had decided upon, is needed.  0xc_ is chosen to
    be visibly different from 0x0_ in "ERP want".
    
    New example trace record formatted with zfcpdbf from s390-tools:
    
    Tag:           : ersfs_3 ERP, trigger, unit reopen, port reopen succeeded
    LUN            : 0x<FCP_LUN>
    WWPN           : 0x<WWPN>
    D_ID           : 0x<N_Port-ID>
    Adapter status : 0x5400050b
    Port status    : 0x54000001
    LUN status     : 0x40000000
    ERP want       : 0x01
    ERP need       : 0xc1           would need LUN ERP, but no action set up
                       ^
    
    Before v2.6.38 commit ae0904f60fab ("[SCSI] zfcp: Redesign of the debug
    tracing for recovery actions.") we could detect this case because the
    "erp_action" field in the trace was NULL. The rework removed erp_action as
    argument and field from the trace.
    
    This patch here is for tracing. A fix to allow LUN recovery in the case at
    hand is a topic for a separate patch.
    
    See also commit fdbd1c5e27da ("[SCSI] zfcp: Allow running unit/LUN shutdown
    without acquiring reference") for a similar case and background info.
    
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Fixes: ae0904f60fab ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.")
    Cc: <stable@vger.kernel.org> #2.6.38+
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97d3625bdd43e6816b179ea56a7aa58060069eee
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Thu May 17 19:14:44 2018 +0200

    scsi: zfcp: fix missing SCSI trace for retry of abort / scsi_eh TMF
    
    commit 81979ae63e872ef650a7197f6ce6590059d37172 upstream.
    
    We already have a SCSI trace for the end of abort and scsi_eh TMF. Due to
    zfcp_erp_wait() and fc_block_scsi_eh() time can pass between the start of
    our eh callback and an actual send/recv of an abort / TMF request.  In order
    to see the temporal sequence including any abort / TMF send retries, add a
    trace before the above two blocking functions.  This supports problem
    determination with scsi_eh and parallel zfcp ERP.
    
    No need to explicitly trace the beginning of our eh callback, since we
    typically can send an abort / TMF and see its HBA response (in the worst
    case, it's a pseudo response on dismiss all of adapter recovery, e.g. due to
    an FSF request timeout [fsrth_1] of the abort / TMF). If we cannot send, we
    now get a trace record for the first "abrt_wt" or "[lt]r_wait" which denotes
    almost the beginning of the callback.
    
    No need to explicitly trace the wakeup after the above two blocking
    functions because the next retry loop causes another trace in any case and
    that is sufficient.
    
    Example trace records formatted with zfcpdbf from s390-tools:
    
    Timestamp      : ...
    Area           : SCSI
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU ID         : ..
    Caller         : 0x...
    Record ID      : 1
    Tag            : abrt_wt        abort, before zfcp_erp_wait()
    Request ID     : 0x0000000000000000                     none (invalid)
    SCSI ID        : 0x<scsi_id>
    SCSI LUN       : 0x<scsi_lun>
    SCSI LUN high  : 0x<scsi_lun_high>
    SCSI result    : 0x<scsi_result_of_cmd_to_be_aborted>
    SCSI retries   : 0x<retries_of_cmd_to_be_aborted>
    SCSI allowed   : 0x<allowed_retries_of_cmd_to_be_aborted>
    SCSI scribble  : 0x<req_id_of_cmd_to_be_aborted>
    SCSI opcode    : <CDB_of_cmd_to_be_aborted>
    FCP rsp inf cod: 0x..                                   none (invalid)
    FCP rsp IU     : ...                                    none (invalid)
    
    Timestamp      : ...
    Area           : SCSI
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU ID         : ..
    Caller         : 0x...
    Record ID      : 1
    Tag            : lr_wait        LUN reset, before zfcp_erp_wait()
    Request ID     : 0x0000000000000000                     none (invalid)
    SCSI ID        : 0x<scsi_id>
    SCSI LUN       : 0x<scsi_lun>
    SCSI LUN high  : 0x<scsi_lun_high>
    SCSI result    : 0x...                                  unrelated
    SCSI retries   : 0x..                                   unrelated
    SCSI allowed   : 0x..                                   unrelated
    SCSI scribble  : 0x...                                  unrelated
    SCSI opcode    : ...                                    unrelated
    FCP rsp inf cod: 0x..                                   none (invalid)
    FCP rsp IU     : ...                                    none (invalid)
    
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Fixes: 63caf367e1c9 ("[SCSI] zfcp: Improve reliability of SCSI eh handlers in zfcp")
    Fixes: af4de36d911a ("[SCSI] zfcp: Block scsi_eh thread for rport state BLOCKED")
    Cc: <stable@vger.kernel.org> #2.6.38+
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9779f499d88f55df72cc504b830115aecea9cfbe
Author: Steffen Maier <maier@linux.ibm.com>
Date:   Thu May 17 19:14:43 2018 +0200

    scsi: zfcp: fix missing SCSI trace for result of eh_host_reset_handler
    
    commit df30781699f53e4fd4c494c6f7dd16e3d5c21d30 upstream.
    
    For problem determination we need to see whether and why we were successful
    or not. This allows deduction of scsi_eh escalation.
    
    Example trace record formatted with zfcpdbf from s390-tools:
    
    Timestamp      : ...
    Area           : SCSI
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU ID         : ..
    Caller         : 0x...
    Record ID      : 1
    Tag            : schrh_r        SCSI host reset handler result
    Request ID     : 0x0000000000000000                     none (invalid)
    SCSI ID        : 0xffffffff                             none (invalid)
    SCSI LUN       : 0xffffffff                             none (invalid)
    SCSI LUN high  : 0xffffffff                             none (invalid)
    SCSI result    : 0x00002002     field re-used for midlayer value: SUCCESS
                                    or in other cases: 0x2009 == FAST_IO_FAIL
    SCSI retries   : 0xff                                   none (invalid)
    SCSI allowed   : 0xff                                   none (invalid)
    SCSI scribble  : 0xffffffffffffffff                     none (invalid)
    SCSI opcode    : ffffffff ffffffff ffffffff ffffffff    none (invalid)
    FCP rsp inf cod: 0xff                                   none (invalid)
    FCP rsp IU     : 00000000 00000000 00000000 00000000    none (invalid)
                     00000000 00000000
    
    v2.6.35 commit a1dbfddd02d2 ("[SCSI] zfcp: Pass return code from
    fc_block_scsi_eh to scsi eh") introduced the first return with something
    other than the previously hardcoded single SUCCESS return path.
    
    Signed-off-by: Steffen Maier <maier@linux.ibm.com>
    Fixes: a1dbfddd02d2 ("[SCSI] zfcp: Pass return code from fc_block_scsi_eh to scsi eh")
    Cc: <stable@vger.kernel.org> #2.6.38+
    Reviewed-by: Jens Remus <jremus@linux.ibm.com>
    Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0c543159a4abad4412e55db33ac730c9f21684d
Author: Himanshu Madhani <himanshu.madhani@cavium.com>
Date:   Sun Jun 3 22:09:53 2018 -0700

    scsi: qla2xxx: Fix setting lower transfer speed if GPSC fails
    
    commit 413c2f33489b134e3cc65d9c3ff7861e8fdfe899 upstream.
    
    This patch prevents driver from setting lower default speed of 1 GB/sec,
    if the switch does not support Get Port Speed Capabilities (GPSC)
    command. Setting this default speed results into much lower write
    performance for large sequential WRITE.  This patch modifies driver to
    check for gpsc_supported flags and prevents driver from issuing
    MBC_SET_PORT_PARAM (001Ah) to set default speed of 1 GB/sec. If driver
    does not send this mailbox command, firmware assumes maximum supported
    link speed and will operate at the max speed.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
    Reported-by: Eda Zhou <ezhou@redhat.com>
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Tested-by: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0400b066ea2f8730456e607bda3896e3985c2a1a
Author: Martin Kelly <mkelly@xevo.com>
Date:   Mon Mar 26 14:27:51 2018 -0700

    iio:buffer: make length types match kfifo types
    
    commit c043ec1ca5baae63726aae32abbe003192bc6eec upstream.
    
    Currently, we use int for buffer length and bytes_per_datum. However,
    kfifo uses unsigned int for length and size_t for element size. We need
    to make sure these matches or we will have bugs related to overflow (in
    the range between INT_MAX and UINT_MAX for length, for example).
    
    In addition, set_bytes_per_datum uses size_t while bytes_per_datum is an
    int, which would cause bugs for large values of bytes_per_datum.
    
    Change buffer length to use unsigned int and bytes_per_datum to use
    size_t.
    
    Signed-off-by: Martin Kelly <mkelly@xevo.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    [bwh: Backported to 4.9:
     - Drop change to iio_dma_buffer_set_length()
     - Adjust filename, context]
    Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3fd6a73da159049bade087487256af9030423975
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Wed Jan 31 17:09:13 2018 -0700

    Btrfs: fix unexpected cow in run_delalloc_nocow
    
    commit 5811375325420052fcadd944792a416a43072b7f upstream.
    
    Fstests generic/475 provides a way to fail metadata reads while
    checking if checksum exists for the inode inside run_delalloc_nocow(),
    and csum_exist_in_range() interprets error (-EIO) as inode having
    checksum and makes its caller enter the cow path.
    
    In case of free space inode, this ends up with a warning in
    cow_file_range().
    
    The same problem applies to btrfs_cross_ref_exist() since it may also
    read metadata in between.
    
    With this, run_delalloc_nocow() bails out when errors occur at the two
    places.
    
    cc: <stable@vger.kernel.org> v2.6.28+
    Fixes: 17d217fe970d ("Btrfs: fix nodatasum handling in balancing code")
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77c82917d533ce49fff2731ddaa1dbc3fbfd9551
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon Jun 11 19:24:16 2018 +0100

    Btrfs: fix return value on rename exchange failure
    
    commit c5b4a50b74018b3677098151ec5f4fce07d5e6a0 upstream.
    
    If we failed during a rename exchange operation after starting/joining a
    transaction, we would end up replacing the return value, stored in the
    local 'ret' variable, with the return value from btrfs_end_transaction().
    So this could end up returning 0 (success) to user space despite the
    operation having failed and aborted the transaction, because if there are
    multiple tasks having a reference on the transaction at the time
    btrfs_end_transaction() is called by the rename exchange, that function
    returns 0 (otherwise it returns -EIO and not the original error value).
    So fix this by not overwriting the return value on error after getting
    a transaction handle.
    
    Fixes: cdd1fedf8261 ("btrfs: add support for RENAME_EXCHANGE and RENAME_WHITEOUT")
    CC: stable@vger.kernel.org # 4.9+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41b1d57a672f45f1d3a158cf28c24f1885201c9e
Author: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Date:   Sat May 19 14:23:54 2018 +0200

    X.509: unpack RSA signatureValue field from BIT STRING
    
    commit b65c32ec5a942ab3ada93a048089a938918aba7f upstream.
    
    The signatureValue field of a X.509 certificate is encoded as a BIT STRING.
    For RSA signatures this BIT STRING is of so-called primitive subtype, which
    contains a u8 prefix indicating a count of unused bits in the encoding.
    
    We have to strip this prefix from signature data, just as we already do for
    key data in x509_extract_key_data() function.
    
    This wasn't noticed earlier because this prefix byte is zero for RSA key
    sizes divisible by 8. Since BIT STRING is a big-endian encoding adding zero
    prefixes has no bearing on its value.
    
    The signature length, however was incorrect, which is a problem for RSA
    implementations that need it to be exactly correct (like AMD CCP).
    
    Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
    Fixes: c26fd69fa009 ("X.509: Add a crypto key parser for binary (DER) X.509 certificates")
    Cc: stable@vger.kernel.org
    Signed-off-by: James Morris <james.morris@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fd86587ea975c2dc324c7c5bf804619bcea22b6
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Fri Jun 22 16:33:57 2018 +0200

    time: Make sure jiffies_to_msecs() preserves non-zero time periods
    
    commit abcbcb80cd09cd40f2089d912764e315459b71f7 upstream.
    
    For the common cases where 1000 is a multiple of HZ, or HZ is a multiple of
    1000, jiffies_to_msecs() never returns zero when passed a non-zero time
    period.
    
    However, if HZ > 1000 and not an integer multiple of 1000 (e.g. 1024 or
    1200, as used on alpha and DECstation), jiffies_to_msecs() may return zero
    for small non-zero time periods.  This may break code that relies on
    receiving back a non-zero value.
    
    jiffies_to_usecs() does not need such a fix: one jiffy can only be less
    than one µs if HZ > 1000000, and such large values of HZ are already
    rejected at build time, twice:
    
      - include/linux/jiffies.h does #error if HZ >= 12288,
      - kernel/time/time.c has BUILD_BUG_ON(HZ > USEC_PER_SEC).
    
    Broken since forever.
    
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Stephen Boyd <sboyd@kernel.org>
    Cc: linux-alpha@vger.kernel.org
    Cc: linux-mips@linux-mips.org
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20180622143357.7495-1-geert@linux-m68k.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 344d6159fede9a3f7c7b846c662d3744ae89d132
Author: Huacai Chen <chenhc@lemote.com>
Date:   Tue Jun 12 17:54:42 2018 +0800

    MIPS: io: Add barrier after register read in inX()
    
    commit 18f3e95b90b28318ef35910d21c39908de672331 upstream.
    
    While a barrier is present in the outX() functions before the register
    write, a similar barrier is missing in the inX() functions after the
    register read. This could allow memory accesses following inX() to
    observe stale data.
    
    This patch is very similar to commit a1cc7034e33d12dc1 ("MIPS: io: Add
    barrier after register read in readX()"). Because war_io_reorder_wmb()
    is both used by writeX() and outX(), if readX() need a barrier then so
    does inX().
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Patchwork: https://patchwork.linux-mips.org/patch/19516/
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: James Hogan <james.hogan@mips.com>
    Cc: linux-mips@linux-mips.org
    Cc: Fuxin Zhang <zhangfx@lemote.com>
    Cc: Zhangjin Wu <wuzhangjin@gmail.com>
    Cc: Huacai Chen <chenhuacai@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db2baeef79d1d0ff0fac4589f8d7dc215ea36889
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Fri May 11 19:54:19 2018 +0900

    printk: fix possible reuse of va_list variable
    
    commit 988a35f8da1dec5a8cd2788054d1e717be61bf25 upstream.
    
    I noticed that there is a possibility that printk_safe_log_store() causes
    kernel oops because "args" parameter is passed to vsnprintf() again when
    atomic_cmpxchg() detected that we raced. Fix this by using va_copy().
    
    Link: http://lkml.kernel.org/r/201805112002.GIF21216.OFVHFOMLJtQFSO@I-love.SAKURA.ne.jp
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: dvyukov@google.com
    Cc: syzkaller@googlegroups.com
    Cc: fengguang.wu@intel.com
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Fixes: 42a0bb3f71383b45 ("printk/nmi: generic solution for safe printk in NMI")
    Cc: 4.7+ <stable@vger.kernel.org> # v4.7+
    Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca558fb836d3b04fbda144fa22e295d5f41bc2de
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Wed May 23 17:14:39 2018 -0500

    PCI: pciehp: Clear Presence Detect and Data Link Layer Status Changed on resume
    
    commit 13c65840feab8109194f9490c9870587173cb29d upstream.
    
    After a suspend/resume cycle the Presence Detect or Data Link Layer Status
    Changed bits might be set.  If we don't clear them those events will not
    fire anymore and nothing happens for instance when a device is now
    hot-unplugged.
    
    Fix this by clearing those bits in a newly introduced function
    pcie_reenable_notification().  This should be fine because immediately
    after, we check if the adapter is still present by reading directly from
    the status register.
    
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d3d58337d4bd414d069c1f4d6330e02ef2ecd1e
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Fri Apr 27 13:06:30 2018 -0500

    PCI: Add ACS quirk for Intel 300 series
    
    commit f154a718e6cc0d834f5ac4dc4c3b174e65f3659e upstream.
    
    Intel 300 series chipset still has the same ACS issue as the previous
    generations so extend the ACS quirk to cover it as well.
    
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e1deade6064d088ad4852f9a2299eeeefdfe3d2
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Wed Apr 25 14:27:37 2018 -0600

    PCI: Add ACS quirk for Intel 7th & 8th Gen mobile
    
    commit e8440f4bfedc623bee40c84797ac78d9303d0db6 upstream.
    
    The specification update indicates these have the same errata for
    implementing non-standard ACS capabilities.
    
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83f9549d650b477b46fc070461f82ef536eae702
Author: Tokunori Ikegami <ikegami@allied-telesis.co.jp>
Date:   Sun Jun 3 23:02:01 2018 +0900

    MIPS: BCM47XX: Enable 74K Core ExternalSync for PCIe erratum
    
    commit 2a027b47dba6b77ab8c8e47b589ae9bbc5ac6175 upstream.
    
    The erratum and workaround are described by BCM5300X-ES300-RDS.pdf as
    below.
    
      R10: PCIe Transactions Periodically Fail
    
        Description: The BCM5300X PCIe does not maintain transaction ordering.
                     This may cause PCIe transaction failure.
        Fix Comment: Add a dummy PCIe configuration read after a PCIe
                     configuration write to ensure PCIe configuration access
                     ordering. Set ES bit of CP0 configu7 register to enable
                     sync function so that the sync instruction is functional.
        Resolution:  hndpci.c: extpci_write_config()
                     hndmips.c: si_mips_init()
                     mipsinc.h CONF7_ES
    
    This is fixed by the CFE MIPS bcmsi chipset driver also for BCM47XX.
    Also the dummy PCIe configuration read is already implemented in the
    Linux BCMA driver.
    
    Enable ExternalSync in Config7 when CONFIG_BCMA_DRIVER_PCI_HOSTMODE=y
    too so that the sync instruction is externalised.
    
    Signed-off-by: Tokunori Ikegami <ikegami@allied-telesis.co.jp>
    Reviewed-by: Paul Burton <paul.burton@mips.com>
    Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
    Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
    Cc: Rafał Miłecki <zajec5@gmail.com>
    Cc: linux-mips@linux-mips.org
    Cc: stable@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/19461/
    Signed-off-by: James Hogan <jhogan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fdb3c468b515694159583d01a3154e0ffa4a81f
Author: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Date:   Wed Jun 6 12:13:30 2018 +0200

    mtd: cfi_cmdset_0002: Avoid walking all chips when unlocking.
    
    commit f1ce87f6080b1dda7e7b1eda3da332add19d87b9 upstream.
    
    cfi_ppb_unlock() walks all flash chips when unlocking sectors,
    avoid walking chips unaffected by the unlock operation.
    
    Fixes: 1648eaaa1575 ("mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking")
    Cc: stable@vger.kernel.org
    Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
    Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4e24c2842e15f221ac3527af781d7b8940b5cfb
Author: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Date:   Wed Jun 6 12:13:29 2018 +0200

    mtd: cfi_cmdset_0002: Fix unlocking requests crossing a chip boudary
    
    commit 0cd8116f172eed018907303dbff5c112690eeb91 upstream.
    
    The "sector is in requested range" test used to determine whether
    sectors should be re-locked or not is done on a variable that is reset
    everytime we cross a chip boundary, which can lead to some blocks being
    re-locked while the caller expect them to be unlocked.
    Fix the check to make sure this cannot happen.
    
    Fixes: 1648eaaa1575 ("mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking")
    Cc: stable@vger.kernel.org
    Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
    Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0bf4e48c20ca447e577c77bfc9205f1c8890c65d
Author: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Date:   Wed Jun 6 12:13:28 2018 +0200

    mtd: cfi_cmdset_0002: fix SEGV unlocking multiple chips
    
    commit 5fdfc3dbad099281bf027a353d5786c09408a8e5 upstream.
    
    cfi_ppb_unlock() tries to relock all sectors that were locked before
    unlocking the whole chip.
    This locking used the chip start address + the FULL offset from the
    first flash chip, thereby forming an illegal address. Fix that by using
    the chip offset(adr).
    
    Fixes: 1648eaaa1575 ("mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking")
    Cc: stable@vger.kernel.org
    Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
    Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 552eacd58ee4c930f313f8e01f4cee75fc48afed
Author: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Date:   Wed Jun 6 12:13:27 2018 +0200

    mtd: cfi_cmdset_0002: Use right chip in do_ppb_xxlock()
    
    commit f93aa8c4de307069c270b2d81741961162bead6c upstream.
    
    do_ppb_xxlock() fails to add chip->start when querying for lock status
    (and chip_ready test), which caused false status reports.
    Fix that by adding adr += chip->start and adjust call sites
    accordingly.
    
    Fixes: 1648eaaa1575 ("mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking")
    Cc: stable@vger.kernel.org
    Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
    Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9dc5dce0925ea4412345ca034bba9a252de2783
Author: Tokunori Ikegami <ikegami@allied-telesis.co.jp>
Date:   Wed May 30 18:32:26 2018 +0900

    mtd: cfi_cmdset_0002: Change write buffer to check correct value
    
    commit dfeae1073583dc35c33b32150e18b7048bbb37e6 upstream.
    
    For the word write it is checked if the chip has the correct value.
    But it is not checked for the write buffer as only checked if ready.
    To make sure for the write buffer change to check the value.
    
    It is enough as this patch is only checking the last written word.
    Since it is described by data sheets to check the operation status.
    
    Signed-off-by: Tokunori Ikegami <ikegami@allied-telesis.co.jp>
    Reviewed-by: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
    Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
    Cc: Brian Norris <computersforpeace@gmail.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
    Cc: Marek Vasut <marek.vasut@gmail.com>
    Cc: Richard Weinberger <richard@nod.at>
    Cc: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
    Cc: linux-mtd@lists.infradead.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afe249e3e38d51e58eba9b6992646a1f8070883d
Author: Leon Romanovsky <leonro@mellanox.com>
Date:   Tue May 29 14:56:14 2018 +0300

    RDMA/mlx4: Discard unknown SQP work requests
    
    commit 6b1ca7ece15e94251d1d0d919f813943e4a58059 upstream.
    
    There is no need to crash the machine if unknown work request was
    received in SQP MAD.
    
    Cc: <stable@vger.kernel.org> # 3.6
    Fixes: 37bfc7c1e83f ("IB/mlx4: SR-IOV multiplex and demultiplex MADs")
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52e167187be8b584673204f6d87b07aff7725e47
Author: Max Gurtovoy <maxg@mellanox.com>
Date:   Thu May 31 11:05:23 2018 +0300

    IB/isert: fix T10-pi check mask setting
    
    commit 0e12af84cdd3056460f928adc164f9e87f4b303b upstream.
    
    A copy/paste bug (probably) caused setting of an app_tag check mask
    in case where a ref_tag check was needed.
    
    Fixes: 38a2d0d429f1 ("IB/isert: convert to the generic RDMA READ/WRITE API")
    Fixes: 9e961ae73c2c ("IB/isert: Support T10-PI protected transactions")
    Cc: stable@vger.kernel.org
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a664281b85e01066336a0eb46bd09054c0705009
Author: Alex Estrin <alex.estrin@intel.com>
Date:   Tue May 15 18:31:39 2018 -0700

    IB/isert: Fix for lib/dma_debug check_sync warning
    
    commit 763b69654bfb88ea3230d015e7d755ee8339f8ee upstream.
    
    The following error message occurs on a target host in a debug build
    during session login:
    
    [ 3524.411874] WARNING: CPU: 5 PID: 12063 at lib/dma-debug.c:1207 check_sync+0x4ec/0x5b0
    [ 3524.421057] infiniband hfi1_0: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x0000000000000000] [size=76 bytes]
    ......snip .....
    
    [ 3524.535846] CPU: 5 PID: 12063 Comm: iscsi_np Kdump: loaded Not tainted 3.10.0-862.el7.x86_64.debug #1
    [ 3524.546764] Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 1.2.6 06/08/2015
    [ 3524.555740] Call Trace:
    [ 3524.559102]  [<ffffffffa5fe915b>] dump_stack+0x19/0x1b
    [ 3524.565477]  [<ffffffffa58a2f58>] __warn+0xd8/0x100
    [ 3524.571557]  [<ffffffffa58a2fdf>] warn_slowpath_fmt+0x5f/0x80
    [ 3524.578610]  [<ffffffffa5bf5b8c>] check_sync+0x4ec/0x5b0
    [ 3524.585177]  [<ffffffffa58efc3f>] ? set_cpus_allowed_ptr+0x5f/0x1c0
    [ 3524.592812]  [<ffffffffa5bf5cd0>] debug_dma_sync_single_for_cpu+0x80/0x90
    [ 3524.601029]  [<ffffffffa586add3>] ? x2apic_send_IPI_mask+0x13/0x20
    [ 3524.608574]  [<ffffffffa585ee1b>] ? native_smp_send_reschedule+0x5b/0x80
    [ 3524.616699]  [<ffffffffa58e9b76>] ? resched_curr+0xf6/0x140
    [ 3524.623567]  [<ffffffffc0879af0>] isert_create_send_desc.isra.26+0xe0/0x110 [ib_isert]
    [ 3524.633060]  [<ffffffffc087af95>] isert_put_login_tx+0x55/0x8b0 [ib_isert]
    [ 3524.641383]  [<ffffffffa58ef114>] ? try_to_wake_up+0x1a4/0x430
    [ 3524.648561]  [<ffffffffc098cfed>] iscsi_target_do_tx_login_io+0xdd/0x230 [iscsi_target_mod]
    [ 3524.658557]  [<ffffffffc098d827>] iscsi_target_do_login+0x1a7/0x600 [iscsi_target_mod]
    [ 3524.668084]  [<ffffffffa59f9bc9>] ? kstrdup+0x49/0x60
    [ 3524.674420]  [<ffffffffc098e976>] iscsi_target_start_negotiation+0x56/0xc0 [iscsi_target_mod]
    [ 3524.684656]  [<ffffffffc098c2ee>] __iscsi_target_login_thread+0x90e/0x1070 [iscsi_target_mod]
    [ 3524.694901]  [<ffffffffc098ca50>] ? __iscsi_target_login_thread+0x1070/0x1070 [iscsi_target_mod]
    [ 3524.705446]  [<ffffffffc098ca50>] ? __iscsi_target_login_thread+0x1070/0x1070 [iscsi_target_mod]
    [ 3524.715976]  [<ffffffffc098ca78>] iscsi_target_login_thread+0x28/0x60 [iscsi_target_mod]
    [ 3524.725739]  [<ffffffffa58d60ff>] kthread+0xef/0x100
    [ 3524.732007]  [<ffffffffa58d6010>] ? insert_kthread_work+0x80/0x80
    [ 3524.739540]  [<ffffffffa5fff1b7>] ret_from_fork_nospec_begin+0x21/0x21
    [ 3524.747558]  [<ffffffffa58d6010>] ? insert_kthread_work+0x80/0x80
    [ 3524.755088] ---[ end trace 23f8bf9238bd1ed8 ]---
    [ 3595.510822] iSCSI/iqn.1994-05.com.redhat:537fa56299: Unsupported SCSI Opcode 0xa3, sending CHECK_CONDITION.
    
    The code calls dma_sync on login_tx_desc->dma_addr prior to initializing it
    with dma-mapped address.
    login_tx_desc is a part of iser_conn structure and is used only once
    during login negotiation, so the issue is fixed by eliminating
    dma_sync call for this buffer using a special case routine.
    
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Reviewed-by: Don Dutile <ddutile@redhat.com>
    Signed-off-by: Alex Estrin <alex.estrin@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e355402cf19cf30e5f659ac21ddf40ccd7e5bcf0
Author: Erez Shitrit <erezsh@mellanox.com>
Date:   Mon May 21 11:41:01 2018 +0300

    IB/mlx5: Fetch soft WQE's on fatal error state
    
    commit 7b74a83cf54a3747e22c57e25712bd70eef8acee upstream.
    
    On fatal error the driver simulates CQE's for ULPs that rely on
    completion of all their posted work-request.
    
    For the GSI traffic, the mlx5 has its own mechanism that sends the
    completions via software CQE's directly to the relevant CQ.
    
    This should be kept in fatal error too, so the driver should simulate
    such CQE's with the specified error state in order to complete GSI QP
    work requests.
    
    Without the fix the next deadlock might appears:
            schedule_timeout+0x274/0x350
            wait_for_common+0xec/0x240
            mcast_remove_one+0xd0/0x120 [ib_core]
            ib_unregister_device+0x12c/0x230 [ib_core]
            mlx5_ib_remove+0xc4/0x270 [mlx5_ib]
            mlx5_detach_device+0x184/0x1a0 [mlx5_core]
            mlx5_unload_one+0x308/0x340 [mlx5_core]
            mlx5_pci_err_detected+0x74/0xe0 [mlx5_core]
    
    Cc: <stable@vger.kernel.org> # 4.7
    Fixes: 89ea94a7b6c4 ("IB/mlx5: Reset flow support for IB kernel ULPs")
    Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cac0a08e476775df3ae5f90730a766ea01b6232
Author: Alex Estrin <alex.estrin@intel.com>
Date:   Wed May 2 06:43:15 2018 -0700

    IB/{hfi1, qib}: Add handling of kernel restart
    
    commit 8d3e71136a080d007620472f50c7b3e63ba0f5cf upstream.
    
    A warm restart will fail to unload the driver, leaving link state
    potentially flapping up to the point the BIOS resets the adapter.
    Correct the issue by hooking the shutdown pci method,
    which will bring port down.
    
    Cc: <stable@vger.kernel.org> # 4.9.x
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Alex Estrin <alex.estrin@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9321e8303406e2a194ba8e88fa8b57ee360f3f00
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Fri May 18 17:07:01 2018 -0700

    IB/qib: Fix DMA api warning with debug kernel
    
    commit 0252f73334f9ef68868e4684200bea3565a4fcee upstream.
    
    The following error occurs in a debug build when running MPI PSM:
    
    [  307.415911] WARNING: CPU: 4 PID: 23867 at lib/dma-debug.c:1158
    check_unmap+0x4ee/0xa20
    [  307.455661] ib_qib 0000:05:00.0: DMA-API: device driver failed to check map
    error[device address=0x00000000df82b000] [size=4096 bytes] [mapped as page]
    [  307.517494] Modules linked in:
    [  307.531584]  ib_isert iscsi_target_mod ib_srpt target_core_mod rpcrdma
    sunrpc ib_srp scsi_transport_srp scsi_tgt ib_iser libiscsi ib_ipoib
    scsi_transport_iscsi rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm
    ib_qib intel_powerclamp coretemp rdmavt intel_rapl iosf_mbi kvm_intel kvm
    irqbypass crc32_pclmul ghash_clmulni_intel ipmi_ssif ib_core aesni_intel sg
    ipmi_si lrw gf128mul dca glue_helper ipmi_devintf iTCO_wdt gpio_ich hpwdt
    iTCO_vendor_support ablk_helper hpilo acpi_power_meter cryptd ipmi_msghandler
    ie31200_edac shpchp pcc_cpufreq lpc_ich pcspkr ip_tables xfs libcrc32c sd_mod
    crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper syscopyarea
    sysfillrect sysimgblt fb_sys_fops ttm ahci crct10dif_pclmul crct10dif_common
    drm crc32c_intel libahci tg3 libata serio_raw ptp i2c_core
    [  307.846113]  pps_core dm_mirror dm_region_hash dm_log dm_mod
    [  307.866505] CPU: 4 PID: 23867 Comm: mpitests-IMB-MP Kdump: loaded Not
    tainted 3.10.0-862.el7.x86_64.debug #1
    [  307.911178] Hardware name: HP ProLiant DL320e Gen8, BIOS J05 11/09/2013
    [  307.944206] Call Trace:
    [  307.956973]  [<ffffffffbd9e915b>] dump_stack+0x19/0x1b
    [  307.982201]  [<ffffffffbd2a2f58>] __warn+0xd8/0x100
    [  308.005999]  [<ffffffffbd2a2fdf>] warn_slowpath_fmt+0x5f/0x80
    [  308.034260]  [<ffffffffbd5f667e>] check_unmap+0x4ee/0xa20
    [  308.060801]  [<ffffffffbd41acaa>] ? page_add_file_rmap+0x2a/0x1d0
    [  308.090689]  [<ffffffffbd5f6c4d>] debug_dma_unmap_page+0x9d/0xb0
    [  308.120155]  [<ffffffffbd4082e0>] ? might_fault+0xa0/0xb0
    [  308.146656]  [<ffffffffc07761a5>] qib_tid_free.isra.14+0x215/0x2a0 [ib_qib]
    [  308.180739]  [<ffffffffc0776bf4>] qib_write+0x894/0x1280 [ib_qib]
    [  308.210733]  [<ffffffffbd540b00>] ? __inode_security_revalidate+0x70/0x80
    [  308.244837]  [<ffffffffbd53c2b7>] ? security_file_permission+0x27/0xb0
    [  308.266025] qib_ib0.8006: multicast join failed for
    ff12:401b:8006:0000:0000:0000:ffff:ffff, status -22
    [  308.323421]  [<ffffffffbd46f5d3>] vfs_write+0xc3/0x1f0
    [  308.347077]  [<ffffffffbd492a5c>] ? fget_light+0xfc/0x510
    [  308.372533]  [<ffffffffbd47045a>] SyS_write+0x8a/0x100
    [  308.396456]  [<ffffffffbd9ff355>] system_call_fastpath+0x1c/0x21
    
    The code calls a qib_map_page() which has never correctly tested for a
    mapping error.
    
    Fix by testing for pci_dma_mapping_error() in all cases and properly
    handling the failure in the caller.
    
    Additionally, streamline qib_map_page() arguments to satisfy just
    the single caller.
    
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Alex Estrin <alex.estrin@intel.com>
    Tested-by: Don Dutile <ddutile@redhat.com>
    Reviewed-by: Don Dutile <ddutile@redhat.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f92ec84c49f91756cbdd048c1a3136f15810cd94
Author: Stefan M Schaeckeler <sschaeck@cisco.com>
Date:   Mon May 21 16:26:14 2018 -0700

    of: unittest: for strings, account for trailing \0 in property length field
    
    commit 3b9cf7905fe3ab35ab437b5072c883e609d3498d upstream.
    
    For strings, account for trailing \0 in property length field:
    
    This is consistent with how dtc builds string properties.
    
    Function __of_prop_dup() would misbehave on such properties as it duplicates
    properties based on the property length field creating new string values
    without trailing \0s.
    
    Signed-off-by: Stefan M Schaeckeler <sschaeck@cisco.com>
    Reviewed-by: Frank Rowand <frank.rowand@sony.com>
    Tested-by: Frank Rowand <frank.rowand@sony.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb6786ce77ac4d65351832412703b8793e122f12
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Jun 22 16:23:45 2018 +0100

    arm64: mm: Ensure writes to swapper are ordered wrt subsequent cache maintenance
    
    commit 71c8fc0c96abf8e53e74ed4d891d671e585f9076 upstream.
    
    When rewriting swapper using nG mappings, we must performance cache
    maintenance around each page table access in order to avoid coherency
    problems with the host's cacheable alias under KVM. To ensure correct
    ordering of the maintenance with respect to Device memory accesses made
    with the Stage-1 MMU disabled, DMBs need to be added between the
    maintenance and the corresponding memory access.
    
    This patch adds a missing DMB between writing a new page table entry and
    performing a clean+invalidate on the same line.
    
    Fixes: f992b4dfd58b ("arm64: kpti: Add ->enable callback to remap swapper using nG mappings")
    Cc: <stable@vger.kernel.org> # 4.16.x-
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12942d52f23d79df25814730f559c54150ab3e84
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Jun 22 10:25:25 2018 +0100

    arm64: kpti: Use early_param for kpti= command-line option
    
    commit b5b7dd647f2d21b93f734ce890671cd908e69b0a upstream.
    
    We inspect __kpti_forced early on as part of the cpufeature enable
    callback which remaps the swapper page table using non-global entries.
    
    Ensure that __kpti_forced has been updated to reflect the kpti=
    command-line option before we start using it.
    
    Fixes: ea1e3de85e94 ("arm64: entry: Add fake CPU feature for unmapping the kernel at EL0")
    Cc: <stable@vger.kernel.org> # 4.16.x-
    Reported-by: Wei Xu <xuwei5@hisilicon.com>
    Tested-by: Sudeep Holla <sudeep.holla@arm.com>
    Tested-by: Wei Xu <xuwei5@hisilicon.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f27499338a23a9e6eada6ab3a126c0616b21296
Author: David Rivshin <DRivshin@allworx.com>
Date:   Wed Apr 25 21:15:01 2018 +0100

    ARM: 8764/1: kgdb: fix NUMREGBYTES so that gdb_regs[] is the correct size
    
    commit 76ed0b803a2ab793a1b27d1dfe0de7955282cd34 upstream.
    
    NUMREGBYTES (which is used as the size for gdb_regs[]) is incorrectly
    based on DBG_MAX_REG_NUM instead of GDB_MAX_REGS. DBG_MAX_REG_NUM
    is the number of total registers, while GDB_MAX_REGS is the number
    of 'unsigned longs' it takes to serialize those registers. Since
    FP registers require 3 'unsigned longs' each, DBG_MAX_REG_NUM is
    smaller than GDB_MAX_REGS.
    
    This causes GDB 8.0 give the following error on connect:
    "Truncated register 19 in remote 'g' packet"
    
    This also causes the register serialization/deserialization logic
    to overflow gdb_regs[], overwriting whatever follows.
    
    Fixes: 834b2964b7ab ("kgdb,arm: fix register dump")
    Cc: <stable@vger.kernel.org> # 2.6.37+
    Signed-off-by: David Rivshin <drivshin@allworx.com>
    Acked-by: Rabin Vincent <rabin@rab.in>
    Tested-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81d6e715d16124862aaeb4b9d9648fb40e9ae779
Author: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Date:   Fri Apr 27 11:53:18 2018 +0530

    powerpc/fadump: Unregister fadump on kexec down path.
    
    commit 722cde76d68e8cc4f3de42e71c82fd40dea4f7b9 upstream.
    
    Unregister fadump on kexec down path otherwise the fadump registration
    in new kexec-ed kernel complains that fadump is already registered.
    This makes new kernel to continue using fadump registered by previous
    kernel which may lead to invalid vmcore generation. Hence this patch
    fixes this issue by un-registering fadump in fadump_cleanup() which is
    called during kexec path so that new kernel can register fadump with
    new valid values.
    
    Fixes: b500afff11f6 ("fadump: Invalidate registration and release reserved memory for general use.")
    Cc: stable@vger.kernel.org # v3.4+
    Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 443004a666ede252f85bcdf8faab85d8174f0367
Author: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Date:   Thu May 31 17:45:09 2018 +0530

    cpuidle: powernv: Fix promotion from snooze if next state disabled
    
    commit 0a4ec6aa035a52c422eceb2ed51ed88392a3d6c2 upstream.
    
    The commit 78eaa10f027c ("cpuidle: powernv/pseries: Auto-promotion of
    snooze to deeper idle state") introduced a timeout for the snooze idle
    state so that it could be eventually be promoted to a deeper idle
    state. The snooze timeout value is static and set to the target
    residency of the next idle state, which would train the cpuidle
    governor to pick the next idle state eventually.
    
    The unfortunate side-effect of this is that if the next idle state(s)
    is disabled, the CPU will forever remain in snooze, despite the fact
    that the system is completely idle, and other deeper idle states are
    available.
    
    This patch fixes the issue by dynamically setting the snooze timeout
    to the target residency of the next enabled state on the device.
    
    Before Patch:
      POWER8 : Only nap disabled.
      $ cpupower monitor sleep 30
      sleep took 30.01297 seconds and exited with status 0
                    |Idle_Stats
      PKG |CORE|CPU | snoo | Nap  | Fast
         0|   8|   0| 96.41|  0.00|  0.00
         0|   8|   1| 96.43|  0.00|  0.00
         0|   8|   2| 96.47|  0.00|  0.00
         0|   8|   3| 96.35|  0.00|  0.00
         0|   8|   4| 96.37|  0.00|  0.00
         0|   8|   5| 96.37|  0.00|  0.00
         0|   8|   6| 96.47|  0.00|  0.00
         0|   8|   7| 96.47|  0.00|  0.00
    
      POWER9: Shallow states (stop0lite, stop1lite, stop2lite, stop0, stop1,
      stop2) disabled:
      $ cpupower monitor sleep 30
      sleep took 30.05033 seconds and exited with status 0
                    |Idle_Stats
      PKG |CORE|CPU | snoo | stop | stop | stop | stop | stop | stop | stop | stop
         0|  16|   0| 89.79|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00
         0|  16|   1| 90.12|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00
         0|  16|   2| 90.21|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00
         0|  16|   3| 90.29|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00
    
    After Patch:
      POWER8 : Only nap disabled.
      $ cpupower monitor sleep 30
      sleep took 30.01200 seconds and exited with status 0
                    |Idle_Stats
      PKG |CORE|CPU | snoo | Nap  | Fast
         0|   8|   0| 16.58|  0.00| 77.21
         0|   8|   1| 18.42|  0.00| 75.38
         0|   8|   2|  4.70|  0.00| 94.09
         0|   8|   3| 17.06|  0.00| 81.73
         0|   8|   4|  3.06|  0.00| 95.73
         0|   8|   5|  7.00|  0.00| 96.80
         0|   8|   6|  1.00|  0.00| 98.79
         0|   8|   7|  5.62|  0.00| 94.17
    
      POWER9: Shallow states (stop0lite, stop1lite, stop2lite, stop0, stop1,
      stop2) disabled:
    
      $ cpupower monitor sleep 30
      sleep took 30.02110 seconds and exited with status 0
                    |Idle_Stats
      PKG |CORE|CPU | snoo | stop | stop | stop | stop | stop | stop | stop | stop
         0|   0|   0|  0.69|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  9.39| 89.70
         0|   0|   1|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.05| 93.21
         0|   0|   2|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00| 89.93
         0|   0|   3|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00| 93.26
    
    Fixes: 78eaa10f027c ("cpuidle: powernv/pseries: Auto-promotion of snooze to deeper idle state")
    Cc: stable@vger.kernel.org # v4.2+
    Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
    Reviewed-by: Balbir Singh <bsingharora@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9b25660d64bd8f86db67b7cfa6d5c30f53627a0
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date:   Wed May 30 19:22:50 2018 +1000

    powerpc/powernv/ioda2: Remove redundant free of TCE pages
    
    commit 98fd72fe82527fd26618062b60cfd329451f2329 upstream.
    
    When IODA2 creates a PE, it creates an IOMMU table with it_ops::free
    set to pnv_ioda2_table_free() which calls pnv_pci_ioda2_table_free_pages().
    
    Since iommu_tce_table_put() calls it_ops::free when the last reference
    to the table is released, explicit call to pnv_pci_ioda2_table_free_pages()
    is not needed so let's remove it.
    
    This should fix double free in the case of PCI hotuplug as
    pnv_pci_ioda2_table_free_pages() does not reset neither
    iommu_table::it_base nor ::it_size.
    
    This was not exposed by SRIOV as it uses different code path via
    pnv_pcibios_sriov_disable().
    
    IODA1 does not inialize it_ops::free so it does not have this issue.
    
    Fixes: c5f7700bbd2e ("powerpc/powernv: Dynamically release PE")
    Cc: stable@vger.kernel.org # v4.8+
    Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90f88f05d8775d30c68f7cd2058d55c1a9d868da
Author: Michael Neuling <mikey@neuling.org>
Date:   Thu May 17 15:37:14 2018 +1000

    powerpc/ptrace: Fix enforcement of DAWR constraints
    
    commit cd6ef7eebf171bfcba7dc2df719c2a4958775040 upstream.
    
    Back when we first introduced the DAWR, in commit 4ae7ebe9522a
    ("powerpc: Change hardware breakpoint to allow longer ranges"), we
    screwed up the constraint making it a 1024 byte boundary rather than a
    512. This makes the check overly permissive. Fortunately GDB is the
    only real user and it always did they right thing, so we never
    noticed.
    
    This fixes the constraint to 512 bytes.
    
    Fixes: 4ae7ebe9522a ("powerpc: Change hardware breakpoint to allow longer ranges")
    Cc: stable@vger.kernel.org # v3.9+
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ea3b9bddf844e72f701ae8a8ebe75e431249435
Author: Michael Neuling <mikey@neuling.org>
Date:   Thu May 17 15:37:15 2018 +1000

    powerpc/ptrace: Fix setting 512B aligned breakpoints with PTRACE_SET_DEBUGREG
    
    commit 4f7c06e26ec9cf7fe9f0c54dc90079b6a4f4b2c3 upstream.
    
    In commit e2a800beaca1 ("powerpc/hw_brk: Fix off by one error when
    validating DAWR region end") we fixed setting the DAWR end point to
    its max value via PPC_PTRACE_SETHWDEBUG. Unfortunately we broke
    PTRACE_SET_DEBUGREG when setting a 512 byte aligned breakpoint.
    
    PTRACE_SET_DEBUGREG currently sets the length of the breakpoint to
    zero (memset() in hw_breakpoint_init()). This worked with
    arch_validate_hwbkpt_settings() before the above patch was applied but
    is now broken if the breakpoint is 512byte aligned.
    
    This sets the length of the breakpoint to 8 bytes when using
    PTRACE_SET_DEBUGREG.
    
    Fixes: e2a800beaca1 ("powerpc/hw_brk: Fix off by one error when validating DAWR region end")
    Cc: stable@vger.kernel.org # v3.11+
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10e46042f27d6bebcba97fe1a17af1eb7add7db9
Author: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Date:   Wed May 30 18:48:04 2018 +0530

    powerpc/mm/hash: Add missing isync prior to kernel stack SLB switch
    
    commit 91d06971881f71d945910de128658038513d1b24 upstream.
    
    Currently we do not have an isync, or any other context synchronizing
    instruction prior to the slbie/slbmte in _switch() that updates the
    SLB entry for the kernel stack.
    
    However that is not correct as outlined in the ISA.
    
    From Power ISA Version 3.0B, Book III, Chapter 11, page 1133:
    
      "Changing the contents of ... the contents of SLB entries ... can
       have the side effect of altering the context in which data
       addresses and instruction addresses are interpreted, and in which
       instructions are executed and data accesses are performed.
       ...
       These side effects need not occur in program order, and therefore
       may require explicit synchronization by software.
       ...
       The synchronizing instruction before the context-altering
       instruction ensures that all instructions up to and including that
       synchronizing instruction are fetched and executed in the context
       that existed before the alteration."
    
    And page 1136:
    
      "For data accesses, the context synchronizing instruction before the
       slbie, slbieg, slbia, slbmte, tlbie, or tlbiel instruction ensures
       that all preceding instructions that access data storage have
       completed to a point at which they have reported all exceptions
       they will cause."
    
    We're not aware of any bugs caused by this, but it should be fixed
    regardless.
    
    Add the missing isync when updating kernel stack SLB entry.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
    [mpe: Flesh out change log with more ISA text & explanation]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12715f3ef147e56cb3c570ec169de80f6717838e
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Thu May 31 12:26:10 2018 +0200

    fuse: fix control dir setup and teardown
    
    commit 6becdb601bae2a043d7fb9762c4d48699528ea6e upstream.
    
    syzbot is reporting NULL pointer dereference at fuse_ctl_remove_conn() [1].
    Since fc->ctl_ndents is incremented by fuse_ctl_add_conn() when new_inode()
    failed, fuse_ctl_remove_conn() reaches an inode-less dentry and tries to
    clear d_inode(dentry)->i_private field.
    
    Fix by only adding the dentry to the array after being fully set up.
    
    When tearing down the control directory, do d_invalidate() on it to get rid
    of any mounts that might have been added.
    
    [1] https://syzkaller.appspot.com/bug?id=f396d863067238959c91c0b7cfc10b163638cac6
    Reported-by: syzbot <syzbot+32c236387d66c4516827@syzkaller.appspotmail.com>
    Fixes: bafa96541b25 ("[PATCH] fuse: add control filesystem")
    Cc: <stable@vger.kernel.org> # v2.6.18
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0fbcaf9993ea291955ead3dac4b52457b3ec799
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Tue May 1 13:12:14 2018 +0900

    fuse: don't keep dead fuse_conn at fuse_fill_super().
    
    commit 543b8f8662fe6d21f19958b666ab0051af9db21a upstream.
    
    syzbot is reporting use-after-free at fuse_kill_sb_blk() [1].
    Since sb->s_fs_info field is not cleared after fc was released by
    fuse_conn_put() when initialization failed, fuse_kill_sb_blk() finds
    already released fc and tries to hold the lock. Fix this by clearing
    sb->s_fs_info field after calling fuse_conn_put().
    
    [1] https://syzkaller.appspot.com/bug?id=a07a680ed0a9290585ca424546860464dd9658db
    
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Reported-by: syzbot <syzbot+ec3986119086fe4eec97@syzkaller.appspotmail.com>
    Fixes: 3b463ae0c626 ("fuse: invalidation reverse calls")
    Cc: John Muir <john@jmuir.com>
    Cc: Csaba Henk <csaba@gluster.com>
    Cc: Anand Avati <avati@redhat.com>
    Cc: <stable@vger.kernel.org> # v2.6.31
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebdc37febe594035d8cf3f5424ce97a926d2cddf
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Thu Feb 8 15:17:38 2018 +0100

    fuse: atomic_o_trunc should truncate pagecache
    
    commit df0e91d488276086bc07da2e389986cae0048c37 upstream.
    
    Fuse has an "atomic_o_trunc" mode, where userspace filesystem uses the
    O_TRUNC flag in the OPEN request to truncate the file atomically with the
    open.
    
    In this mode there's no need to send a SETATTR request to userspace after
    the open, so fuse_do_setattr() checks this mode and returns.  But this
    misses the important step of truncating the pagecache.
    
    Add the missing parts of truncation to the ATTR_OPEN branch.
    
    Reported-by: Chad Austin <chadaustin@fb.com>
    Fixes: 6ff958edbf39 ("fuse: add atomic open+truncate support")
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1e9a633e660cbb792c2bc8409e7defd964bae95
Author: Amit Pundir <amit.pundir@linaro.org>
Date:   Mon Apr 16 12:10:24 2018 +0530

    Bluetooth: hci_qca: Avoid missing rampatch failure with userspace fw loader
    
    commit 7dc5fe0814c35ec4e7d2e8fa30abab72e0e6a172 upstream.
    
    AOSP use userspace firmware loader to load firmwares, which will
    return -EAGAIN in case qca/rampatch_00440302.bin is not found.
    Since there is no rampatch for dragonboard820c QCA controller
    revision, just make it work as is.
    
    CC: Loic Poulain <loic.poulain@linaro.org>
    CC: Nicolas Dechesne <nicolas.dechesne@linaro.org>
    CC: Marcel Holtmann <marcel@holtmann.org>
    CC: Johan Hedberg <johan.hedberg@gmail.com>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d11ec041b2c4fddd7d963cf09895fbcbe14fec2d
Author: Corey Minyard <cminyard@mvista.com>
Date:   Tue May 22 08:14:51 2018 -0500

    ipmi:bt: Set the timeout before doing a capabilities check
    
    commit fe50a7d0393a552e4539da2d31261a59d6415950 upstream.
    
    There was one place where the timeout value for an operation was
    not being set, if a capabilities request was done from idle.  Move
    the timeout value setting to before where that change might be
    requested.
    
    IMHO the cause here is the invisible returns in the macros.  Maybe
    that's a job for later, though.
    
    Reported-by: Nordmark Claes <Claes.Nordmark@tieto.com>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e4fab744be24bf88dac651c5878c831743c0fbe
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed May 30 08:19:22 2018 -0400

    branch-check: fix long->int truncation when profiling branches
    
    commit 2026d35741f2c3ece73c11eb7e4a15d7c2df9ebe upstream.
    
    The function __builtin_expect returns long type (see the gcc
    documentation), and so do macros likely and unlikely. Unfortunatelly, when
    CONFIG_PROFILE_ANNOTATED_BRANCHES is selected, the macros likely and
    unlikely expand to __branch_check__ and __branch_check__ truncates the
    long type to int. This unintended truncation may cause bugs in various
    kernel code (we found a bug in dm-writecache because of it), so it's
    better to fix __branch_check__ to return long.
    
    Link: http://lkml.kernel.org/r/alpine.LRH.2.02.1805300818140.24812@file01.intranet.prod.int.rdu2.redhat.com
    
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: stable@vger.kernel.org
    Fixes: 1f0d69a9fc815 ("tracing: profile likely and unlikely annotations")
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95f871342295f2a616fb28d5e0cf72939fe5db5d
Author: Matthias Schiffer <mschiffer@universe-factory.net>
Date:   Sat Mar 24 17:57:49 2018 +0100

    mips: ftrace: fix static function graph tracing
    
    commit 6fb8656646f996d1eef42e6d56203c4915cb9e08 upstream.
    
    ftrace_graph_caller was never run after calling ftrace_trace_function,
    breaking the function graph tracer. Fix this, bringing it in line with the
    x86 implementation.
    
    While we're at it, also streamline the control flow of _mcount a bit to
    reduce the number of branches.
    
    This issue was reported before:
    https://www.linux-mips.org/archives/linux-mips/2014-11/msg00295.html
    
    Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
    Tested-by: Matt Redfearn <matt.redfearn@mips.com>
    Patchwork: https://patchwork.linux-mips.org/patch/18929/
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: stable@vger.kernel.org # v3.17+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec7bea37c833616b63a740d1ba54d2a030b62b32
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Jun 1 11:28:22 2018 +0200

    lib/vsprintf: Remove atomic-unsafe support for %pCr
    
    commit 666902e42fd8344b923c02dc5b0f37948ff4f225 upstream.
    
    "%pCr" formats the current rate of a clock, and calls clk_get_rate().
    The latter obtains a mutex, hence it must not be called from atomic
    context.
    
    Remove support for this rarely-used format, as vsprintf() (and e.g.
    printk()) must be callable from any context.
    
    Any remaining out-of-tree users will start seeing the clock's name
    printed instead of its rate.
    
    Reported-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Fixes: 900cca2944254edd ("lib/vsprintf: add %pC{,n,r} format specifiers for clocks")
    Link: http://lkml.kernel.org/r/1527845302-12159-5-git-send-email-geert+renesas@glider.be
    To: Jia-Ju Bai <baijiaju1990@gmail.com>
    To: Jonathan Corbet <corbet@lwn.net>
    To: Michael Turquette <mturquette@baylibre.com>
    To: Stephen Boyd <sboyd@kernel.org>
    To: Zhang Rui <rui.zhang@intel.com>
    To: Eduardo Valentin <edubezval@gmail.com>
    To: Eric Anholt <eric@anholt.net>
    To: Stefan Wahren <stefan.wahren@i2se.com>
    To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: linux-doc@vger.kernel.org
    Cc: linux-clk@vger.kernel.org
    Cc: linux-pm@vger.kernel.org
    Cc: linux-serial@vger.kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-renesas-soc@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Cc: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: stable@vger.kernel.org # 4.1+
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 676b002f26f98214856dfebd3bba2673ed9037c9
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Jun 1 11:28:19 2018 +0200

    clk: renesas: cpg-mssr: Stop using printk format %pCr
    
    commit ef4b0be62641d296cf4c0ad8f75ab83ab066ed51 upstream.
    
    Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
    called in atomic context.
    
    Replace it by open-coding the operation.  This is safe here, as the code
    runs in task context.
    
    Link: http://lkml.kernel.org/r/1527845302-12159-2-git-send-email-geert+renesas@glider.be
    To: Jia-Ju Bai <baijiaju1990@gmail.com>
    To: Jonathan Corbet <corbet@lwn.net>
    To: Michael Turquette <mturquette@baylibre.com>
    To: Stephen Boyd <sboyd@kernel.org>
    To: Zhang Rui <rui.zhang@intel.com>
    To: Eduardo Valentin <edubezval@gmail.com>
    To: Eric Anholt <eric@anholt.net>
    To: Stefan Wahren <stefan.wahren@i2se.com>
    To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: linux-doc@vger.kernel.org
    Cc: linux-clk@vger.kernel.org
    Cc: linux-pm@vger.kernel.org
    Cc: linux-serial@vger.kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-renesas-soc@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Cc: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: stable@vger.kernel.org # 4.5+
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a879f6c232029d08aac63865c4779117d5114d5e
Author: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Date:   Sat Apr 28 22:51:39 2018 +0200

    ASoC: cirrus: i2s: Fix {TX|RX}LinCtrlData setup
    
    commit 5d302ed3cc80564fb835bed5fdba1e1250ecc9e5 upstream.
    
    According to "EP93xx User’s Guide", I2STXLinCtrlData and I2SRXLinCtrlData
    registers actually have different format. The only currently used bit
    (Left_Right_Justify) has different position. Fix this and simplify the
    whole setup taking into account the fact that both registers have zero
    default value.
    
    The practical effect of the above is repaired SND_SOC_DAIFMT_RIGHT_J
    support (currently unused).
    
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6aa7326e812915f84098164f0699fdc2ace6a0c
Author: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Date:   Sat Apr 28 22:51:38 2018 +0200

    ASoC: cirrus: i2s: Fix LRCLK configuration
    
    commit 2d534113be9a2aa532a1ae127a57e83558aed358 upstream.
    
    The bit responsible for LRCLK polarity is i2s_tlrs (0), not i2s_trel (2)
    (refer to "EP93xx User's Guide").
    
    Previously card drivers which specified SND_SOC_DAIFMT_NB_IF actually got
    SND_SOC_DAIFMT_NB_NF, an adaptation is necessary to retain the old
    behavior.
    
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a1b2790f0bc991fcd21ad2e781dc7c1690446a8
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Mon Jun 4 12:13:26 2018 +0100

    ASoC: dapm: delete dapm_kcontrol_data paths list before freeing it
    
    commit ff2faf1289c1f81b5b26b9451dd1c2006aac8db8 upstream.
    
    dapm_kcontrol_data is freed as part of dapm_kcontrol_free(), leaving the
    paths pointer dangling in the list.
    
    This leads to system crash when we try to unload and reload sound card.
    I hit this bug during ADSP crash/reboot test case on Dragon board DB410c.
    
    Without this patch, on SLAB Poisoning enabled build, kernel crashes with
    "BUG kmalloc-128 (Tainted: G        W        ): Poison overwritten"
    
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf05568cb828cbbe7c36c19187ff68aa1c2bd512
Author: Ingo Flaschberger <ingo.flaschberger@gmail.com>
Date:   Tue May 1 16:10:33 2018 +0200

    1wire: family module autoload fails because of upper/lower case mismatch.
    
    commit 065c09563c872e52813a17218c52cd642be1dca6 upstream.
    
    1wire family module autoload fails because of upper/lower
      case mismatch.
    
    Signed-off-by: Ingo Flaschberger <ingo.flaschberger@gmail.com>
    Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55365ad775af75e1ea56a496e845bd43cbf276bf
Author: Maxim Moseychuk <franchesko.salias.hudro.pedros@gmail.com>
Date:   Thu Jan 4 21:43:03 2018 +0300

    usb: do not reset if a low-speed or full-speed device timed out
    
    commit 6e01827ed93947895680fbdad68c072a0f4e2450 upstream.
    
    Some low-speed and full-speed devices (for example, bluetooth)
    do not have time to initialize. For them, ETIMEDOUT is a valid error.
    We need to give them another try. Otherwise, they will
    never be initialized correctly and in dmesg will be messages
    "Bluetooth: hci0 command 0x1002 tx timeout" or similars.
    
    Fixes: 264904ccc33c ("usb: retry reset if a device times out")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Maxim Moseychuk <franchesko.salias.hudro.pedros@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c82ccd7122be45daa107244240a2ede87e562b86
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Fri Apr 20 09:14:56 2018 -0500

    signal/xtensa: Consistenly use SIGBUS in do_unaligned_user
    
    commit 7de712ccc096b81d23cc0a941cd9b8cb3956605d upstream.
    
    While working on changing this code to use force_sig_fault I
    discovered that do_unaliged_user is sets si_signo to SIGBUS and passes
    SIGSEGV to force_sig_info.  Which is just b0rked.
    
    The code is reporting a SIGBUS error so replace the SIGSEGV with SIGBUS.
    
    Cc: Chris Zankel <chris@zankel.net>
    Cc: Max Filippov <jcmvbkbc@gmail.com>
    Cc: linux-xtensa@linux-xtensa.org
    Cc: stable@vger.kernel.org
    Acked-by: Max Filippov <jcmvbkbc@gmail.com>
    Fixes: 5a0015d62668 ("[PATCH] xtensa: Architecture support for Tensilica Xtensa Part 3")
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9c202b269dd752c977fb1eb3cc6875a69899648
Author: Daniel Wagner <daniel.wagner@siemens.com>
Date:   Tue May 8 10:55:09 2018 +0200

    serial: sh-sci: Use spin_{try}lock_irqsave instead of open coding version
    
    commit 8afb1d2c12163f77777f84616a8e9444d0050ebe upstream.
    
    Commit 40f70c03e33a ("serial: sh-sci: add locking to console write
    function to avoid SMP lockup") copied the strategy to avoid locking
    problems in conjuncture with the console from the UART8250
    driver. Instead using directly spin_{try}lock_irqsave(),
    local_irq_save() followed by spin_{try}lock() was used. While this is
    correct on mainline, for -rt it is a problem. spin_{try}lock() will
    check if it is running in a valid context. Since the local_irq_save()
    has already been executed, the context has changed and
    spin_{try}lock() will complain. The reason why spin_{try}lock()
    complains is that on -rt the spin locks are turned into mutexes and
    therefore can sleep. Sleeping with interrupts disabled is not valid.
    
    BUG: sleeping function called from invalid context at /home/wagi/work/rt/v4.4-cip-rt/kernel/locking/rtmutex.c:995
    in_atomic(): 0, irqs_disabled(): 128, pid: 778, name: irq/76-eth0
    CPU: 0 PID: 778 Comm: irq/76-eth0 Not tainted 4.4.126-test-cip22-rt14-00403-gcd03665c8318 #12
    Hardware name: Generic RZ/G1 (Flattened Device Tree)
    Backtrace:
    [<c00140a0>] (dump_backtrace) from [<c001424c>] (show_stack+0x18/0x1c)
     r7:c06b01f0 r6:60010193 r5:00000000 r4:c06b01f0
    [<c0014234>] (show_stack) from [<c01d3c94>] (dump_stack+0x78/0x94)
    [<c01d3c1c>] (dump_stack) from [<c004c134>] (___might_sleep+0x134/0x194)
     r7:60010113 r6:c06d3559 r5:00000000 r4:ffffe000
    [<c004c000>] (___might_sleep) from [<c04ded60>] (rt_spin_lock+0x20/0x74)
     r5:c06f4d60 r4:c06f4d60
    [<c04ded40>] (rt_spin_lock) from [<c02577e4>] (serial_console_write+0x100/0x118)
     r5:c06f4d60 r4:c06f4d60
    [<c02576e4>] (serial_console_write) from [<c0061060>] (call_console_drivers.constprop.15+0x10c/0x124)
     r10:c06d2894 r9:c04e18b0 r8:00000028 r7:00000000 r6:c06d3559 r5:c06d2798
     r4:c06b9914 r3:c02576e4
    [<c0060f54>] (call_console_drivers.constprop.15) from [<c0062984>] (console_unlock+0x32c/0x430)
     r10:c06d30d8 r9:00000028 r8:c06dd518 r7:00000005 r6:00000000 r5:c06d2798
     r4:c06d2798 r3:00000028
    [<c0062658>] (console_unlock) from [<c0062e1c>] (vprintk_emit+0x394/0x4f0)
     r10:c06d2798 r9:c06d30ee r8:00000006 r7:00000005 r6:c06a78fc r5:00000027
     r4:00000003
    [<c0062a88>] (vprintk_emit) from [<c0062fa0>] (vprintk+0x28/0x30)
     r10:c060bd46 r9:00001000 r8:c06b9a90 r7:c06b9a90 r6:c06b994c r5:c06b9a3c
     r4:c0062fa8
    [<c0062f78>] (vprintk) from [<c0062fb8>] (vprintk_default+0x10/0x14)
    [<c0062fa8>] (vprintk_default) from [<c009cd30>] (printk+0x78/0x84)
    [<c009ccbc>] (printk) from [<c025afdc>] (credit_entropy_bits+0x17c/0x2cc)
     r3:00000001 r2:decade60 r1:c061a5ee r0:c061a523
     r4:00000006
    [<c025ae60>] (credit_entropy_bits) from [<c025bf74>] (add_interrupt_randomness+0x160/0x178)
     r10:466e7196 r9:1f536000 r8:fffeef74 r7:00000000 r6:c06b9a60 r5:c06b9a3c
     r4:dfbcf680
    [<c025be14>] (add_interrupt_randomness) from [<c006536c>] (irq_thread+0x1e8/0x248)
     r10:c006537c r9:c06cdf21 r8:c0064fcc r7:df791c24 r6:df791c00 r5:ffffe000
     r4:df525180
    [<c0065184>] (irq_thread) from [<c003fba4>] (kthread+0x108/0x11c)
     r10:00000000 r9:00000000 r8:c0065184 r7:df791c00 r6:00000000 r5:df791d00
     r4:decac000
    [<c003fa9c>] (kthread) from [<c00101b8>] (ret_from_fork+0x14/0x3c)
     r8:00000000 r7:00000000 r6:00000000 r5:c003fa9c r4:df791d00
    
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Daniel Wagner <daniel.wagner@siemens.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5692dcf90e6907e6ea09707b6c7426f36f905772
Author: Michael Schmitz <schmitzmic@gmail.com>
Date:   Mon May 14 23:10:53 2018 +1200

    m68k/mm: Adjust VM area to be unmapped by gap size for __iounmap()
    
    commit 3f90f9ef2dda316d64e420d5d51ba369587ccc55 upstream.
    
    If 020/030 support is enabled, get_io_area() leaves an IO_SIZE gap
    between mappings which is added to the vm_struct representing the
    mapping.  __ioremap() uses the actual requested size (after alignment),
    while __iounmap() is passed the size from the vm_struct.
    
    On 020/030, early termination descriptors are used to set up mappings of
    extent 'size', which are validated on unmapping. The unmapped gap of
    size IO_SIZE defeats the sanity check of the pmd tables, causing
    __iounmap() to loop forever on 030.
    
    On 040/060, unmapping of page table entries does not check for a valid
    mapping, so the umapping loop always completes there.
    
    Adjust size to be unmapped by the gap that had been added in the
    vm_struct prior.
    
    This fixes the hang in atari_platform_init() reported a long time ago,
    and a similar one reported by Finn recently (addressed by removing
    ioremap() use from the SWIM driver.
    
    Tested on my Falcon in 030 mode - untested but should work the same on
    040/060 (the extra page tables cleared there would never have been set
    up anyway).
    
    Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
    [geert: Minor commit description improvements]
    [geert: This was fixed in 2.4.23, but not in 2.5.x]
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a68dcdc9d22080c974bb5472cae7d1799ec8607
Author: Siarhei Liakh <Siarhei.Liakh@concurrent-rt.com>
Date:   Thu Jun 14 19:36:07 2018 +0000

    x86: Call fixup_exception() before notify_die() in math_error()
    
    commit 3ae6295ccb7cf6d344908209701badbbbb503e40 upstream.
    
    fpu__drop() has an explicit fwait which under some conditions can trigger a
    fixable FPU exception while in kernel. Thus, we should attempt to fixup the
    exception first, and only call notify_die() if the fixup failed just like
    in do_general_protection(). The original call sequence incorrectly triggers
    KDB entry on debug kernels under particular FPU-intensive workloads.
    
    Andy noted, that this makes the whole conditional irq enable thing even
    more inconsistent, but fixing that it outside the scope of this.
    
    Signed-off-by: Siarhei Liakh <siarhei.liakh@concurrent-rt.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Andy Lutomirski <luto@kernel.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: "Borislav  Petkov" <bpetkov@suse.de>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/DM5PR11MB201156F1CAB2592B07C79A03B17D0@DM5PR11MB2011.namprd11.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a48f6084de709dbc55c56d91fc78011ae6c4b0e
Author: Borislav Petkov <bp@suse.de>
Date:   Fri Jun 22 11:54:28 2018 +0200

    x86/mce: Do not overwrite MCi_STATUS in mce_no_way_out()
    
    commit 1f74c8a64798e2c488f86efc97e308b85fb7d7aa upstream.
    
    mce_no_way_out() does a quick check during #MC to see whether some of
    the MCEs logged would require the kernel to panic immediately. And it
    passes a struct mce where MCi_STATUS gets written.
    
    However, after having saved a valid status value, the next iteration
    of the loop which goes over the MCA banks on the CPU, overwrites the
    valid status value because we're using struct mce as storage instead of
    a temporary variable.
    
    Which leads to MCE records with an empty status value:
    
      mce: [Hardware Error]: CPU 0: Machine Check Exception: 6 Bank 0: 0000000000000000
      mce: [Hardware Error]: RIP 10:<ffffffffbd42fbd7> {trigger_mce+0x7/0x10}
    
    In order to prevent the loss of the status register value, return
    immediately when severity is a panic one so that we can panic
    immediately with the first fatal MCE logged. This is also the intention
    of this function and not to noodle over the banks while a fatal MCE is
    already logged.
    
    Tony: read the rest of the MCA bank to populate the struct mce fully.
    
    Suggested-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20180622095428.626-8-bp@alien8.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c267eaaceb58e0acf0132a509ce58649add44f5e
Author: Tony Luck <tony.luck@intel.com>
Date:   Fri Jun 22 11:54:23 2018 +0200

    x86/mce: Fix incorrect "Machine check from unknown source" message
    
    commit 40c36e2741d7fe1e66d6ec55477ba5fd19c9c5d2 upstream.
    
    Some injection testing resulted in the following console log:
    
      mce: [Hardware Error]: CPU 22: Machine Check Exception: f Bank 1: bd80000000100134
      mce: [Hardware Error]: RIP 10:<ffffffffc05292dd> {pmem_do_bvec+0x11d/0x330 [nd_pmem]}
      mce: [Hardware Error]: TSC c51a63035d52 ADDR 3234bc4000 MISC 88
      mce: [Hardware Error]: PROCESSOR 0:50654 TIME 1526502199 SOCKET 0 APIC 38 microcode 2000043
      mce: [Hardware Error]: Run the above through 'mcelog --ascii'
      Kernel panic - not syncing: Machine check from unknown source
    
    This confused everybody because the first line quite clearly shows
    that we found a logged error in "Bank 1", while the last line says
    "unknown source".
    
    The problem is that the Linux code doesn't do the right thing
    for a local machine check that results in a fatal error.
    
    It turns out that we know very early in the handler whether the
    machine check is fatal. The call to mce_no_way_out() has checked
    all the banks for the CPU that took the local machine check. If
    it says we must crash, we can do so right away with the right
    messages.
    
    We do scan all the banks again. This means that we might initially
    not see a problem, but during the second scan find something fatal.
    If this happens we print a slightly different message (so I can
    see if it actually every happens).
    
    [ bp: Remove unneeded severity assignment. ]
    
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ashok Raj <ashok.raj@intel.com>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
    Cc: linux-edac <linux-edac@vger.kernel.org>
    Cc: stable@vger.kernel.org # 4.2
    Link: http://lkml.kernel.org/r/52e049a497e86fd0b71c529651def8871c804df0.1527283897.git.tony.luck@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7905a78ad570760210192307d9dc69051a072bd
Author: Tony Luck <tony.luck@intel.com>
Date:   Fri May 25 14:42:09 2018 -0700

    x86/mce: Check for alternate indication of machine check recovery on Skylake
    
    commit 4c5717da1d021cf368eabb3cb1adcaead56c0d1e upstream.
    
    Currently we just check the "CAPID0" register to see whether the CPU
    can recover from machine checks.
    
    But there are also some special SKUs which do not have all advanced
    RAS features, but do enable machine check recovery for use with NVDIMMs.
    
    Add a check for any of bits {8:5} in the "CAPID5" register (each
    reports some NVDIMM mode available, if any of them are set, then
    the system supports memory machine check recovery).
    
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
    Cc: Ashok Raj <ashok.raj@intel.com>
    Cc: stable@vger.kernel.org # 4.9
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/03cbed6e99ddafb51c2eadf9a3b7c8d7a0cc204e.1527283897.git.tony.luck@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4eb80a751d3f9ece95255dbcb38539f2c96acac
Author: Tony Luck <tony.luck@intel.com>
Date:   Fri May 25 14:41:39 2018 -0700

    x86/mce: Improve error message when kernel cannot recover
    
    commit c7d606f560e4c698884697fef503e4abacdd8c25 upstream.
    
    Since we added support to add recovery from some errors inside the kernel in:
    
    commit b2f9d678e28c ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries")
    
    we have done a less than stellar job at reporting the cause of recoverable
    machine checks that occur in other parts of the kernel. The user just gets
    the unhelpful message:
    
            mce: [Hardware Error]: Machine check: Action required: unknown MCACOD
    
    doubly unhelpful when they check the manual for the reported IA32_MSR_STATUS.MCACOD
    and see that it is listed as one of the standard recoverable values.
    
    Add an extra rule to the MCE severity table to catch this case and report it
    as:
    
            mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel
    
    Fixes: b2f9d678e28c ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries")
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
    Cc: Ashok Raj <ashok.raj@intel.com>
    Cc: stable@vger.kernel.org # 4.6+
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/4cc7c465150a9a48b8b9f45d0b840278e77eb9b5.1527283897.git.tony.luck@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 995cddcc3337088b2129dddc7d59fe0282d15d5f
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Jun 7 09:13:48 2018 -0700

    x86/spectre_v1: Disable compiler optimizations over array_index_mask_nospec()
    
    commit eab6870fee877258122a042bfd99ee7908c40280 upstream.
    
    Mark Rutland noticed that GCC optimization passes have the potential to elide
    necessary invocations of the array_index_mask_nospec() instruction sequence,
    so mark the asm() volatile.
    
    Mark explains:
    
    "The volatile will inhibit *some* cases where the compiler could lift the
     array_index_nospec() call out of a branch, e.g. where there are multiple
     invocations of array_index_nospec() with the same arguments:
    
            if (idx < foo) {
                    idx1 = array_idx_nospec(idx, foo)
                    do_something(idx1);
            }
    
            < some other code >
    
            if (idx < foo) {
                    idx2 = array_idx_nospec(idx, foo);
                    do_something_else(idx2);
            }
    
     ... since the compiler can determine that the two invocations yield the same
     result, and reuse the first result (likely the same register as idx was in
     originally) for the second branch, effectively re-writing the above as:
    
            if (idx < foo) {
                    idx = array_idx_nospec(idx, foo);
                    do_something(idx);
            }
    
            < some other code >
    
            if (idx < foo) {
                    do_something_else(idx);
            }
    
     ... if we don't take the first branch, then speculatively take the second, we
     lose the nospec protection.
    
     There's more info on volatile asm in the GCC docs:
    
       https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile
     "
    
    Reported-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: <stable@vger.kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Fixes: babdde2698d4 ("x86: Implement array_index_mask_nospec")
    Link: https://lkml.kernel.org/lkml/152838798950.14521.4893346294059739135.stgit@dwillia2-desk3.amr.corp.intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>