commit 8979da2558a4993989542e1d2db23b426b148ae9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jan 16 22:07:13 2019 +0100

    Linux 4.14.94

commit cb754d67c084d4e673c3dd420636d7e8eb81b024
Author: Christoffer Dall <christoffer.dall@arm.com>
Date:   Tue Dec 11 13:23:57 2018 +0100

    KVM: arm/arm64: Fix VMID alloc race by reverting to lock-less
    
    commit fb544d1ca65a89f7a3895f7531221ceeed74ada7 upstream.
    
    We recently addressed a VMID generation race by introducing a read/write
    lock around accesses and updates to the vmid generation values.
    
    However, kvm_arch_vcpu_ioctl_run() also calls need_new_vmid_gen() but
    does so without taking the read lock.
    
    As far as I can tell, this can lead to the same kind of race:
    
      VM 0, VCPU 0                  VM 0, VCPU 1
      ------------                  ------------
      update_vttbr (vmid 254)
                                    update_vttbr (vmid 1) // roll over
                                    read_lock(kvm_vmid_lock);
                                    force_vm_exit()
      local_irq_disable
      need_new_vmid_gen == false //because vmid gen matches
    
      enter_guest (vmid 254)
                                    kvm_arch.vttbr = <PGD>:<VMID 1>
                                    read_unlock(kvm_vmid_lock);
    
                                    enter_guest (vmid 1)
    
    Which results in running two VCPUs in the same VM with different VMIDs
    and (even worse) other VCPUs from other VMs could now allocate clashing
    VMID 254 from the new generation as long as VCPU 0 is not exiting.
    
    Attempt to solve this by making sure vttbr is updated before another CPU
    can observe the updated VMID generation.
    
    Cc: stable@vger.kernel.org
    Fixes: f0cf47d939d0 "KVM: arm/arm64: Close VMID generation race"
    Reviewed-by: Julien Thierry <julien.thierry@arm.com>
    Signed-off-by: Christoffer Dall <christoffer.dall@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65dba32522065b79a16393efc75f8006c2c3dbb8
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Mon Dec 24 14:44:52 2018 +0300

    sunrpc: use-after-free in svc_process_common()
    
    commit d4b09acf924b84bae77cad090a9d108e70b43643 upstream.
    
    if node have NFSv41+ mounts inside several net namespaces
    it can lead to use-after-free in svc_process_common()
    
    svc_process_common()
            /* Setup reply header */
            rqstp->rq_xprt->xpt_ops->xpo_prep_reply_hdr(rqstp); <<< HERE
    
    svc_process_common() can use incorrect rqstp->rq_xprt,
    its caller function bc_svc_process() takes it from serv->sv_bc_xprt.
    The problem is that serv is global structure but sv_bc_xprt
    is assigned per-netnamespace.
    
    According to Trond, the whole "let's set up rqstp->rq_xprt
    for the back channel" is nothing but a giant hack in order
    to work around the fact that svc_process_common() uses it
    to find the xpt_ops, and perform a couple of (meaningless
    for the back channel) tests of xpt_flags.
    
    All we really need in svc_process_common() is to be able to run
    rqstp->rq_xprt->xpt_ops->xpo_prep_reply_hdr()
    
    Bruce J Fields points that this xpo_prep_reply_hdr() call
    is an awfully roundabout way just to do "svc_putnl(resv, 0);"
    in the tcp case.
    
    This patch does not initialiuze rqstp->rq_xprt in bc_svc_process(),
    now it calls svc_process_common() with rqstp->rq_xprt = NULL.
    
    To adjust reply header svc_process_common() just check
    rqstp->rq_prot and calls svc_tcp_prep_reply_hdr() for tcp case.
    
    To handle rqstp->rq_xprt = NULL case in functions called from
    svc_process_common() patch intruduces net namespace pointer
    svc_rqst->rq_bc_net and adjust SVC_NET() definition.
    Some other function was also adopted to properly handle described case.
    
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Cc: stable@vger.kernel.org
    Fixes: 23c20ecd4475 ("NFS: callback up - users counting cleanup")
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    v2: - added lost extern svc_tcp_prep_reply_hdr()
        - dropped trace_svc_process() changes
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5903fc6477b1aed7db1165a7f328948e6ef93ef1
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Mon Dec 31 00:11:07 2018 -0500

    ext4: track writeback errors using the generic tracking infrastructure
    
    commit 95cb67138746451cc84cf8e516e14989746e93b0 upstream.
    
    We already using mapping_set_error() in fs/ext4/page_io.c, so all we
    need to do is to use file_check_and_advance_wb_err() when handling
    fsync() requests in ext4_sync_file().
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82f71b8bc05c6866b7dfae96ebca5ee102f76afa
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Mon Dec 31 00:10:48 2018 -0500

    ext4: use ext4_write_inode() when fsyncing w/o a journal
    
    commit ad211f3e94b314a910d4af03178a0b52a7d1ee0a upstream.
    
    In no-journal mode, we previously used __generic_file_fsync() in
    no-journal mode.  This triggers a lockdep warning, and in addition,
    it's not safe to depend on the inode writeback mechanism in the case
    ext4.  We can solve both problems by calling ext4_write_inode()
    directly.
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b17971aeaf144ec627b0516ecc990c0a3fd278fe
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sun Dec 30 23:20:39 2018 -0500

    ext4: avoid kernel warning when writing the superblock to a dead device
    
    commit e86807862e6880809f191c4cea7f88a489f0ed34 upstream.
    
    The xfstests generic/475 test switches the underlying device with
    dm-error while running a stress test.  This results in a large number
    of file system errors, and since we can't lock the buffer head when
    marking the superblock dirty in the ext4_grp_locked_error() case, it's
    possible the superblock to be !buffer_uptodate() without
    buffer_write_io_error() being true.
    
    We need to set buffer_uptodate() before we call mark_buffer_dirty() or
    this will trigger a WARN_ON.  It's safe to do this since the
    superblock must have been properly read into memory or the mount would
    have been successful.  So if buffer_uptodate() is not set, we can
    safely assume that this happened due to a failed attempt to write the
    superblock.
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4727299f58df8c7feaac247f7b841b610b5cbaf
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Tue Dec 25 00:56:33 2018 -0500

    ext4: fix a potential fiemap/page fault deadlock w/ inline_data
    
    commit 2b08b1f12cd664dc7d5c84ead9ff25ae97ad5491 upstream.
    
    The ext4_inline_data_fiemap() function calls fiemap_fill_next_extent()
    while still holding the xattr semaphore.  This is not necessary and it
    triggers a circular lockdep warning.  This is because
    fiemap_fill_next_extent() could trigger a page fault when it writes
    into page which triggers a page fault.  If that page is mmaped from
    the inline file in question, this could very well result in a
    deadlock.
    
    This problem can be reproduced using generic/519 with a file system
    configuration which has the inline_data feature enabled.
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb13c60d82db21411ba2ea4557494450a9d6fa11
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Mon Dec 24 20:27:08 2018 -0500

    ext4: make sure enough credits are reserved for dioread_nolock writes
    
    commit 812c0cab2c0dfad977605dbadf9148490ca5d93f upstream.
    
    There are enough credits reserved for most dioread_nolock writes;
    however, if the extent tree is sufficiently deep, and/or quota is
    enabled, the code was not allowing for all eventualities when
    reserving journal credits for the unwritten extent conversion.
    
    This problem can be seen using xfstests ext4/034:
    
       WARNING: CPU: 1 PID: 257 at fs/ext4/ext4_jbd2.c:271 __ext4_handle_dirty_metadata+0x10c/0x180
       Workqueue: ext4-rsv-conversion ext4_end_io_rsv_work
       RIP: 0010:__ext4_handle_dirty_metadata+0x10c/0x180
            ...
       EXT4-fs: ext4_free_blocks:4938: aborting transaction: error 28 in __ext4_handle_dirty_metadata
       EXT4: jbd2_journal_dirty_metadata failed: handle type 11 started at line 4921, credits 4/0, errcode -28
       EXT4-fs error (device dm-1) in ext4_free_blocks:4950: error 28
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 022ce60cc621c84df6d0272984e791f60983fd7a
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Tue Jan 8 19:47:38 2019 +0100

    rbd: don't return 0 on unmap if RBD_DEV_FLAG_REMOVING is set
    
    commit 85f5a4d666fd9be73856ed16bb36c5af5b406b29 upstream.
    
    There is a window between when RBD_DEV_FLAG_REMOVING is set and when
    the device is removed from rbd_dev_list.  During this window, we set
    "already" and return 0.
    
    Returning 0 from write(2) can confuse userspace tools because
    0 indicates that nothing was written.  In particular, "rbd unmap"
    will retry the write multiple times a second:
    
      10:28:05.463299 write(4, "0", 1)        = 0
      10:28:05.463509 write(4, "0", 1)        = 0
      10:28:05.463720 write(4, "0", 1)        = 0
      10:28:05.463942 write(4, "0", 1)        = 0
      10:28:05.464155 write(4, "0", 1)        = 0
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Tested-by: Dongsheng Yang <dongsheng.yang@easystack.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b99f1705b5d545c23fc629e51063915e7bb3fce
Author: Ivan Mironov <mironov.ivan@gmail.com>
Date:   Tue Jan 8 12:23:52 2019 +0500

    drm/fb-helper: Partially bring back workaround for bugs of SDL 1.2
    
    commit 62d85b3bf9d978ed4b6b2aeef5cf0ccf1423906e upstream.
    
    SDL 1.2 sets all fields related to the pixel format to zero in some
    cases[1]. Prior to commit db05c48197759 ("drm: fb-helper: Reject all
    pixel format changing requests"), there was an unintentional workaround
    for this that existed for more than a decade. First in device-specific DRM
    drivers, then here in drm_fb_helper.c.
    
    Previous code containing this workaround just ignores pixel format fields
    from userspace code. Not a good thing either, as this way, driver may
    silently use pixel format different from what client actually requested,
    and this in turn will lead to displaying garbage on the screen. I think
    that returning EINVAL to userspace in this particular case is the right
    option, so I decided to left code from problematic commit untouched
    instead of just reverting it entirely.
    
    Here is the steps required to reproduce this problem exactly:
            1) Compile fceux[2] with SDL 1.2.15 and without GTK or OpenGL
               support. SDL should be compiled with fbdev support (which is
               on by default).
            2) Create /etc/fb.modes with following contents (values seems
               not used, and just required to trigger problematic code in
               SDL):
    
                    mode "test"
                        geometry 1 1 1 1 1
                        timings 1 1 1 1 1 1 1
                    endmode
    
            3) Create ~/.fceux/fceux.cfg with following contents:
    
                    SDL.Hotkeys.Quit = 27
                    SDL.DoubleBuffering = 1
    
            4) Ensure that screen resolution is at least 1280x960 (e.g.
               append "video=Virtual-1:1280x960-32" to the kernel cmdline
               for qemu/QXL).
    
            5) Try to run fceux on VT with some ROM file[3]:
    
                    # ./fceux color_test.nes
    
    [1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c,
        FB_SetVideoMode()
    [2] http://www.fceux.com
    [3] Example ROM: https://github.com/bokuweb/rustynes/blob/master/roms/color_test.nes
    
    Reported-by: saahriktu <mail@saahriktu.org>
    Suggested-by: saahriktu <mail@saahriktu.org>
    Cc: stable@vger.kernel.org
    Fixes: db05c48197759 ("drm: fb-helper: Reject all pixel format changing requests")
    Signed-off-by: Ivan Mironov <mironov.ivan@gmail.com>
    [danvet: Delete misleading comment.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-2-mironov.ivan@gmail.com
    Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-2-mironov.ivan@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78e5ef1add51528d0e3818bacdb4739fc6661c78
Author: Yi Zeng <yizeng@asrmicro.com>
Date:   Wed Jan 9 15:33:07 2019 +0800

    i2c: dev: prevent adapter retries and timeout being set as minus value
    
    commit 6ebec961d59bccf65d08b13fc1ad4e6272a89338 upstream.
    
    If adapter->retries is set to a minus value from user space via ioctl,
    it will make __i2c_transfer and __i2c_smbus_xfer skip the calling to
    adapter->algo->master_xfer and adapter->algo->smbus_xfer that is
    registered by the underlying bus drivers, and return value 0 to all the
    callers. The bus driver will never be accessed anymore by all users,
    besides, the users may still get successful return value without any
    error or information log print out.
    
    If adapter->timeout is set to minus value from user space via ioctl,
    it will make the retrying loop in __i2c_transfer and __i2c_smbus_xfer
    always break after the the first try, due to the time_after always
    returns true.
    
    Signed-off-by: Yi Zeng <yizeng@asrmicro.com>
    [wsa: minor grammar updates to commit message]
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3db93d2be900a920aca76a557010a90e2c4a877
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Jan 4 23:10:54 2019 +0100

    ACPI / PMIC: xpower: Fix TS-pin current-source handling
    
    commit 2b531d71595d2b5b12782a49b23c335869e2621e upstream.
    
    The current-source used for the battery temp-sensor (TS) is shared with the
    GPADC. For proper fuel-gauge and charger operation the TS current-source
    needs to be permanently on. But to read the GPADC we need to temporary
    switch the TS current-source to ondemand, so that the GPADC can use it,
    otherwise we will always read an all 0 value.
    
    The switching from on to on-ondemand is not necessary when the TS
    current-source is off (this happens on devices which do not have a TS).
    
    Prior to this commit there were 2 issues with our handling of the TS
    current-source switching:
    
     1) We were writing hardcoded values to the ADC TS pin-ctrl register,
     overwriting various other unrelated bits. Specifically we were overwriting
     the current-source setting for the TS and GPIO0 pins, forcing it to 80ųA
     independent of its original setting. On a Chuwi Vi10 tablet this was
     causing us to get a too high adc value (due to a too high current-source)
     resulting in acpi_lpat_raw_to_temp() returning -ENOENT, resulting in:
    
    ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion]
    ACPI Error: Method parse/execution failed \_SB.SXP1._TMP, AE_ERROR
    
    This commit fixes this by using regmap_update_bits to change only the
    relevant bits.
    
     2) At the end of intel_xpower_pmic_get_raw_temp() we were unconditionally
     enabling the TS current-source even on devices where the TS-pin is not used
     and the current-source thus was off on entry of the function.
    
    This commit fixes this by checking if the TS current-source is off when
    entering intel_xpower_pmic_get_raw_temp() and if so it is left as is.
    
    Fixes: 58eefe2f3f53 (ACPI / PMIC: xpower: Do pinswitch ... reading GPADC)
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec697eb3b840abae279a59725223d4a10dee8938
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Dec 30 18:25:00 2018 +0100

    ACPI: power: Skip duplicate power resource references in _PRx
    
    commit 7d7b467cb95bf29597b417d4990160d4ea6d69b9 upstream.
    
    Some ACPI tables contain duplicate power resource references like this:
    
            Name (_PR0, Package (0x04)  // _PR0: Power Resources for D0
            {
                P28P,
                P18P,
                P18P,
                CLK4
            })
    
    This causes a WARN_ON in sysfs_add_link_to_group() because we end up
    adding a link to the same acpi_device twice:
    
    sysfs: cannot create duplicate filename '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/808622C1:00/OVTI2680:00/power_resources_D0/LNXPOWER:0a'
    CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.12-301.fc29.x86_64 #1
    Hardware name: Insyde CherryTrail/Type2 - Board Product Name, BIOS jumperx.T87.KFBNEEA02 04/13/2016
    Call Trace:
     dump_stack+0x5c/0x80
     sysfs_warn_dup.cold.3+0x17/0x2a
     sysfs_do_create_link_sd.isra.2+0xa9/0xb0
     sysfs_add_link_to_group+0x30/0x50
     acpi_power_expose_list+0x74/0xa0
     acpi_power_add_remove_device+0x50/0xa0
     acpi_add_single_object+0x26b/0x5f0
     acpi_bus_check_add+0xc4/0x250
     ...
    
    To address this issue, make acpi_extract_power_resources() check for
    duplicates and simply skip them when found.
    
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    [ rjw: Subject & changelog, comments ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c4da1134aa39b1cd9f77be5df349dc08f3aa569
Author: Michal Hocko <mhocko@suse.com>
Date:   Tue Jan 8 15:23:07 2019 -0800

    mm, memcg: fix reclaim deadlock with writeback
    
    commit 63f3655f950186752236bb88a22f8252c11ce394 upstream.
    
    Liu Bo has experienced a deadlock between memcg (legacy) reclaim and the
    ext4 writeback
    
      task1:
        wait_on_page_bit+0x82/0xa0
        shrink_page_list+0x907/0x960
        shrink_inactive_list+0x2c7/0x680
        shrink_node_memcg+0x404/0x830
        shrink_node+0xd8/0x300
        do_try_to_free_pages+0x10d/0x330
        try_to_free_mem_cgroup_pages+0xd5/0x1b0
        try_charge+0x14d/0x720
        memcg_kmem_charge_memcg+0x3c/0xa0
        memcg_kmem_charge+0x7e/0xd0
        __alloc_pages_nodemask+0x178/0x260
        alloc_pages_current+0x95/0x140
        pte_alloc_one+0x17/0x40
        __pte_alloc+0x1e/0x110
        alloc_set_pte+0x5fe/0xc20
        do_fault+0x103/0x970
        handle_mm_fault+0x61e/0xd10
        __do_page_fault+0x252/0x4d0
        do_page_fault+0x30/0x80
        page_fault+0x28/0x30
    
      task2:
        __lock_page+0x86/0xa0
        mpage_prepare_extent_to_map+0x2e7/0x310 [ext4]
        ext4_writepages+0x479/0xd60
        do_writepages+0x1e/0x30
        __writeback_single_inode+0x45/0x320
        writeback_sb_inodes+0x272/0x600
        __writeback_inodes_wb+0x92/0xc0
        wb_writeback+0x268/0x300
        wb_workfn+0xb4/0x390
        process_one_work+0x189/0x420
        worker_thread+0x4e/0x4b0
        kthread+0xe6/0x100
        ret_from_fork+0x41/0x50
    
    He adds
     "task1 is waiting for the PageWriteback bit of the page that task2 has
      collected in mpd->io_submit->io_bio, and tasks2 is waiting for the
      LOCKED bit the page which tasks1 has locked"
    
    More precisely task1 is handling a page fault and it has a page locked
    while it charges a new page table to a memcg.  That in turn hits a
    memory limit reclaim and the memcg reclaim for legacy controller is
    waiting on the writeback but that is never going to finish because the
    writeback itself is waiting for the page locked in the #PF path.  So
    this is essentially ABBA deadlock:
    
                                            lock_page(A)
                                            SetPageWriteback(A)
                                            unlock_page(A)
      lock_page(B)
                                            lock_page(B)
      pte_alloc_pne
        shrink_page_list
          wait_on_page_writeback(A)
                                            SetPageWriteback(B)
                                            unlock_page(B)
    
                                            # flush A, B to clear the writeback
    
    This accumulating of more pages to flush is used by several filesystems
    to generate a more optimal IO patterns.
    
    Waiting for the writeback in legacy memcg controller is a workaround for
    pre-mature OOM killer invocations because there is no dirty IO
    throttling available for the controller.  There is no easy way around
    that unfortunately.  Therefore fix this specific issue by pre-allocating
    the page table outside of the page lock.  We have that handy
    infrastructure for that already so simply reuse the fault-around pattern
    which already does this.
    
    There are probably other hidden __GFP_ACCOUNT | GFP_KERNEL allocations
    from under a fs page locked but they should be really rare.  I am not
    aware of a better solution unfortunately.
    
    [akpm@linux-foundation.org: fix mm/memory.c:__do_fault()]
    [akpm@linux-foundation.org: coding-style fixes]
    [mhocko@kernel.org: enhance comment, per Johannes]
      Link: http://lkml.kernel.org/r/20181214084948.GA5624@dhcp22.suse.cz
    Link: http://lkml.kernel.org/r/20181213092221.27270-1-mhocko@kernel.org
    Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages")
    Signed-off-by: Michal Hocko <mhocko@suse.com>
    Reported-by: Liu Bo <bo.liu@linux.alibaba.com>
    Debugged-by: Liu Bo <bo.liu@linux.alibaba.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Liu Bo <bo.liu@linux.alibaba.com>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Dave Chinner <david@fromorbit.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: Shakeel Butt <shakeelb@google.com>
    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 e973b3929a13c235a474532e640ddff426c5346e
Author: Jan Stancek <jstancek@redhat.com>
Date:   Tue Jan 8 15:23:28 2019 -0800

    mm: page_mapped: don't assume compound page is huge or THP
    
    commit 8ab88c7169b7fba98812ead6524b9d05bc76cf00 upstream.
    
    LTP proc01 testcase has been observed to rarely trigger crashes
    on arm64:
        page_mapped+0x78/0xb4
        stable_page_flags+0x27c/0x338
        kpageflags_read+0xfc/0x164
        proc_reg_read+0x7c/0xb8
        __vfs_read+0x58/0x178
        vfs_read+0x90/0x14c
        SyS_read+0x60/0xc0
    
    The issue is that page_mapped() assumes that if compound page is not
    huge, then it must be THP.  But if this is 'normal' compound page
    (COMPOUND_PAGE_DTOR), then following loop can keep running (for
    HPAGE_PMD_NR iterations) until it tries to read from memory that isn't
    mapped and triggers a panic:
    
            for (i = 0; i < hpage_nr_pages(page); i++) {
                    if (atomic_read(&page[i]._mapcount) >= 0)
                            return true;
            }
    
    I could replicate this on x86 (v4.20-rc4-98-g60b548237fed) only
    with a custom kernel module [1] which:
     - allocates compound page (PAGEC) of order 1
     - allocates 2 normal pages (COPY), which are initialized to 0xff (to
       satisfy _mapcount >= 0)
     - 2 PAGEC page structs are copied to address of first COPY page
     - second page of COPY is marked as not present
     - call to page_mapped(COPY) now triggers fault on access to 2nd COPY
       page at offset 0x30 (_mapcount)
    
    [1] https://github.com/jstancek/reproducers/blob/master/kernel/page_mapped_crash/repro.c
    
    Fix the loop to iterate for "1 << compound_order" pages.
    
    Kirrill said "IIRC, sound subsystem can producuce custom mapped compound
    pages".
    
    Link: http://lkml.kernel.org/r/c440d69879e34209feba21e12d236d06bc0a25db.1543577156.git.jstancek@redhat.com
    Fixes: e1534ae95004 ("mm: differentiate page_mapped() from page_mapcount() for compound pages")
    Signed-off-by: Jan Stancek <jstancek@redhat.com>
    Debugged-by: Laszlo Ersek <lersek@redhat.com>
    Suggested-by: "Kirill A. Shutemov" <kirill@shutemov.name>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
    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 90bcbcfb745059e555943090ff3f2f615d360e98
Author: Christoph Lameter <cl@linux.com>
Date:   Tue Jan 8 15:23:00 2019 -0800

    slab: alien caches must not be initialized if the allocation of the alien cache failed
    
    commit 09c2e76ed734a1d36470d257a778aaba28e86531 upstream.
    
    Callers of __alloc_alien() check for NULL.  We must do the same check in
    __alloc_alien_cache to avoid NULL pointer dereferences on allocation
    failures.
    
    Link: http://lkml.kernel.org/r/010001680f42f192-82b4e12e-1565-4ee0-ae1f-1e98974906aa-000000@email.amazonses.com
    Fixes: 49dfc304ba241 ("slab: use the lock on alien_cache, instead of the lock on array_cache")
    Fixes: c8522a3a5832b ("Slab: introduce alloc_alien")
    Signed-off-by: Christoph Lameter <cl@linux.com>
    Reported-by: syzbot+d6ed4ec679652b4fd4e4@syzkaller.appspotmail.com
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    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 ec197f07d3eaee6d78228760bf6ee3ca40cff2b2
Author: Jack Stocker <jackstocker.93@gmail.com>
Date:   Thu Jan 3 21:56:53 2019 +0000

    USB: Add USB_QUIRK_DELAY_CTRL_MSG quirk for Corsair K70 RGB
    
    commit 3483254b89438e60f719937376c5e0ce2bc46761 upstream.
    
    To match the Corsair Strafe RGB, the Corsair K70 RGB also requires
    USB_QUIRK_DELAY_CTRL_MSG to completely resolve boot connection issues
    discussed here: https://github.com/ckb-next/ckb-next/issues/42.
    Otherwise roughly 1 in 10 boots the keyboard will fail to be detected.
    
    Patch that applied delay control quirk for Corsair Strafe RGB:
    cb88a0588717 ("usb: quirks: add control message delay for 1b1c:1b20")
    
    Previous K70 RGB patch to add delay-init quirk:
    7a1646d92257 ("Add delay-init quirk for Corsair K70 RGB keyboards")
    
    Signed-off-by: Jack Stocker <jackstocker.93@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8497e3b0b7b165d728941eb652bef6eb7684e4a
Author: Icenowy Zheng <icenowy@aosc.io>
Date:   Thu Jan 3 11:26:18 2019 +0800

    USB: storage: add quirk for SMI SM3350
    
    commit 0a99cc4b8ee83885ab9f097a3737d1ab28455ac0 upstream.
    
    The SMI SM3350 USB-UFS bridge controller cannot handle long sense request
    correctly and will make the chip refuse to do read/write when requested
    long sense.
    
    Add a bad sense quirk for it.
    
    Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e43d3143ad116b0559bd8fc0f2948d2e60404343
Author: Icenowy Zheng <icenowy@aosc.io>
Date:   Thu Jan 3 11:26:17 2019 +0800

    USB: storage: don't insert sane sense for SPC3+ when bad sense specified
    
    commit c5603d2fdb424849360fe7e3f8c1befc97571b8c upstream.
    
    Currently the code will set US_FL_SANE_SENSE flag unconditionally if
    device claims SPC3+, however we should allow US_FL_BAD_SENSE flag to
    prevent this behavior, because SMI SM3350 UFS-USB bridge controller,
    which claims SPC4, will show strange behavior with 96-byte sense
    (put the chip into a wrong state that cannot read/write anything).
    
    Check the presence of US_FL_BAD_SENSE when assuming US_FL_SANE_SENSE on
    SPC4+ devices.
    
    Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d42666bd9f35a91ef870344d27b86f5bb1bfe220
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Fri Dec 28 16:15:41 2018 +0100

    usb: cdc-acm: send ZLP for Telit 3G Intel based modems
    
    commit 34aabf918717dd14e05051896aaecd3b16b53d95 upstream.
    
    Telit 3G Intel based modems require zero packet to be sent if
    out data size is equal to the endpoint max packet size.
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c467ac09db61069e409d1249c23a9deff747410
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date:   Tue Jan 8 18:30:57 2019 +0000

    cifs: Fix potential OOB access of lock element array
    
    commit b9a74cde94957d82003fb9f7ab4777938ca851cd upstream.
    
    If maxBuf is small but non-zero, it could result in a zero sized lock
    element array which we would then try and access OOB.
    
    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4092ad400ea6ef5c31871ccefdaf809ef8dd32cc
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date:   Thu Jan 10 11:27:28 2019 -0800

    CIFS: Do not hide EINTR after sending network packets
    
    commit ee13919c2e8d1f904e035ad4b4239029a8994131 upstream.
    
    Currently we hide EINTR code returned from sock_sendmsg()
    and return 0 instead. This makes a caller think that we
    successfully completed the network operation which is not
    true. Fix this by properly returning EINTR to callers.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit edc8099b54ec5c465987b4f6bcd44a0130ed2ffd
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date:   Wed Dec 19 22:49:09 2018 +0000

    CIFS: Fix adjustment of credits for MTU requests
    
    commit b983f7e92348d7e7d091db1b78b7915e9dd3d63a upstream.
    
    Currently for MTU requests we allocate maximum possible credits
    in advance and then adjust them according to the request size.
    While we were adjusting the number of credits belonging to the
    server, we were skipping adjustment of credits belonging to the
    request. This patch fixes it by setting request credits to
    CreditCharge field value of SMB2 packet header.
    
    Also ask 1 credit more for async read and write operations to
    increase parallelism and match the behavior of other operations.
    
    Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1008331ce7a1033d70ef3e6559eaf5e072b8218
Author: Kailang Yang <kailang@realtek.com>
Date:   Wed Jan 9 17:05:24 2019 +0800

    ALSA: hda/realtek - Disable headset Mic VREF for headset mode of ALC225
    
    commit d1dd42110d2727e81b9265841a62bc84c454c3a2 upstream.
    
    Disable Headset Mic VREF for headset mode of ALC225.
    This will be controlled by coef bits of headset mode functions.
    
    [ Fixed a compile warning and code simplification -- tiwai ]
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd5a27c87820dd613518243c6422d1ea59b4759c
Author: Kailang Yang <kailang@realtek.com>
Date:   Wed Jan 9 16:23:37 2019 +0800

    ALSA: hda/realtek - Add unplug function into unplug state of Headset Mode for ALC225
    
    commit 4d4b0c52bde470c379f5d168d5c139ad866cb808 upstream.
    
    Forgot to add unplug function to unplug state of headset mode
    for ALC225.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 711fd1f564c3e8bdc4e344055abe06f2f6c6b8f7
Author: Kailang Yang <kailang@realtek.com>
Date:   Thu Jan 3 15:53:39 2019 +0800

    ALSA: hda/realtek - Support Dell headset mode for New AIO platform
    
    commit c2a7c55a04065c3b0c32d23b099db7ea1dbf6250 upstream.
    
    Dell has new platform for ALC274.
    This will support to enable headset mode.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64ac5483a1b187f4e3fa47c65ba53546f9089bd6
Author: WANG Chao <chao.wang@ucloud.cn>
Date:   Tue Dec 11 00:37:25 2018 +0800

    x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINE
    
    commit e4f358916d528d479c3c12bd2fd03f2d5a576380 upstream.
    
    Commit
    
      4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support")
    
    replaced the RETPOLINE define with CONFIG_RETPOLINE checks. Remove the
    remaining pieces.
    
     [ bp: Massage commit message. ]
    
    Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support")
    Signed-off-by: WANG Chao <chao.wang@ucloud.cn>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: David Woodhouse <dwmw@amazon.co.uk>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Jessica Yu <jeyu@kernel.org>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
    Cc: Michal Marek <michal.lkml@markovi.net>
    Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Vasily Gorbik <gor@linux.ibm.com>
    Cc: linux-kbuild@vger.kernel.org
    Cc: srinivas.eeda@oracle.com
    Cc: stable <stable@vger.kernel.org>
    Cc: x86-ml <x86@kernel.org>
    Link: https://lkml.kernel.org/r/20181210163725.95977-1-chao.wang@ucloud.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4124a4cff344abbf8187775eb643d9827830e715
Author: Rik van Riel <riel@redhat.com>
Date:   Tue Nov 14 16:54:23 2017 -0500

    x86,kvm: move qemu/guest FPU switching out to vcpu_run
    
    commit f775b13eedee2f7f3c6fdd4e90fb79090ce5d339 upstream.
    
    Currently, every time a VCPU is scheduled out, the host kernel will
    first save the guest FPU/xstate context, then load the qemu userspace
    FPU context, only to then immediately save the qemu userspace FPU
    context back to memory. When scheduling in a VCPU, the same extraneous
    FPU loads and saves are done.
    
    This could be avoided by moving from a model where the guest FPU is
    loaded and stored with preemption disabled, to a model where the
    qemu userspace FPU is swapped out for the guest FPU context for
    the duration of the KVM_RUN ioctl.
    
    This is done under the VCPU mutex, which is also taken when other
    tasks inspect the VCPU FPU context, so the code should already be
    safe for this change. That should come as no surprise, given that
    s390 already has this optimization.
    
    This can fix a bug where KVM calls get_user_pages while owning the
    FPU, and the file system ends up requesting the FPU again:
    
        [258270.527947]  __warn+0xcb/0xf0
        [258270.527948]  warn_slowpath_null+0x1d/0x20
        [258270.527951]  kernel_fpu_disable+0x3f/0x50
        [258270.527953]  __kernel_fpu_begin+0x49/0x100
        [258270.527955]  kernel_fpu_begin+0xe/0x10
        [258270.527958]  crc32c_pcl_intel_update+0x84/0xb0
        [258270.527961]  crypto_shash_update+0x3f/0x110
        [258270.527968]  crc32c+0x63/0x8a [libcrc32c]
        [258270.527975]  dm_bm_checksum+0x1b/0x20 [dm_persistent_data]
        [258270.527978]  node_prepare_for_write+0x44/0x70 [dm_persistent_data]
        [258270.527985]  dm_block_manager_write_callback+0x41/0x50 [dm_persistent_data]
        [258270.527988]  submit_io+0x170/0x1b0 [dm_bufio]
        [258270.527992]  __write_dirty_buffer+0x89/0x90 [dm_bufio]
        [258270.527994]  __make_buffer_clean+0x4f/0x80 [dm_bufio]
        [258270.527996]  __try_evict_buffer+0x42/0x60 [dm_bufio]
        [258270.527998]  dm_bufio_shrink_scan+0xc0/0x130 [dm_bufio]
        [258270.528002]  shrink_slab.part.40+0x1f5/0x420
        [258270.528004]  shrink_node+0x22c/0x320
        [258270.528006]  do_try_to_free_pages+0xf5/0x330
        [258270.528008]  try_to_free_pages+0xe9/0x190
        [258270.528009]  __alloc_pages_slowpath+0x40f/0xba0
        [258270.528011]  __alloc_pages_nodemask+0x209/0x260
        [258270.528014]  alloc_pages_vma+0x1f1/0x250
        [258270.528017]  do_huge_pmd_anonymous_page+0x123/0x660
        [258270.528021]  handle_mm_fault+0xfd3/0x1330
        [258270.528025]  __get_user_pages+0x113/0x640
        [258270.528027]  get_user_pages+0x4f/0x60
        [258270.528063]  __gfn_to_pfn_memslot+0x120/0x3f0 [kvm]
        [258270.528108]  try_async_pf+0x66/0x230 [kvm]
        [258270.528135]  tdp_page_fault+0x130/0x280 [kvm]
        [258270.528149]  kvm_mmu_page_fault+0x60/0x120 [kvm]
        [258270.528158]  handle_ept_violation+0x91/0x170 [kvm_intel]
        [258270.528162]  vmx_handle_exit+0x1ca/0x1400 [kvm_intel]
    
    No performance changes were detected in quick ping-pong tests on
    my 4 socket system, which is expected since an FPU+xstate load is
    on the order of 0.1us, while ping-ponging between CPUs is on the
    order of 20us, and somewhat noisy.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Rik van Riel <riel@redhat.com>
    Suggested-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [Fixed a bug where reset_vcpu called put_fpu without preceding load_fpu,
     which happened inside from KVM_CREATE_VCPU ioctl. - Radim]
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>