commit b8343316098dd191a6d643c5eb6ab7024622af9e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Mar 13 14:05:02 2019 -0700

    Linux 4.9.163

commit 3596b45859416cc91e22ac5ec8963029c49af8b0
Author: Peter Zijlstra (Intel) <peterz@infradead.org>
Date:   Tue Mar 5 22:23:17 2019 +0100

    x86: Add TSX Force Abort CPUID/MSR
    
    commit 52f64909409c17adf54fcf5f9751e0544ca3a6b4 upstream
    
    Skylake systems will receive a microcode update to address a TSX
    errata. This microcode will (by default) clobber PMC3 when TSX
    instructions are (speculatively or not) executed.
    
    It also provides an MSR to cause all TSX transaction to abort and
    preserve PMC3.
    
    Add the CPUID enumeration and MSR definition.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c34730d7e64ff84657eadeb820f424139dc50929
Author: Peter Zijlstra (Intel) <peterz@infradead.org>
Date:   Tue Mar 5 22:23:16 2019 +0100

    perf/x86/intel: Generalize dynamic constraint creation
    
    commit 11f8b2d65ca9029591c8df26bb6bd063c312b7fe upstream
    
    Such that we can re-use it.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ac343a528910b2e457cf71b6a6bcb09cf3e0b10
Author: Peter Zijlstra (Intel) <peterz@infradead.org>
Date:   Tue Mar 5 22:23:15 2019 +0100

    perf/x86/intel: Make cpuc allocations consistent
    
    commit d01b1f96a82e5dd7841a1d39db3abfdaf95f70ab upstream
    
    The cpuc data structure allocation is different between fake and real
    cpuc's; use the same code to init/free both.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd25a761bfb019b7a8924d726dfa82c0f9b619a4
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Sat Feb 11 22:14:56 2017 +0200

    ARM: dts: exynos: Do not ignore real-world fuse values for thermal zone 0 on Exynos5420
    
    commit 28928a3ce142b2e4e5a7a0f067cefb41a3d2c3f9 upstream.
    
    In Odroid XU3 Lite board, the temperature levels reported for thermal
    zone 0 were weird. In warm room:
            /sys/class/thermal/thermal_zone0/temp:32000
            /sys/class/thermal/thermal_zone1/temp:51000
            /sys/class/thermal/thermal_zone2/temp:55000
            /sys/class/thermal/thermal_zone3/temp:54000
            /sys/class/thermal/thermal_zone4/temp:51000
    
    Sometimes after booting the value was even equal to ambient temperature
    which is highly unlikely to be a real temperature of sensor in SoC.
    
    The thermal sensor's calibration (trimming) is based on fused values.
    In case of the board above, the fused values are: 35, 52, 43, 58 and 43
    (corresponding to each TMU device).  However driver defined a minimum value
    for fused data as 40 and for smaller values it was using a hard-coded 55
    instead.  This lead to mapping data from sensor to wrong temperatures
    for thermal zone 0.
    
    Various vendor 3.10 trees (Hardkernel's based on Samsung LSI, Artik 10)
    do not impose any limits on fused values.  Since we do not have any
    knowledge about these limits, use 0 as a minimum accepted fused value.
    This should essentially allow accepting any reasonable fused value thus
    behaving like vendor driver.
    
    The exynos5420-tmu-sensor-conf.dtsi is copied directly from existing
    exynos4412 with one change - the samsung,tmu_min_efuse_value.
    
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Acked-by: Eduardo Valentin <edubezval@gmail.com>
    Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
    Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
    Reviewed-by: Anand Moon <linux.amoon@gmail.com>
    Tested-by: Anand Moon <linux.amoon@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88bc59cff5226a25dc20017eee2cb470b364f97a
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date:   Fri Jul 13 11:12:22 2018 +0100

    ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+
    
    [ Upstream commit afc9f65e01cd114cb2cedf544d22239116ce0cc6 ]
    
    When building the kernel as Thumb-2 with binutils 2.29 or newer, if the
    assembler has seen the .type directive (via ENDPROC()) for a symbol, it
    automatically handles the setting of the lowest bit when the symbol is
    used with ADR.  The badr macro on the other hand handles this lowest bit
    manually.  This leads to a jump to a wrong address in the wrong state
    in the syscall return path:
    
     Internal error: Oops - undefined instruction: 0 [#2] SMP THUMB2
     Modules linked in:
     CPU: 0 PID: 652 Comm: modprobe Tainted: G      D           4.18.0-rc3+ #8
     PC is at ret_fast_syscall+0x4/0x62
     LR is at sys_brk+0x109/0x128
     pc : [<80101004>]    lr : [<801c8a35>]    psr: 60000013
     Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
     Control: 50c5387d  Table: 9e82006a  DAC: 00000051
     Process modprobe (pid: 652, stack limit = 0x(ptrval))
    
     80101000 <ret_fast_syscall>:
     80101000:       b672            cpsid   i
     80101002:       f8d9 2008       ldr.w   r2, [r9, #8]
     80101006:       f1b2 4ffe       cmp.w   r2, #2130706432 ; 0x7f000000
    
     80101184 <local_restart>:
     80101184:       f8d9 a000       ldr.w   sl, [r9]
     80101188:       e92d 0030       stmdb   sp!, {r4, r5}
     8010118c:       f01a 0ff0       tst.w   sl, #240        ; 0xf0
     80101190:       d117            bne.n   801011c2 <__sys_trace>
     80101192:       46ba            mov     sl, r7
     80101194:       f5ba 7fc8       cmp.w   sl, #400        ; 0x190
     80101198:       bf28            it      cs
     8010119a:       f04f 0a00       movcs.w sl, #0
     8010119e:       f3af 8014       nop.w   {20}
     801011a2:       f2af 1ea2       subw    lr, pc, #418    ; 0x1a2
    
    To fix this, add a new symbol name which doesn't have ENDPROC used on it
    and use that with badr.  We can't remove the badr usage since that would
    would cause breakage with older binutils.
    
    Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 660e1bf847546a36b09c210a1f40f988800a2894
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Thu Jan 24 13:06:58 2019 +0100

    drm: disable uncached DMA optimization for ARM and arm64
    
    [ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ]
    
    The DRM driver stack is designed to work with cache coherent devices
    only, but permits an optimization to be enabled in some cases, where
    for some buffers, both the CPU and the GPU use uncached mappings,
    removing the need for DMA snooping and allocation in the CPU caches.
    
    The use of uncached GPU mappings relies on the correct implementation
    of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU
    will use cached mappings nonetheless. On x86 platforms, this does not
    seem to matter, as uncached CPU mappings will snoop the caches in any
    case. However, on ARM and arm64, enabling this optimization on a
    platform where NoSnoop is ignored results in loss of coherency, which
    breaks correct operation of the device. Since we have no way of
    detecting whether NoSnoop works or not, just disable this
    optimization entirely for ARM and arm64.
    
    Cc: Christian Koenig <christian.koenig@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: David Zhou <David1.Zhou@amd.com>
    Cc: Huang Rui <ray.huang@amd.com>
    Cc: Junwei Zhang <Jerry.Zhang@amd.com>
    Cc: Michel Daenzer <michel.daenzer@amd.com>
    Cc: David Airlie <airlied@linux.ie>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: Maxime Ripard <maxime.ripard@bootlin.com>
    Cc: Sean Paul <sean@poorly.run>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: amd-gfx list <amd-gfx@lists.freedesktop.org>
    Cc: dri-devel <dri-devel@lists.freedesktop.org>
    Reported-by: Carsten Haitzler <Carsten.Haitzler@arm.com>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Link: https://patchwork.kernel.org/patch/10778815/
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a844f7910c4e81a33a679ceb9a7429f0df8a84e9
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Fri Feb 15 11:36:50 2019 +0100

    ARM: dts: exynos: Add minimal clkout parameters to Exynos3250 PMU
    
    commit a66352e005488ecb4b534ba1af58a9f671eba9b8 upstream.
    
    Add minimal parameters needed by the Exynos CLKOUT driver to Exynos3250
    PMU node. This fixes the following warning on boot:
    
    exynos_clkout_init: failed to register clkout clock
    
    Fixes: d19bb397e19e ("ARM: dts: exynos: Update PMU node with CLKOUT related data")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf0488350d0484192a06609bd2148d8835ad56ac
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Thu Jan 24 13:22:57 2019 +0100

    ARM: dts: exynos: Fix pinctrl definition for eMMC RTSN line on Odroid X2/U3
    
    commit ec33745bccc8f336957c751f4153421cc9ef5a54 upstream.
    
    Commit 225da7e65a03 ("ARM: dts: add eMMC reset line for
    exynos4412-odroid-common") added MMC power sequence for eMMC card of
    Odroid X2/U3. It reused generic sd1_cd pin control configuration node
    and only disabled pull-up. However that time the pinctrl configuration
    was not applied during MMC power sequence driver initialization. This
    has been changed later by commit d97a1e5d7cd2 ("mmc: pwrseq: convert to
    proper platform device").
    
    It turned out then, that the provided pinctrl configuration is not
    correct, because the eMMC_RTSN line is being re-configured as 'special
    function/card detect function for mmc1 controller' not the simple
    'output', thus the power sequence driver doesn't really set the pin
    value. This in effect broke the reboot of Odroid X2/U3 boards. Fix this
    by providing separate node with eMMC_RTSN pin configuration.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: Markus Reichl <m.reichl@fivetechno.de>
    Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
    Fixes: 225da7e65a03 ("ARM: dts: add eMMC reset line for exynos4412-odroid-common")
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce813552312bfbb28bae32064d65afff3c0e7c82
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Mar 22 11:35:57 2017 +0100

    futex,rt_mutex: Restructure rt_mutex_finish_proxy_lock()
    
    commit 38d589f2fd08f1296aea3ce62bebd185125c6d81 upstream.
    
    With the ultimate goal of keeping rt_mutex wait_list and futex_q waiters
    consistent it's necessary to split 'rt_mutex_futex_lock()' into finer
    parts, such that only the actual blocking can be done without hb->lock
    held.
    
    Split split_mutex_finish_proxy_lock() into two parts, one that does the
    blocking and one that does remove_waiter() when the lock acquire failed.
    
    When the rtmutex was acquired successfully the waiter can be removed in the
    acquisiton path safely, since there is no concurrency on the lock owner.
    
    This means that, except for futex_lock_pi(), all wait_list modifications
    are done with both hb->lock and wait_lock held.
    
    [bigeasy@linutronix.de: fix for futex_requeue_pi_signal_restart]
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: juri.lelli@arm.com
    Cc: bigeasy@linutronix.de
    Cc: xlpang@redhat.com
    Cc: rostedt@goodmis.org
    Cc: mathieu.desnoyers@efficios.com
    Cc: jdesfossez@efficios.com
    Cc: dvhart@infradead.org
    Cc: bristot@redhat.com
    Link: http://lkml.kernel.org/r/20170322104152.001659630@infradead.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Zubin Mithra <zsm@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1dd5254782f393f0dea5184c7aee5c5801bdc1dc
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Fri Feb 15 15:42:42 2019 -0600

    scsi: aacraid: Fix missing break in switch statement
    
    commit 5e420fe635813e5746b296cfc8fff4853ae205a2 upstream.
    
    Add missing break statement and fix identation issue.
    
    This bug was found thanks to the ongoing efforts to enable
    -Wimplicit-fallthrough.
    
    Fixes: 9cb62fa24e0d ("aacraid: Log firmware AIF messages")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6263e82643db9ba45ce66642401928a0a175a399
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Mon Feb 11 12:43:23 2019 -0600

    iscsi_ibft: Fix missing break in switch statement
    
    commit df997abeebadaa4824271009e2d2b526a70a11cb upstream.
    
    Add missing break statement in order to prevent the code from falling
    through to case ISCSI_BOOT_TGT_NAME, which is unnecessary.
    
    This bug was found thanks to the ongoing efforts to enable
    -Wimplicit-fallthrough.
    
    Fixes: b33a84a38477 ("ibft: convert iscsi_ibft module to iscsi boot lib")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b5ed2ceeb5c7713b3117a35620921fedacd669e
Author: Vincent Batts <vbatts@hashbangbash.com>
Date:   Sat Mar 9 15:48:04 2019 -0800

    Input: elan_i2c - add id for touchpad found in Lenovo s21e-20
    
    commit e154ab69321ce2c54f19863d75c77b4e2dc9d365 upstream.
    
    Lenovo s21e-20 uses ELAN0601 in its ACPI tables for the Elan touchpad.
    
    Signed-off-by: Vincent Batts <vbatts@hashbangbash.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 1a2403a279bb4690156d4a62c13f9aacb46050e9
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Sat Mar 9 15:32:13 2019 -0800

    Input: wacom_serial4 - add support for Wacom ArtPad II tablet
    
    commit 44fc95e218a09d7966a9d448941fdb003f6bb69f upstream.
    
    Tablet initially begins communicating at 9600 baud, so this command
    should be used to connect to the device:
    
        $ inputattach --daemon --baud 9600 --wacom_iv /dev/ttyS0
    
    https://github.com/linuxwacom/xf86-input-wacom/issues/40
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.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 579acdaef9a0648bab740d0418228207c9eeeb70
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Mon Jan 21 22:49:37 2019 +0900

    fs: ratelimit __find_get_block_slow() failure message.
    
    [ Upstream commit 43636c804df0126da669c261fc820fb22f62bfc2 ]
    
    When something let __find_get_block_slow() hit all_mapped path, it calls
    printk() for 100+ times per a second. But there is no need to print same
    message with such high frequency; it is just asking for stall warning, or
    at least bloating log files.
    
      [  399.866302][T15342] __find_get_block_slow() failed. block=1, b_blocknr=8
      [  399.873324][T15342] b_state=0x00000029, b_size=512
      [  399.878403][T15342] device loop0 blocksize: 4096
      [  399.883296][T15342] __find_get_block_slow() failed. block=1, b_blocknr=8
      [  399.890400][T15342] b_state=0x00000029, b_size=512
      [  399.895595][T15342] device loop0 blocksize: 4096
      [  399.900556][T15342] __find_get_block_slow() failed. block=1, b_blocknr=8
      [  399.907471][T15342] b_state=0x00000029, b_size=512
      [  399.912506][T15342] device loop0 blocksize: 4096
    
    This patch reduces frequency to up to once per a second, in addition to
    concatenating three lines into one.
    
      [  399.866302][T15342] __find_get_block_slow() failed. block=1, b_blocknr=8, b_state=0x00000029, b_size=512, device loop0 blocksize: 4096
    
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a189410b3f76b8f00c1da296836928904266b0f1
Author: Jun-Ru Chang <jrjang@realtek.com>
Date:   Tue Jan 29 11:56:07 2019 +0800

    MIPS: Remove function size check in get_frame_info()
    
    [ Upstream commit 2b424cfc69728224fcb5fad138ea7260728e0901 ]
    
    Patch (b6c7a324df37b "MIPS: Fix get_frame_info() handling of
    microMIPS function size.") introduces additional function size
    check for microMIPS by only checking insn between ip and ip + func_size.
    However, func_size in get_frame_info() is always 0 if KALLSYMS is not
    enabled. This causes get_frame_info() to return immediately without
    calculating correct frame_size, which in turn causes "Can't analyze
    schedule() prologue" warning messages at boot time.
    
    This patch removes func_size check, and let the frame_size check run
    up to 128 insns for both MIPS and microMIPS.
    
    Signed-off-by: Jun-Ru Chang <jrjang@realtek.com>
    Signed-off-by: Tony Wu <tonywu@realtek.com>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Fixes: b6c7a324df37b ("MIPS: Fix get_frame_info() handling of microMIPS function size.")
    Cc: <ralf@linux-mips.org>
    Cc: <jhogan@kernel.org>
    Cc: <macro@mips.com>
    Cc: <yamada.masahiro@socionext.com>
    Cc: <peterz@infradead.org>
    Cc: <mingo@kernel.org>
    Cc: <linux-mips@vger.kernel.org>
    Cc: <linux-kernel@vger.kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ce42bb1d2bef896f3f22080807df5ba0bfb064a6
Author: Jiri Olsa <jolsa@redhat.com>
Date:   Mon Jan 28 14:35:26 2019 +0100

    perf symbols: Filter out hidden symbols from labels
    
    [ Upstream commit 59a17706915fe5ea6f711e1f92d4fb706bce07fe ]
    
    When perf is built with the annobin plugin (RHEL8 build) extra symbols
    are added to its binary:
    
      # nm perf | grep annobin | head -10
      0000000000241100 t .annobin_annotate.c
      0000000000326490 t .annobin_annotate.c
      0000000000249255 t .annobin_annotate.c_end
      00000000003283a8 t .annobin_annotate.c_end
      00000000001bce18 t .annobin_annotate.c_end.hot
      00000000001bce18 t .annobin_annotate.c_end.hot
      00000000001bc3e2 t .annobin_annotate.c_end.unlikely
      00000000001bc400 t .annobin_annotate.c_end.unlikely
      00000000001bce18 t .annobin_annotate.c.hot
      00000000001bce18 t .annobin_annotate.c.hot
      ...
    
    Those symbols have no use for report or annotation and should be
    skipped.  Moreover they interfere with the DWARF unwind test on the PPC
    arch, where they are mixed with checked symbols and then the test fails:
    
      # perf test dwarf -v
      59: Test dwarf unwind                                     :
      --- start ---
      test child forked, pid 8515
      unwind: .annobin_dwarf_unwind.c:ip = 0x10dba40dc (0x2740dc)
      ...
      got: .annobin_dwarf_unwind.c 0x10dba40dc, expecting test__arch_unwind_sample
      unwind: failed with 'no error'
    
    The annobin symbols are defined as NOTYPE/LOCAL/HIDDEN:
    
      # readelf -s ./perf | grep annobin | head -1
        40: 00000000001bce4f     0 NOTYPE  LOCAL  HIDDEN    13 .annobin_init.c
    
    They can still pass the check for the label symbol. Adding check for
    HIDDEN and INTERNAL (as suggested by Nick below) visibility and filter
    out such symbols.
    
    >   Just to be awkward, if you are going to ignore STV_HIDDEN
    >   symbols then you should probably also ignore STV_INTERNAL ones
    >   as well...  Annobin does not generate them, but you never know,
    >   one day some other tool might create some.
    
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Michael Petlan <mpetlan@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Nick Clifton <nickc@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/20190128133526.GD15461@krava
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78335ed0018587a047b66b9ff85b4e1e75d68bdc
Author: Julian Wiedmann <jwi@linux.ibm.com>
Date:   Mon Feb 4 17:40:07 2019 +0100

    s390/qeth: fix use-after-free in error path
    
    [ Upstream commit afa0c5904ba16d59b0454f7ee4c807dae350f432 ]
    
    The error path in qeth_alloc_qdio_buffers() that takes care of
    cleaning up the Output Queues is buggy. It first frees the queue, but
    then calls qeth_clear_outq_buffers() with that very queue struct.
    
    Make the call to qeth_clear_outq_buffers() part of the free action
    (in the correct order), and while at it fix the naming of the helper.
    
    Fixes: 0da9581ddb0f ("qeth: exploit asynchronous delivery of storage blocks")
    Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
    Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92044928a9029807aafdd2c5b7e4748e0cca3643
Author: Martynas Pumputis <martynas@weave.works>
Date:   Tue Jan 29 15:51:42 2019 +0100

    netfilter: nf_nat: skip nat clash resolution for same-origin entries
    
    [ Upstream commit 4e35c1cb9460240e983a01745b5f29fe3a4d8e39 ]
    
    It is possible that two concurrent packets originating from the same
    socket of a connection-less protocol (e.g. UDP) can end up having
    different IP_CT_DIR_REPLY tuples which results in one of the packets
    being dropped.
    
    To illustrate this, consider the following simplified scenario:
    
    1. Packet A and B are sent at the same time from two different threads
       by same UDP socket.  No matching conntrack entry exists yet.
       Both packets cause allocation of a new conntrack entry.
    2. get_unique_tuple gets called for A.  No clashing entry found.
       conntrack entry for A is added to main conntrack table.
    3. get_unique_tuple is called for B and will find that the reply
       tuple of B is already taken by A.
       It will allocate a new UDP source port for B to resolve the clash.
    4. conntrack entry for B cannot be added to main conntrack table
       because its ORIGINAL direction is clashing with A and the REPLY
       directions of A and B are not the same anymore due to UDP source
       port reallocation done in step 3.
    
    This patch modifies nf_conntrack_tuple_taken so it doesn't consider
    colliding reply tuples if the IP_CT_DIR_ORIGINAL tuples are equal.
    
    [ Florian: simplify patch to not use .allow_clash setting
      and always ignore identical flows ]
    
    Signed-off-by: Martynas Pumputis <martynas@weave.works>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9b060e08ef7d0ea6291145d8e75b25a087805250
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Jan 29 15:16:23 2019 +0100

    selftests: netfilter: add simple masq/redirect test cases
    
    [ Upstream commit 98bfc3414bda335dbd7fec58bde6266f991801d7 ]
    
    Check basic nat/redirect/masquerade for ipv4 and ipv6.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78dbfc5d258b45fae159f59c892012b75359dbb2
Author: Naresh Kamboju <naresh.kamboju@linaro.org>
Date:   Tue Jan 29 06:28:35 2019 +0000

    selftests: netfilter: fix config fragment CONFIG_NF_TABLES_INET
    
    [ Upstream commit 952b72f89ae23b316da8c1021b18d0c388ad6cc4 ]
    
    In selftests the config fragment for netfilter was added as
    NF_TABLES_INET=y and this patch correct it as CONFIG_NF_TABLES_INET=y
    
    Signed-off-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad3039362bb0aa8fb877e2122d34125ea3716b21
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Wed Jan 30 21:48:44 2019 +0200

    dmaengine: dmatest: Abort test in case of mapping error
    
    [ Upstream commit 6454368a804c4955ccd116236037536f81e5b1f1 ]
    
    In case of mapping error the DMA addresses are invalid and continuing
    will screw system memory or potentially something else.
    
    [  222.480310] dmatest: dma0chan7-copy0: summary 1 tests, 3 failures 6 iops 349 KB/s (0)
    ...
    [  240.912725] check: Corrupted low memory at 00000000c7c75ac9 (2940 phys) = 5656000000000000
    [  240.921998] check: Corrupted low memory at 000000005715a1cd (2948 phys) = 279f2aca5595ab2b
    [  240.931280] check: Corrupted low memory at 000000002f4024c0 (2950 phys) = 5e5624f349e793cf
    ...
    
    Abort any test if mapping failed.
    
    Fixes: 4076e755dbec ("dmatest: convert to dmaengine_unmap_data")
    Cc: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4c870d3c4b3464503a713770bbd6fefde1f49e26
Author: Stefano Garzarella <sgarzare@redhat.com>
Date:   Fri Feb 1 12:42:07 2019 +0100

    vsock/virtio: reset connected sockets on device removal
    
    [ Upstream commit 85965487abc540368393a15491e6e7fcd230039d ]
    
    When the virtio transport device disappear, we should reset all
    connected sockets in order to inform the users.
    
    Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5c9e72bfd09a53ea1b5b71fc5b84e09bacc9a975
Author: Stefano Garzarella <sgarzare@redhat.com>
Date:   Fri Feb 1 12:42:06 2019 +0100

    vsock/virtio: fix kernel panic after device hot-unplug
    
    [ Upstream commit 22b5c0b63f32568e130fa2df4ba23efce3eb495b ]
    
    virtio_vsock_remove() invokes the vsock_core_exit() also if there
    are opened sockets for the AF_VSOCK protocol family. In this way
    the vsock "transport" pointer is set to NULL, triggering the
    kernel panic at the first socket activity.
    
    This patch move the vsock_core_init()/vsock_core_exit() in the
    virtio_vsock respectively in module_init and module_exit functions,
    that cannot be invoked until there are open sockets.
    
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1609699
    Reported-by: Yan Fu <yafu@redhat.com>
    Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
    Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b498cfefc30a7f3f223c927c082cd3bd96aeced2
Author: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Date:   Wed Jan 23 16:33:47 2019 +0000

    dmaengine: at_xdmac: Fix wrongfull report of a channel as in use
    
    [ Upstream commit dc3f595b6617ebc0307e0ce151e8f2f2b2489b95 ]
    
    atchan->status variable is used to store two different information:
     - pass channel interrupts status from interrupt handler to tasklet;
     - channel information like whether it is cyclic or paused;
    
    This causes a bug when device_terminate_all() is called,
    (AT_XDMAC_CHAN_IS_CYCLIC cleared on atchan->status) and then a late End
    of Block interrupt arrives (AT_XDMAC_CIS_BIS), which sets bit 0 of
    atchan->status. Bit 0 is also used for AT_XDMAC_CHAN_IS_CYCLIC, so when
    a new descriptor for a cyclic transfer is created, the driver reports
    the channel as in use:
    
    if (test_and_set_bit(AT_XDMAC_CHAN_IS_CYCLIC, &atchan->status)) {
            dev_err(chan2dev(chan), "channel currently used\n");
            return NULL;
    }
    
    This patch fixes the bug by adding a different struct member to keep
    the interrupts status separated from the channel status bits.
    
    Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver")
    Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d82c7e8d450c8810ca8c1114df4905f3c5461c6e
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date:   Thu Jan 31 14:25:50 2019 +0100

    drm/sun4i: tcon: Prepare and enable TCON channel 0 clock at init
    
    [ Upstream commit b14e945bda8ae227d1bf2b1837c0c4a61721cd1a ]
    
    When initializing clocks, a reference to the TCON channel 0 clock is
    obtained. However, the clock is never prepared and enabled later.
    Switching from simplefb to DRM actually disables the clock (that was
    usually configured by U-Boot) because of that.
    
    On the V3s, this results in a hang when writing to some mixer registers
    when switching over to DRM from simplefb.
    
    Fix this by preparing and enabling the clock when initializing other
    clocks. Waiting for sun4i_tcon_channel_enable to enable the clock is
    apparently too late and results in the same mixer register access hang.
    
    Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190131132550.26355-1-paul.kocialkowski@bootlin.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1573281a2eb815fb7a00b5310f4fade244d383c0
Author: Lubomir Rintel <lkundrak@v3.sk>
Date:   Mon Jan 28 16:59:35 2019 +0100

    irqchip/mmp: Only touch the PJ4 IRQ & FIQ bits on enable/disable
    
    [ Upstream commit 2380a22b60ce6f995eac806e69c66e397b59d045 ]
    
    Resetting bit 4 disables the interrupt delivery to the "secure
    processor" core. This breaks the keyboard on a OLPC XO 1.75 laptop,
    where the firmware running on the "secure processor" bit-bangs the
    PS/2 protocol over the GPIO lines.
    
    It is not clear what the rest of the bits are and Marvell was unhelpful
    when asked for documentation. Aside from the SP bit, there are probably
    priority bits.
    
    Leaving the unknown bits as the firmware set them up seems to be a wiser
    course of action compared to just turning them off.
    
    Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    [maz: fixed-up subject and commit message]
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ae6eb61f0e16db7cd8a07213dd77cdd06f579d2
Author: Anders Roxell <anders.roxell@linaro.org>
Date:   Tue Jan 22 11:36:02 2019 +0100

    usb: phy: fix link errors
    
    [ Upstream commit f2105d42597f4d10e431b195d69e96dccaf9b012 ]
    
    Fix link errors when CONFIG_FSL_USB2_OTG is enabled and USB_OTG_FSM is
    set to module then the following link error occurs.
    
    aarch64-linux-gnu-ld: drivers/usb/phy/phy-fsl-usb.o: in function `fsl_otg_ioctl':
    drivers/usb/phy/phy-fsl-usb.c:1083: undefined reference to `otg_statemachine'
    aarch64-linux-gnu-ld: drivers/usb/phy/phy-fsl-usb.c:1083:(.text+0x574): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `otg_statemachine'
    aarch64-linux-gnu-ld: drivers/usb/phy/phy-fsl-usb.o: in function `fsl_otg_start_srp':
    drivers/usb/phy/phy-fsl-usb.c:674: undefined reference to `otg_statemachine'
    aarch64-linux-gnu-ld: drivers/usb/phy/phy-fsl-usb.c:674:(.text+0x61c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `otg_statemachine'
    aarch64-linux-gnu-ld: drivers/usb/phy/phy-fsl-usb.o: in function `fsl_otg_set_host':
    drivers/usb/phy/phy-fsl-usb.c:593: undefined reference to `otg_statemachine'
    aarch64-linux-gnu-ld: drivers/usb/phy/phy-fsl-usb.c:593:(.text+0x7a4): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `otg_statemachine'
    aarch64-linux-gnu-ld: drivers/usb/phy/phy-fsl-usb.o: in function `fsl_otg_start_hnp':
    drivers/usb/phy/phy-fsl-usb.c:695: undefined reference to `otg_statemachine'
    aarch64-linux-gnu-ld: drivers/usb/phy/phy-fsl-usb.c:695:(.text+0x858): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `otg_statemachine'
    aarch64-linux-gnu-ld: drivers/usb/phy/phy-fsl-usb.o: in function `a_wait_enum':
    drivers/usb/phy/phy-fsl-usb.c:274: undefined reference to `otg_statemachine'
    aarch64-linux-gnu-ld: drivers/usb/phy/phy-fsl-usb.c:274:(.text+0x16f0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `otg_statemachine'
    aarch64-linux-gnu-ld: drivers/usb/phy/phy-fsl-usb.o:drivers/usb/phy/phy-fsl-usb.c:619: more undefined references to `otg_statemachine' follow
    aarch64-linux-gnu-ld: drivers/usb/phy/phy-fsl-usb.o: in function `fsl_otg_set_peripheral':
    drivers/usb/phy/phy-fsl-usb.c:619:(.text+0x1fa0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `otg_statemachine'
    make[1]: *** [Makefile:1020: vmlinux] Error 1
    make[1]: Target 'Image' not remade because of errors.
    make: *** [Makefile:152: sub-make] Error 2
    make: Target 'Image' not remade because of errors.
    
    Rework so that FSL_USB2_OTG depends on that the USB_OTG_FSM is builtin.
    
    Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 75389275566eac0df65e0e0ba049e77574743f7a
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Mon Dec 10 13:56:33 2018 +0000

    arm64: dts: add msm8996 compatible to gicv3
    
    [ Upstream commit 2a81efb0de0e33f2d2c83154af0bd3ce389b3269 ]
    
    Add compatible to gicv3 node to enable quirk required to restrict writing
    to GICR_WAKER register which is restricted on msm8996 SoC in Hypervisor.
    
    With this quirk MSM8996 can at least boot out of mainline, which can help
    community to work with boards based on MSM8996.
    
    Without this patch Qualcomm DB820c board reboots on mainline.
    
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Signed-off-by: Andy Gross <andy.gross@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06e777ea40b5e4da6f6a655f1885bcbabd328ad6
Author: Peng Hao <peng.hao2@zte.com.cn>
Date:   Sat Dec 29 13:10:06 2018 +0800

    ARM: pxa: ssp: unneeded to free devm_ allocated data
    
    [ Upstream commit ba16adeb346387eb2d1ada69003588be96f098fa ]
    
    devm_ allocated data will be automatically freed. The free
    of devm_ allocated data is invalid.
    
    Fixes: 1c459de1e645 ("ARM: pxa: ssp: use devm_ functions")
    Signed-off-by: Peng Hao <peng.hao2@zte.com.cn>
    [title's prefix changed]
    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d31765ea42565bec01b1319c2a750a1d502e731a
Author: Madalin Bucur <madalin.bucur@nxp.com>
Date:   Fri Dec 21 16:41:42 2018 +0200

    soc: fsl: qbman: avoid race in clearing QMan interrupt
    
    [ Upstream commit 89857a8a5c89a406b967ab2be7bd2ccdbe75e73d ]
    
    By clearing all interrupt sources, not only those that
    already occurred, the existing code may acknowledge by
    mistake interrupts that occurred after the code checks
    for them.
    
    Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
    Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
    Signed-off-by: Li Yang <leoyang.li@nxp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 37b6ac5254e6f16823b81e94173c603fd0e8a70a
Author: Ian Kent <raven@themaw.net>
Date:   Fri Feb 1 14:21:29 2019 -0800

    autofs: fix error return in autofs_fill_super()
    
    [ Upstream commit f585b283e3f025754c45bbe7533fc6e5c4643700 ]
    
    In autofs_fill_super() on error of get inode/make root dentry the return
    should be ENOMEM as this is the only failure case of the called
    functions.
    
    Link: http://lkml.kernel.org/r/154725123240.11260.796773942606871359.stgit@pluto-themaw-net
    Signed-off-by: Ian Kent <raven@themaw.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 07f67e6e9a7f0130a3177101e5c4875b446cb2f9
Author: Pan Bian <bianpan2016@163.com>
Date:   Fri Feb 1 14:21:26 2019 -0800

    autofs: drop dentry reference only when it is never used
    
    [ Upstream commit 63ce5f552beb9bdb41546b3a26c4374758b21815 ]
    
    autofs_expire_run() calls dput(dentry) to drop the reference count of
    dentry.  However, dentry is read via autofs_dentry_ino(dentry) after
    that.  This may result in a use-free-bug.  The patch drops the reference
    count of dentry only when it is never used.
    
    Link: http://lkml.kernel.org/r/154725122396.11260.16053424107144453867.stgit@pluto-themaw-net
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Signed-off-by: Ian Kent <raven@themaw.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c3ce520779d03b1324626a8108f210e17247240c
Author: Jan Kara <jack@suse.cz>
Date:   Fri Feb 1 14:21:23 2019 -0800

    fs/drop_caches.c: avoid softlockups in drop_pagecache_sb()
    
    [ Upstream commit c27d82f52f75fc9d8d9d40d120d2a96fdeeada5e ]
    
    When superblock has lots of inodes without any pagecache (like is the
    case for /proc), drop_pagecache_sb() will iterate through all of them
    without dropping sb->s_inode_list_lock which can lead to softlockups
    (one of our customers hit this).
    
    Fix the problem by going to the slow path and doing cond_resched() in
    case the process needs rescheduling.
    
    Link: http://lkml.kernel.org/r/20190114085343.15011-1-jack@suse.cz
    Signed-off-by: Jan Kara <jack@suse.cz>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3016e96863cefe2d90de6e65283fa62a0bfce8ac
Author: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Date:   Fri Feb 1 14:20:38 2019 -0800

    mm, memory_hotplug: test_pages_in_a_zone do not pass the end of zone
    
    [ Upstream commit 24feb47c5fa5b825efb0151f28906dfdad027e61 ]
    
    If memory end is not aligned with the sparse memory section boundary,
    the mapping of such a section is only partly initialized.  This may lead
    to VM_BUG_ON due to uninitialized struct pages access from
    test_pages_in_a_zone() function triggered by memory_hotplug sysfs
    handlers.
    
    Here are the the panic examples:
     CONFIG_DEBUG_VM_PGFLAGS=y
     kernel parameter mem=2050M
     --------------------------
     page:000003d082008000 is uninitialized and poisoned
     page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
     Call Trace:
       test_pages_in_a_zone+0xde/0x160
       show_valid_zones+0x5c/0x190
       dev_attr_show+0x34/0x70
       sysfs_kf_seq_show+0xc8/0x148
       seq_read+0x204/0x480
       __vfs_read+0x32/0x178
       vfs_read+0x82/0x138
       ksys_read+0x5a/0xb0
       system_call+0xdc/0x2d8
     Last Breaking-Event-Address:
       test_pages_in_a_zone+0xde/0x160
     Kernel panic - not syncing: Fatal exception: panic_on_oops
    
    Fix this by checking whether the pfn to check is within the zone.
    
    [mhocko@suse.com: separated this change from http://lkml.kernel.org/r/20181105150401.97287-2-zaslonko@linux.ibm.com]
    Link: http://lkml.kernel.org/r/20190128144506.15603-3-mhocko@kernel.org
    
    [mhocko@suse.com: separated this change from
    http://lkml.kernel.org/r/20181105150401.97287-2-zaslonko@linux.ibm.com]
    Signed-off-by: Michal Hocko <mhocko@suse.com>
    Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
    Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Tested-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
    Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 61fdbbb8b0bbdd8582396eca7b98439d94333b07
Author: Michal Hocko <mhocko@suse.com>
Date:   Fri Feb 1 14:20:34 2019 -0800

    mm, memory_hotplug: is_mem_section_removable do not pass the end of a zone
    
    [ Upstream commit efad4e475c312456edb3c789d0996d12ed744c13 ]
    
    Patch series "mm, memory_hotplug: fix uninitialized pages fallouts", v2.
    
    Mikhail Zaslonko has posted fixes for the two bugs quite some time ago
    [1].  I have pushed back on those fixes because I believed that it is
    much better to plug the problem at the initialization time rather than
    play whack-a-mole all over the hotplug code and find all the places
    which expect the full memory section to be initialized.
    
    We have ended up with commit 2830bf6f05fb ("mm, memory_hotplug:
    initialize struct pages for the full memory section") merged and cause a
    regression [2][3].  The reason is that there might be memory layouts
    when two NUMA nodes share the same memory section so the merged fix is
    simply incorrect.
    
    In order to plug this hole we really have to be zone range aware in
    those handlers.  I have split up the original patch into two.  One is
    unchanged (patch 2) and I took a different approach for `removable'
    crash.
    
    [1] http://lkml.kernel.org/r/20181105150401.97287-2-zaslonko@linux.ibm.com
    [2] https://bugzilla.redhat.com/show_bug.cgi?id=1666948
    [3] http://lkml.kernel.org/r/20190125163938.GA20411@dhcp22.suse.cz
    
    This patch (of 2):
    
    Mikhail has reported the following VM_BUG_ON triggered when reading sysfs
    removable state of a memory block:
    
     page:000003d08300c000 is uninitialized and poisoned
     page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
     Call Trace:
       is_mem_section_removable+0xb4/0x190
       show_mem_removable+0x9a/0xd8
       dev_attr_show+0x34/0x70
       sysfs_kf_seq_show+0xc8/0x148
       seq_read+0x204/0x480
       __vfs_read+0x32/0x178
       vfs_read+0x82/0x138
       ksys_read+0x5a/0xb0
       system_call+0xdc/0x2d8
     Last Breaking-Event-Address:
       is_mem_section_removable+0xb4/0x190
     Kernel panic - not syncing: Fatal exception: panic_on_oops
    
    The reason is that the memory block spans the zone boundary and we are
    stumbling over an unitialized struct page.  Fix this by enforcing zone
    range in is_mem_section_removable so that we never run away from a zone.
    
    Link: http://lkml.kernel.org/r/20190128144506.15603-2-mhocko@kernel.org
    Signed-off-by: Michal Hocko <mhocko@suse.com>
    Reported-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
    Debugged-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
    Tested-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
    Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 42813d9c08add87803a13cfd9908bab81a08aa37
Author: Qian Cai <cai@lca.pw>
Date:   Fri Feb 1 14:20:20 2019 -0800

    x86_64: increase stack size for KASAN_EXTRA
    
    [ Upstream commit a8e911d13540487942d53137c156bd7707f66e5d ]
    
    If the kernel is configured with KASAN_EXTRA, the stack size is
    increasted significantly because this option sets "-fstack-reuse" to
    "none" in GCC [1].  As a result, it triggers stack overrun quite often
    with 32k stack size compiled using GCC 8.  For example, this reproducer
    
      https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise06.c
    
    triggers a "corrupted stack end detected inside scheduler" very reliably
    with CONFIG_SCHED_STACK_END_CHECK enabled.
    
    There are just too many functions that could have a large stack with
    KASAN_EXTRA due to large local variables that have been called over and
    over again without being able to reuse the stacks.  Some noticiable ones
    are
    
      size
      7648 shrink_page_list
      3584 xfs_rmap_convert
      3312 migrate_page_move_mapping
      3312 dev_ethtool
      3200 migrate_misplaced_transhuge_page
      3168 copy_process
    
    There are other 49 functions are over 2k in size while compiling kernel
    with "-Wframe-larger-than=" even with a related minimal config on this
    machine.  Hence, it is too much work to change Makefiles for each object
    to compile without "-fsanitize-address-use-after-scope" individually.
    
    [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715#c23
    
    Although there is a patch in GCC 9 to help the situation, GCC 9 probably
    won't be released in a few months and then it probably take another
    6-month to 1-year for all major distros to include it as a default.
    Hence, the stack usage with KASAN_EXTRA can be revisited again in 2020
    when GCC 9 is everywhere.  Until then, this patch will help users avoid
    stack overrun.
    
    This has already been fixed for arm64 for the same reason via
    6e8830674ea ("arm64: kasan: Increase stack size for KASAN_EXTRA").
    
    Link: http://lkml.kernel.org/r/20190109215209.2903-1-cai@lca.pw
    Signed-off-by: Qian Cai <cai@lca.pw>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c2ca09ca45900fc283e23c3c70acbe69edcbbb4
Author: Kairui Song <kasong@redhat.com>
Date:   Fri Jan 18 19:13:08 2019 +0800

    x86/kexec: Don't setup EFI info if EFI runtime is not enabled
    
    [ Upstream commit 2aa958c99c7fd3162b089a1a56a34a0cdb778de1 ]
    
    Kexec-ing a kernel with "efi=noruntime" on the first kernel's command
    line causes the following null pointer dereference:
    
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
      #PF error: [normal kernel read fault]
      Call Trace:
       efi_runtime_map_copy+0x28/0x30
       bzImage64_load+0x688/0x872
       arch_kexec_kernel_image_load+0x6d/0x70
       kimage_file_alloc_init+0x13e/0x220
       __x64_sys_kexec_file_load+0x144/0x290
       do_syscall_64+0x55/0x1a0
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Just skip the EFI info setup if EFI runtime services are not enabled.
    
     [ bp: Massage commit message. ]
    
    Suggested-by: Dave Young <dyoung@redhat.com>
    Signed-off-by: Kairui Song <kasong@redhat.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Dave Young <dyoung@redhat.com>
    Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Cc: bhe@redhat.com
    Cc: David Howells <dhowells@redhat.com>
    Cc: erik.schmauss@intel.com
    Cc: fanc.fnst@cn.fujitsu.com
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: kexec@lists.infradead.org
    Cc: lenb@kernel.org
    Cc: linux-acpi@vger.kernel.org
    Cc: Philipp Rudo <prudo@linux.vnet.ibm.com>
    Cc: rafael.j.wysocki@intel.com
    Cc: robert.moore@intel.com
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: x86-ml <x86@kernel.org>
    Cc: Yannik Sembritzki <yannik@sembritzki.me>
    Link: https://lkml.kernel.org/r/20190118111310.29589-2-kasong@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32d14df09a909fb333734e63c2f2e4facaead26b
Author: James Morse <james.morse@arm.com>
Date:   Thu Jan 24 16:32:55 2019 +0000

    arm64: kprobe: Always blacklist the KVM world-switch code
    
    [ Upstream commit f2b3d8566d81deaca31f4e3163def0bea7746e11 ]
    
    On systems with VHE the kernel and KVM's world-switch code run at the
    same exception level. Code that is only used on a VHE system does not
    need to be annotated as __hyp_text as it can reside anywhere in the
     kernel text.
    
    __hyp_text was also used to prevent kprobes from patching breakpoint
    instructions into this region, as this code runs at a different
    exception level. While this is no longer true with VHE, KVM still
    switches VBAR_EL1, meaning a kprobe's breakpoint executed in the
    world-switch code will cause a hyp-panic.
    
    Move the __hyp_text check in the kprobes blacklist so it applies on
    VHE systems too, to cover the common code and guest enter/exit
    assembly.
    
    Fixes: 888b3c8720e0 ("arm64: Treat all entry code as non-kprobe-able")
    Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
    Signed-off-by: James Morse <james.morse@arm.com>
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b0ac76f1c943463d156d54c63f8555ca429fd34
Author: Ronnie Sahlberg <lsahlber@redhat.com>
Date:   Tue Jan 29 12:46:16 2019 +1000

    cifs: fix computation for MAX_SMB2_HDR_SIZE
    
    [ Upstream commit 58d15ed1203f4d858c339ea4d7dafa94bd2a56d3 ]
    
    The size of the fixed part of the create response is 88 bytes not 56.
    
    Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4a2e5c58c67e028c8183e32fc05825ddceeeccce
Author: Sinan Kaya <okaya@kernel.org>
Date:   Thu Jan 24 19:31:01 2019 +0000

    platform/x86: Fix unmet dependency warning for SAMSUNG_Q10
    
    [ Upstream commit 0ee4b5f801b73b83a9fb3921d725f2162fd4a2e5 ]
    
    Add BACKLIGHT_LCD_SUPPORT for SAMSUNG_Q10 to fix the
    warning: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE.
    
    SAMSUNG_Q10 selects BACKLIGHT_CLASS_DEVICE but BACKLIGHT_CLASS_DEVICE
    depends on BACKLIGHT_LCD_SUPPORT.
    
    Copy BACKLIGHT_LCD_SUPPORT dependency into SAMSUNG_Q10 to fix:
    
    WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE
      Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n]
      Selected by [y]:
      - SAMSUNG_Q10 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y]
    
    Signed-off-by: Sinan Kaya <okaya@kernel.org>
    Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5224c7811d50b5f2bbc26723b4bf4fc90dbdb2e7
Author: Ming Lu <ming.lu@citrix.com>
Date:   Thu Jan 24 13:25:42 2019 +0800

    scsi: libfc: free skb when receiving invalid flogi resp
    
    [ Upstream commit 5d8fc4a9f0eec20b6c07895022a6bea3fb6dfb38 ]
    
    The issue to be fixed in this commit is when libfc found it received a
    invalid FLOGI response from FC switch, it would return without freeing the
    fc frame, which is just the skb data. This would cause memory leak if FC
    switch keeps sending invalid FLOGI responses.
    
    This fix is just to make it execute `fc_frame_free(fp)` before returning
    from function `fc_lport_flogi_resp`.
    
    Signed-off-by: Ming Lu <ming.lu@citrix.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f85469e778e803d43e73cbf53be0401b854de39b
Author: Manish Chopra <manishc@marvell.com>
Date:   Mon Jan 28 10:05:06 2019 -0800

    qed: Fix VF probe failure while FLR
    
    [ Upstream commit 327852ec64205bb651be391a069784872098a3b2 ]
    
    VFs may hit VF-PF channel timeout while probing, as in some
    cases it was observed that VF FLR and VF "acquire" message
    transaction (i.e first message from VF to PF in VF's probe flow)
    could occur simultaneously which could lead VF to fail sending
    "acquire" message to PF as VF is marked disabled from HW perspective
    due to FLR, which will result into channel timeout and VF probe failure.
    
    In such cases, try retrying VF "acquire" message so that in later
    attempts it could be successful to pass message to PF after the VF
    FLR is completed and can be probed successfully.
    
    Signed-off-by: Manish Chopra <manishc@marvell.com>
    Signed-off-by: Ariel Elior <aelior@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f976ecaf133d1b5c5e87f5295fbbb8e4e6613e5
Author: Yao Liu <yotta.liu@ucloud.cn>
Date:   Mon Jan 28 19:44:14 2019 +0800

    nfs: Fix NULL pointer dereference of dev_name
    
    [ Upstream commit 80ff00172407e0aad4b10b94ef0816fc3e7813cb ]
    
    There is a NULL pointer dereference of dev_name in nfs_parse_devname()
    
    The oops looks something like:
    
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
      ...
      RIP: 0010:nfs_fs_mount+0x3b6/0xc20 [nfs]
      ...
      Call Trace:
       ? ida_alloc_range+0x34b/0x3d0
       ? nfs_clone_super+0x80/0x80 [nfs]
       ? nfs_free_parsed_mount_data+0x60/0x60 [nfs]
       mount_fs+0x52/0x170
       ? __init_waitqueue_head+0x3b/0x50
       vfs_kern_mount+0x6b/0x170
       do_mount+0x216/0xdc0
       ksys_mount+0x83/0xd0
       __x64_sys_mount+0x25/0x30
       do_syscall_64+0x65/0x220
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Fix this by adding a NULL check on dev_name
    
    Signed-off-by: Yao Liu <yotta.liu@ucloud.cn>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f6a66361b2556811b560071ca7bd21a22156dc4
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Sun Jan 27 22:58:00 2019 +0100

    gpio: vf610: Mask all GPIO interrupts
    
    [ Upstream commit 7ae710f9f8b2cf95297e7bbfe1c09789a7dc43d4 ]
    
    On SoC reset all GPIO interrupts are disable. However, if kexec is
    used to boot into a new kernel, the SoC does not experience a
    reset. Hence GPIO interrupts can be left enabled from the previous
    kernel. It is then possible for the interrupt to fire before an
    interrupt handler is registered, resulting in the kernel complaining
    of an "unexpected IRQ trap", the interrupt is never cleared, and so
    fires again, resulting in an interrupt storm.
    
    Disable all GPIO interrupts before registering the GPIO IRQ chip.
    
    Fixes: 7f2691a19627 ("gpio: vf610: add gpiolib/IRQ chip driver for Vybrid")
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Acked-by: Stefan Agner <stefan@agner.ch>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e6330840bc0845ffc546d376a09a5eecbf10659
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Sat Jan 26 22:48:57 2019 +0300

    net: stmmac: dwmac-rk: fix error handling in rk_gmac_powerup()
    
    [ Upstream commit c69c29a1a0a8f68cd87e98ba4a5a79fb8ef2a58c ]
    
    If phy_power_on() fails in rk_gmac_powerup(), clocks are left enabled.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 91500a8493d6d53657a679ca61f5a165487b8965
Author: Yonglong Liu <liuyonglong@huawei.com>
Date:   Sat Jan 26 17:18:27 2019 +0800

    net: hns: Fix wrong read accesses via Clause 45 MDIO protocol
    
    [ Upstream commit cec8abba13e6a26729dfed41019720068eeeff2b ]
    
    When reading phy registers via Clause 45 MDIO protocol, after write
    address operation, the driver use another write address operation, so
    can not read the right value of any phy registers. This patch fixes it.
    
    Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
    Signed-off-by: Peng Li <lipeng321@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e8e523420602c2aa0685062a8b361c8500f3bb0
Author: Yonglong Liu <liuyonglong@huawei.com>
Date:   Sat Jan 26 17:18:25 2019 +0800

    net: hns: Fix for missing of_node_put() after of_parse_phandle()
    
    [ Upstream commit 263c6d75f9a544a3c2f8f6a26de4f4808d8f59cf ]
    
    In hns enet driver, we use of_parse_handle() to get hold of the
    device node related to "ae-handle" but we have missed to put
    the node reference using of_node_put() after we are done using
    the node. This patch fixes it.
    
    Note:
    This problem is stated in Link: https://lkml.org/lkml/2018/12/22/217
    
    Fixes: 48189d6aaf1e ("net: hns: enet specifies a reference to dsaf")
    Reported-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
    Signed-off-by: Peng Li <lipeng321@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cdf3d54517b5afda3a85ed737917ab1a820f5c9a
Author: Tomonori Sakita <tomonori.sakita@sord.co.jp>
Date:   Fri Jan 25 11:02:22 2019 +0900

    net: altera_tse: fix msgdma_tx_completion on non-zero fill_level case
    
    [ Upstream commit 6571ebce112a21ec9be68ef2f53b96fcd41fd81b ]
    
    If fill_level was not zero and status was not BUSY,
    result of "tx_prod - tx_cons - inuse" might be zero.
    Subtracting 1 unconditionally results invalid negative return value
    on this case.
    Make sure not to return an negative value.
    
    Signed-off-by: Tomonori Sakita <tomonori.sakita@sord.co.jp>
    Signed-off-by: Atsushi Nemoto <atsushi.nemoto@sord.co.jp>
    Reviewed-by: Dalon L Westergreen <dalon.westergreen@linux.intel.com>
    Acked-by: Thor Thayer <thor.thayer@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d1ef64ecaf077b683e5f86a2cd76000829a2f90
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Sat Jan 26 20:35:18 2019 -0800

    xtensa: SMP: limit number of possible CPUs by NR_CPUS
    
    [ Upstream commit 25384ce5f9530def39421597b1457d9462df6455 ]
    
    This fixes the following warning at boot when the kernel is booted on a
    board with more CPU cores than was configured in NR_CPUS:
    
      smp_init_cpus: Core Count = 8
      smp_init_cpus: Core Id = 0
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 0 at include/linux/cpumask.h:121 smp_init_cpus+0x54/0x74
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc3-00015-g1459333f88a0 #124
      Call Trace:
        __warn$part$3+0x6a/0x7c
        warn_slowpath_null+0x35/0x3c
        smp_init_cpus+0x54/0x74
        setup_arch+0x1c0/0x1d0
        start_kernel+0x44/0x310
        _startup+0x107/0x107
    
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11a4dc890959b81310f2faf8f6a5f86af0ccaf1a
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Sat Jan 19 00:26:48 2019 -0800

    xtensa: SMP: mark each possible CPU as present
    
    [ Upstream commit 8b1c42cdd7181200dc1fff39dcb6ac1a3fac2c25 ]
    
    Otherwise it is impossible to enable CPUs after booting with 'maxcpus'
    parameter.
    
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db325a389ce02c155f1d98b366c15442b517da21
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Thu Jan 24 17:16:11 2019 -0800

    xtensa: smp_lx200_defconfig: fix vectors clash
    
    [ Upstream commit 306b38305c0f86de7f17c5b091a95451dcc93d7d ]
    
    Secondary CPU reset vector overlaps part of the double exception handler
    code, resulting in weird crashes and hangups when running user code.
    Move exception vectors one page up so that they don't clash with the
    secondary CPU reset vector.
    
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e2f3fd4d5b3d480837bf4da405b4b4dc238db96c
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Fri Dec 21 08:26:20 2018 -0800

    xtensa: SMP: fix secondary CPU initialization
    
    [ Upstream commit 32a7726c4f4aadfabdb82440d84f88a5a2c8fe13 ]
    
    - add missing memory barriers to the secondary CPU synchronization spin
      loops; add comment to the matching memory barrier in the boot_secondary
      and __cpu_die functions;
    - use READ_ONCE/WRITE_ONCE to access cpu_start_id/cpu_start_ccount
      instead of reading/writing them directly;
    - re-initialize cpu_running every time before starting secondary CPU to
      flush possible previous CPU startup results.
    
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aa9b819beeca166b31ca52288a8aae94cdf99a50
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Mon Jan 29 09:09:41 2018 -0800

    xtensa: SMP: fix ccount_timer_shutdown
    
    [ Upstream commit 4fe8713b873fc881284722ce4ac47995de7cf62c ]
    
    ccount_timer_shutdown is called from the atomic context in the
    secondary_start_kernel, resulting in the following BUG:
    
    BUG: sleeping function called from invalid context
    in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1
    Preemption disabled at:
      secondary_start_kernel+0xa1/0x130
    Call Trace:
      ___might_sleep+0xe7/0xfc
      __might_sleep+0x41/0x44
      synchronize_irq+0x24/0x64
      disable_irq+0x11/0x14
      ccount_timer_shutdown+0x12/0x20
      clockevents_switch_state+0x82/0xb4
      clockevents_exchange_device+0x54/0x60
      tick_check_new_device+0x46/0x70
      clockevents_register_device+0x8c/0xc8
      clockevents_config_and_register+0x1d/0x2c
      local_timer_setup+0x75/0x7c
      secondary_start_kernel+0xb4/0x130
      should_never_return+0x32/0x35
    
    Use disable_irq_nosync instead of disable_irq to avoid it.
    This is safe because the ccount timer IRQ is per-CPU, and once IRQ is
    masked the ISR will not be called.
    
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2efa79e89223e35a935b8e82c91f09ce8f3937e7
Author: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Date:   Thu Jan 24 04:16:45 2019 +0000

    iommu/amd: Fix IOMMU page flush when detach device from a domain
    
    [ Upstream commit 9825bd94e3a2baae1f4874767ae3a7d4c049720e ]
    
    When a VM is terminated, the VFIO driver detaches all pass-through
    devices from VFIO domain by clearing domain id and page table root
    pointer from each device table entry (DTE), and then invalidates
    the DTE. Then, the VFIO driver unmap pages and invalidate IOMMU pages.
    
    Currently, the IOMMU driver keeps track of which IOMMU and how many
    devices are attached to the domain. When invalidate IOMMU pages,
    the driver checks if the IOMMU is still attached to the domain before
    issuing the invalidate page command.
    
    However, since VFIO has already detached all devices from the domain,
    the subsequent INVALIDATE_IOMMU_PAGES commands are being skipped as
    there is no IOMMU attached to the domain. This results in data
    corruption and could cause the PCI device to end up in indeterministic
    state.
    
    Fix this by invalidate IOMMU pages when detach a device, and
    before decrementing the per-domain device reference counts.
    
    Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Suggested-by: Joerg Roedel <joro@8bytes.org>
    Co-developed-by: Brijesh Singh <brijesh.singh@amd.com>
    Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
    Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Fixes: 6de8ad9b9ee0 ('x86/amd-iommu: Make iommu_flush_pages aware of multiple IOMMUs')
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 304e1f0723c4b2cd5727f5d25da9907294312cb9
Author: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
Date:   Thu Jan 10 16:39:06 2019 +0800

    ipvs: Fix signed integer overflow when setsockopt timeout
    
    [ Upstream commit 53ab60baa1ac4f20b080a22c13b77b6373922fd7 ]
    
    There is a UBSAN bug report as below:
    UBSAN: Undefined behaviour in net/netfilter/ipvs/ip_vs_ctl.c:2227:21
    signed integer overflow:
    -2147483647 * 1000 cannot be represented in type 'int'
    
    Reproduce program:
            #include <stdio.h>
            #include <sys/types.h>
            #include <sys/socket.h>
    
            #define IPPROTO_IP 0
            #define IPPROTO_RAW 255
    
            #define IP_VS_BASE_CTL          (64+1024+64)
            #define IP_VS_SO_SET_TIMEOUT    (IP_VS_BASE_CTL+10)
    
            /* The argument to IP_VS_SO_GET_TIMEOUT */
            struct ipvs_timeout_t {
                    int tcp_timeout;
                    int tcp_fin_timeout;
                    int udp_timeout;
            };
    
            int main() {
                    int ret = -1;
                    int sockfd = -1;
                    struct ipvs_timeout_t to;
    
                    sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_RAW);
                    if (sockfd == -1) {
                            printf("socket init error\n");
                            return -1;
                    }
    
                    to.tcp_timeout = -2147483647;
                    to.tcp_fin_timeout = -2147483647;
                    to.udp_timeout = -2147483647;
    
                    ret = setsockopt(sockfd,
                                     IPPROTO_IP,
                                     IP_VS_SO_SET_TIMEOUT,
                                     (char *)(&to),
                                     sizeof(to));
    
                    printf("setsockopt return %d\n", ret);
                    return ret;
            }
    
    Return -EINVAL if the timeout value is negative or max than 'INT_MAX / HZ'.
    
    Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
    Acked-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50c382e88a79adc366ef12276a10461b3ebe8af9
Author: Jerry Snitselaar <jsnitsel@redhat.com>
Date:   Sat Jan 19 10:38:05 2019 -0700

    iommu/amd: Unmap all mapped pages in error path of map_sg
    
    [ Upstream commit f1724c0883bb0ce93b8dcb94b53dcca3b75ac9a7 ]
    
    In the error path of map_sg there is an incorrect if condition
    for breaking out of the loop that searches the scatterlist
    for mapped pages to unmap. Instead of breaking out of the
    loop once all the pages that were mapped have been unmapped,
    it will break out of the loop after it has unmapped 1 page.
    Fix the condition, so it breaks out of the loop only after
    all the mapped pages have been unmapped.
    
    Fixes: 80187fd39dcb ("iommu/amd: Optimize map_sg and unmap_sg")
    Cc: Joerg Roedel <joro@8bytes.org>
    Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a6c9f65e75526e72bc114638b97a624a7c7d9f8
Author: Jerry Snitselaar <jsnitsel@redhat.com>
Date:   Thu Jan 17 12:29:02 2019 -0700

    iommu/amd: Call free_iova_fast with pfn in map_sg
    
    [ Upstream commit 51d8838d66d3249508940d8f59b07701f2129723 ]
    
    In the error path of map_sg, free_iova_fast is being called with
    address instead of the pfn. This results in a bad value getting into
    the rcache, and can result in hitting a BUG_ON when
    iova_magazine_free_pfns is called.
    
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
    Fixes: 80187fd39dcb ("iommu/amd: Optimize map_sg and unmap_sg")
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c310cd9fa235b00cc33443efc09acfd496b1078
Author: Brian Welty <brian.welty@intel.com>
Date:   Thu Jan 17 12:41:32 2019 -0800

    IB/{hfi1, qib}: Fix WC.byte_len calculation for UD_SEND_WITH_IMM
    
    [ Upstream commit 904bba211acc2112fdf866e5a2bc6cd9ecd0de1b ]
    
    The work completion length for a receiving a UD send with immediate is
    short by 4 bytes causing application using this opcode to fail.
    
    The UD receive logic incorrectly subtracts 4 bytes for immediate
    value. These bytes are already included in header length and are used to
    calculate header/payload split, so the result is these 4 bytes are
    subtracted twice, once when the header length subtracted from the overall
    length and once again in the UD opcode specific path.
    
    Remove the extra subtraction when handling the opcode.
    
    Fixes: 7724105686e7 ("IB/hfi1: add driver files")
    Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
    Signed-off-by: Brian Welty <brian.welty@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70ffacb73785bd2d4ebe0f205c75c809ea920e47
Author: Stephane Eranian <eranian@google.com>
Date:   Sat Jan 19 00:12:39 2019 -0800

    perf tools: Handle TOPOLOGY headers with no CPU
    
    [ Upstream commit 1497e804d1a6e2bd9107ddf64b0310449f4673eb ]
    
    This patch fixes an issue in cpumap.c when used with the TOPOLOGY
    header. In some configurations, some NUMA nodes may have no CPU (empty
    cpulist). Yet a cpumap map must be created otherwise perf abort with an
    error. This patch handles this case by creating a dummy map.
    
      Before:
    
      $ perf record -o - -e cycles noploop 2 | perf script -i -
      0x6e8 [0x6c]: failed to process type: 80
    
      After:
    
      $ perf record -o - -e cycles noploop 2 | perf script -i -
      noploop for 2 seconds
    
    Signed-off-by: Stephane Eranian <eranian@google.com>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1547885559-1657-1-git-send-email-eranian@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d3916f7aaf13ee84d3109592209946722da1731
Author: Stephane Eranian <eranian@google.com>
Date:   Thu Jan 10 17:17:16 2019 -0800

    perf core: Fix perf_proc_update_handler() bug
    
    [ Upstream commit 1a51c5da5acc6c188c917ba572eebac5f8793432 ]
    
    The perf_proc_update_handler() handles /proc/sys/kernel/perf_event_max_sample_rate
    syctl variable.  When the PMU IRQ handler timing monitoring is disabled, i.e,
    when /proc/sys/kernel/perf_cpu_time_max_percent is equal to 0 or 100,
    then no modification to sysctl_perf_event_sample_rate is allowed to prevent
    possible hang from wrong values.
    
    The problem is that the test to prevent modification is made after the
    sysctl variable is modified in perf_proc_update_handler().
    
    You get an error:
    
      $ echo 10001 >/proc/sys/kernel/perf_event_max_sample_rate
      echo: write error: invalid argument
    
    But the value is still modified causing all sorts of inconsistencies:
    
      $ cat /proc/sys/kernel/perf_event_max_sample_rate
      10001
    
    This patch fixes the problem by moving the parsing of the value after
    the test.
    
    Committer testing:
    
      # echo 100 > /proc/sys/kernel/perf_cpu_time_max_percent
      # echo 10001 > /proc/sys/kernel/perf_event_max_sample_rate
      -bash: echo: write error: Invalid argument
      # cat /proc/sys/kernel/perf_event_max_sample_rate
      10001
      #
    
    Signed-off-by: Stephane Eranian <eranian@google.com>
    Reviewed-by: Andi Kleen <ak@linux.intel.com>
    Reviewed-by: Jiri Olsa <jolsa@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/1547169436-6266-1-git-send-email-eranian@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d2a6df768b5565275014149dcf5e634c0b527096
Author: Su Yanjun <suyj.fnst@cn.fujitsu.com>
Date:   Sun Jan 6 21:31:20 2019 -0500

    vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel
    
    [ Upstream commit dd9ee3444014e8f28c0eefc9fffc9ac9c5248c12 ]
    
    Recently we run a network test over ipcomp virtual tunnel.We find that
    if a ipv4 packet needs fragment, then the peer can't receive
    it.
    
    We deep into the code and find that when packet need fragment the smaller
    fragment will be encapsulated by ipip not ipcomp. So when the ipip packet
    goes into xfrm, it's skb->dev is not properly set. The ipv4 reassembly code
    always set skb'dev to the last fragment's dev. After ipv4 defrag processing,
    when the kernel rp_filter parameter is set, the skb will be drop by -EXDEV
    error.
    
    This patch adds compatible support for the ipip process in ipcomp virtual tunnel.
    
    Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47d77d464e574d56eecb39677df7bc6663635a3f
Author: Alistair Strachan <astrachan@google.com>
Date:   Tue Dec 18 20:32:48 2018 -0500

    media: uvcvideo: Fix 'type' check leading to overflow
    
    commit 47bb117911b051bbc90764a8bff96543cbd2005f upstream.
    
    When initially testing the Camera Terminal Descriptor wTerminalType
    field (buffer[4]), no mask is used. Later in the function, the MSB is
    overloaded to store the descriptor subtype, and so a mask of 0x7fff
    is used to check the type.
    
    If a descriptor is specially crafted to set this overloaded bit in the
    original wTerminalType field, the initial type check will fail (falling
    through, without adjusting the buffer size), but the later type checks
    will pass, assuming the buffer has been made suitably large, causing an
    overflow.
    
    Avoid this problem by checking for the MSB in the wTerminalType field.
    If the bit is set, assume the descriptor is bad, and abort parsing it.
    
    Originally reported here:
    https://groups.google.com/forum/#!topic/syzkaller/Ot1fOE6v1d8
    A similar (non-compiling) patch was provided at that time.
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Alistair Strachan <astrachan@google.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd6734e17903f16a47c78d0418f02e06df080c54
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Tue Feb 19 10:10:38 2019 +0800

    exec: Fix mem leak in kernel_read_file
    
    commit f612acfae86af7ecad754ae6a46019be9da05b8e upstream.
    
    syzkaller report this:
    BUG: memory leak
    unreferenced object 0xffffc9000488d000 (size 9195520):
      comm "syz-executor.0", pid 2752, jiffies 4294787496 (age 18.757s)
      hex dump (first 32 bytes):
        ff ff ff ff ff ff ff ff a8 00 00 00 01 00 00 00  ................
        02 00 00 00 00 00 00 00 80 a1 7a c1 ff ff ff ff  ..........z.....
      backtrace:
        [<000000000863775c>] __vmalloc_node mm/vmalloc.c:1795 [inline]
        [<000000000863775c>] __vmalloc_node_flags mm/vmalloc.c:1809 [inline]
        [<000000000863775c>] vmalloc+0x8c/0xb0 mm/vmalloc.c:1831
        [<000000003f668111>] kernel_read_file+0x58f/0x7d0 fs/exec.c:924
        [<000000002385813f>] kernel_read_file_from_fd+0x49/0x80 fs/exec.c:993
        [<0000000011953ff1>] __do_sys_finit_module+0x13b/0x2a0 kernel/module.c:3895
        [<000000006f58491f>] do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
        [<00000000ee78baf4>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
        [<00000000241f889b>] 0xffffffffffffffff
    
    It should goto 'out_free' lable to free allocated buf while kernel_read
    fails.
    
    Fixes: 39d637af5aa7 ("vfs: forbid write access when reading a file into memory")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Thibaut Sautereau <thibaut@sautereau.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b010e03dd5306eef6ba983f17017bfecbf4150f3
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date:   Thu Feb 28 16:22:02 2019 -0800

    hugetlbfs: fix races and page leaks during migration
    
    commit cb6acd01e2e43fd8bad11155752b7699c3d0fb76 upstream.
    
    hugetlb pages should only be migrated if they are 'active'.  The
    routines set/clear_page_huge_active() modify the active state of hugetlb
    pages.
    
    When a new hugetlb page is allocated at fault time, set_page_huge_active
    is called before the page is locked.  Therefore, another thread could
    race and migrate the page while it is being added to page table by the
    fault code.  This race is somewhat hard to trigger, but can be seen by
    strategically adding udelay to simulate worst case scheduling behavior.
    Depending on 'how' the code races, various BUG()s could be triggered.
    
    To address this issue, simply delay the set_page_huge_active call until
    after the page is successfully added to the page table.
    
    Hugetlb pages can also be leaked at migration time if the pages are
    associated with a file in an explicitly mounted hugetlbfs filesystem.
    For example, consider a two node system with 4GB worth of huge pages
    available.  A program mmaps a 2G file in a hugetlbfs filesystem.  It
    then migrates the pages associated with the file from one node to
    another.  When the program exits, huge page counts are as follows:
    
      node0
      1024    free_hugepages
      1024    nr_hugepages
    
      node1
      0       free_hugepages
      1024    nr_hugepages
    
      Filesystem                         Size  Used Avail Use% Mounted on
      nodev                              4.0G  2.0G  2.0G  50% /var/opt/hugepool
    
    That is as expected.  2G of huge pages are taken from the free_hugepages
    counts, and 2G is the size of the file in the explicitly mounted
    filesystem.  If the file is then removed, the counts become:
    
      node0
      1024    free_hugepages
      1024    nr_hugepages
    
      node1
      1024    free_hugepages
      1024    nr_hugepages
    
      Filesystem                         Size  Used Avail Use% Mounted on
      nodev                              4.0G  2.0G  2.0G  50% /var/opt/hugepool
    
    Note that the filesystem still shows 2G of pages used, while there
    actually are no huge pages in use.  The only way to 'fix' the filesystem
    accounting is to unmount the filesystem
    
    If a hugetlb page is associated with an explicitly mounted filesystem,
    this information in contained in the page_private field.  At migration
    time, this information is not preserved.  To fix, simply transfer
    page_private from old to new page at migration time if necessary.
    
    There is a related race with removing a huge page from a file and
    migration.  When a huge page is removed from the pagecache, the
    page_mapping() field is cleared, yet page_private remains set until the
    page is actually freed by free_huge_page().  A page could be migrated
    while in this state.  However, since page_mapping() is not set the
    hugetlbfs specific routine to transfer page_private is not called and we
    leak the page count in the filesystem.
    
    To fix that, check for this condition before migrating a huge page.  If
    the condition is detected, return EBUSY for the page.
    
    Link: http://lkml.kernel.org/r/74510272-7319-7372-9ea6-ec914734c179@oracle.com
    Link: http://lkml.kernel.org/r/20190212221400.3512-1-mike.kravetz@oracle.com
    Fixes: bcc54222309c ("mm: hugetlb: introduce page_huge_active")
    Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
    Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: <stable@vger.kernel.org>
    [mike.kravetz@oracle.com: v2]
      Link: http://lkml.kernel.org/r/7534d322-d782-8ac6-1c8d-a8dc380eb3ab@oracle.com
    [mike.kravetz@oracle.com: update comment and changelog]
      Link: http://lkml.kernel.org/r/420bcfd6-158b-38e4-98da-26d0cd85bd01@oracle.com
    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 2ffcbeb5ac8b36d71385fb2d75d915dfda640272
Author: Liu Xiang <liu.xiang6@zte.com.cn>
Date:   Sat Feb 16 17:12:24 2019 +0800

    MIPS: irq: Allocate accurate order pages for irq stack
    
    commit 72faa7a773ca59336f3c889e878de81445c5a85c upstream.
    
    The irq_pages is the number of pages for irq stack, but not the
    order which is needed by __get_free_pages().
    We can use get_order() to calculate the accurate order.
    
    Signed-off-by: Liu Xiang <liu.xiang6@zte.com.cn>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Fixes: fe8bd18ffea5 ("MIPS: Introduce irq_stack")
    Cc: linux-mips@vger.kernel.org
    Cc: stable@vger.kernel.org # v4.11+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3001a9c2d9349cd4eef5043126a55a5365719034
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Wed Jan 9 16:05:10 2019 -0600

    applicom: Fix potential Spectre v1 vulnerabilities
    
    commit d7ac3c6ef5d8ce14b6381d52eb7adafdd6c8bb3c upstream.
    
    IndexCard is indirectly controlled by user-space, hence leading to
    a potential exploitation of the Spectre variant 1 vulnerability.
    
    This issue was detected with the help of Smatch:
    
    drivers/char/applicom.c:418 ac_write() warn: potential spectre issue 'apbs' [r]
    drivers/char/applicom.c:728 ac_ioctl() warn: potential spectre issue 'apbs' [r] (local cap)
    
    Fix this by sanitizing IndexCard before using it to index apbs.
    
    Notice that given that speculation windows are large, the policy is
    to kill the speculation on the first load and not worry if it can be
    completed with a dependent load/store [1].
    
    [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff24d867b9dea6b4e9c40bf5a0bddf1c6d60fbb8
Author: Jiaxun Yang <jiaxun.yang@flygoat.com>
Date:   Tue Nov 20 11:00:18 2018 +0800

    x86/CPU/AMD: Set the CPB bit unconditionally on F17h
    
    commit 0237199186e7a4aa5310741f0a6498a20c820fd7 upstream.
    
    Some F17h models do not have CPB set in CPUID even though the CPU
    supports it. Set the feature bit unconditionally on all F17h.
    
     [ bp: Rewrite commit message and patch. ]
    
    Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Sherry Hurwitz <sherry.hurwitz@amd.com>
    Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: x86-ml <x86@kernel.org>
    Link: https://lkml.kernel.org/r/20181120030018.5185-1-jiaxun.yang@flygoat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8381e961d9bd831f2274d4e13834b40671c0e41
Author: Rajasingh Thavamani <T.Rajasingh@landisgyr.com>
Date:   Wed Feb 27 17:43:19 2019 +0530

    net: phy: Micrel KSZ8061: link failure after cable connect
    
    [ Upstream commit 232ba3a51cc224b339c7114888ed7f0d4d95695e ]
    
    With Micrel KSZ8061 PHY, the link may occasionally not come up after
    Ethernet cable connect. The vendor's (Microchip, former Micrel) errata
    sheet 80000688A.pdf descripes the problem and possible workarounds in
    detail, see below.
    The batch implements workaround 1, which permanently fixes the issue.
    
    DESCRIPTION
    Link-up may not occur properly when the Ethernet cable is initially
    connected. This issue occurs more commonly when the cable is connected
    slowly, but it may occur any time a cable is connected. This issue occurs
    in the auto-negotiation circuit, and will not occur if auto-negotiation
    is disabled (which requires that the two link partners be set to the
    same speed and duplex).
    
    END USER IMPLICATIONS
    When this issue occurs, link is not established. Subsequent cable
    plug/unplaug cycle will not correct the issue.
    
    WORk AROUND
    There are four approaches to work around this issue:
    1. This issue can be prevented by setting bit 15 in MMD device address 1,
       register 2, prior to connecting the cable or prior to setting the
       Restart Auto-negotiation bit in register 0h. The MMD registers are
       accessed via the indirect access registers Dh and Eh, or via the Micrel
       EthUtil utility as shown here:
       . if using the EthUtil utility (usually with a Micrel KSZ8061
         Evaluation Board), type the following commands:
         > address 1
         > mmd 1
         > iw 2 b61a
       . Alternatively, write the following registers to write to the
         indirect MMD register:
         Write register Dh, data 0001h
         Write register Eh, data 0002h
         Write register Dh, data 4001h
         Write register Eh, data B61Ah
    2. The issue can be avoided by disabling auto-negotiation in the KSZ8061,
       either by the strapping option, or by clearing bit 12 in register 0h.
       Care must be taken to ensure that the KSZ8061 and the link partner
       will link with the same speed and duplex. Note that the KSZ8061
       defaults to full-duplex when auto-negotiation is off, but other
       devices may default to half-duplex in the event of failed
       auto-negotiation.
    3. The issue can be avoided by connecting the cable prior to powering-up
       or resetting the KSZ8061, and leaving it plugged in thereafter.
    4. If the above measures are not taken and the problem occurs, link can
       be recovered by setting the Restart Auto-Negotiation bit in
       register 0h, or by resetting or power cycling the device. Reset may
       be either hardware reset or software reset (register 0h, bit 15).
    
    PLAN
    This errata will not be corrected in the future revision.
    
    Fixes: 7ab59dc15e2f ("drivers/net/phy/micrel_phy: Add support for new PHYs")
    Signed-off-by: Alexander Onnasch <alexander.onnasch@landisgyr.com>
    Signed-off-by: Rajasingh Thavamani <T.Rajasingh@landisgyr.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dca7cd43ce0933d8c787cb099ba7d706ea9dce9f
Author: Timur Celik <mail@timurcelik.de>
Date:   Mon Feb 25 21:13:13 2019 +0100

    tun: remove unnecessary memory barrier
    
    [ Upstream commit ecef67cb10db7b83b3b71c61dbb29aa070ab0112 ]
    
    Replace set_current_state with __set_current_state since no memory
    barrier is needed at this point.
    
    Signed-off-by: Timur Celik <mail@timurcelik.de>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 689b5a2970b8e09621acb693dcaa762c0330cd1e
Author: Timur Celik <mail@timurcelik.de>
Date:   Sat Feb 23 12:53:13 2019 +0100

    tun: fix blocking read
    
    [ Upstream commit 71828b2240692cec0e68b8d867bc00e1745e7fae ]
    
    This patch moves setting of the current state into the loop. Otherwise
    the task may end up in a busy wait loop if none of the break conditions
    are met.
    
    Signed-off-by: Timur Celik <mail@timurcelik.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b448977879f7b25f5171de3b58755658f92f1ae
Author: Nazarov Sergey <s-nazarov@yandex.ru>
Date:   Mon Feb 25 19:27:15 2019 +0300

    net: avoid use IPCB in cipso_v4_error
    
    [ Upstream commit 3da1ed7ac398f34fff1694017a07054d69c5f5c5 ]
    
    Extract IP options in cipso_v4_error and use __icmp_send.
    
    Signed-off-by: Sergey Nazarov <s-nazarov@yandex.ru>
    Acked-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55ea53a854c0c580c4cd1fffe1984987e04eb045
Author: Nazarov Sergey <s-nazarov@yandex.ru>
Date:   Mon Feb 25 19:24:15 2019 +0300

    net: Add __icmp_send helper.
    
    [ Upstream commit 9ef6b42ad6fd7929dd1b6092cb02014e382c6a91 ]
    
    Add __icmp_send function having ip_options struct parameter
    
    Signed-off-by: Sergey Nazarov <s-nazarov@yandex.ru>
    Reviewed-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07745894ea6f8242ef4fe32aa836ee77222e7688
Author: Igor Druzhinin <igor.druzhinin@citrix.com>
Date:   Thu Feb 28 12:48:03 2019 +0000

    xen-netback: fix occasional leak of grant ref mappings under memory pressure
    
    [ Upstream commit 99e87f56b48f490fb16b6e0f74691c1e664dea95 ]
    
    Zero-copy callback flag is not yet set on frag list skb at the moment
    xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
    leaking grant ref mappings since xenvif_zerocopy_callback() is never
    called for these fragments. Those eventually build up and cause Xen
    to kill Dom0 as the slots get reused for new mappings:
    
    "d0v0 Attempt to implicitly unmap a granted PTE c010000329fce005"
    
    That behavior is observed under certain workloads where sudden spikes
    of page cache writes coexist with active atomic skb allocations from
    network traffic. Additionally, rework the logic to deal with frag_list
    deallocation in a single place.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
    Acked-by: Wei Liu <wei.liu2@citrix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e6b3933008c5d48995e89f75974da848f5ec4b4
Author: Igor Druzhinin <igor.druzhinin@citrix.com>
Date:   Thu Feb 28 14:11:26 2019 +0000

    xen-netback: don't populate the hash cache on XenBus disconnect
    
    [ Upstream commit a2288d4e355992d369c50c45d017a85f6061ff71 ]
    
    Occasionally, during the disconnection procedure on XenBus which
    includes hash cache deinitialization there might be some packets
    still in-flight on other processors. Handling of these packets includes
    hashing and hash cache population that finally results in hash cache
    data structure corruption.
    
    In order to avoid this we prevent hashing of those packets if there
    are no queues initialized. In that case RCU protection of queues guards
    the hash cache as well.
    
    Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
    Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 375d6d454a95ebacb9c6eb0b715da05a4458ffef
Author: Mao Wenan <maowenan@huawei.com>
Date:   Fri Mar 1 23:06:40 2019 +0800

    net: sit: fix memory leak in sit_init_net()
    
    [ Upstream commit 07f12b26e21ab359261bf75cfcb424fdc7daeb6d ]
    
    If register_netdev() is failed to register sitn->fb_tunnel_dev,
    it will go to err_reg_dev and forget to free netdev(sitn->fb_tunnel_dev).
    
    BUG: memory leak
    unreferenced object 0xffff888378daad00 (size 512):
      comm "syz-executor.1", pid 4006, jiffies 4295121142 (age 16.115s)
      hex dump (first 32 bytes):
        00 e6 ed c0 83 88 ff ff 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    backtrace:
        [<00000000d6dcb63e>] kvmalloc include/linux/mm.h:577 [inline]
        [<00000000d6dcb63e>] kvzalloc include/linux/mm.h:585 [inline]
        [<00000000d6dcb63e>] netif_alloc_netdev_queues net/core/dev.c:8380 [inline]
        [<00000000d6dcb63e>] alloc_netdev_mqs+0x600/0xcc0 net/core/dev.c:8970
        [<00000000867e172f>] sit_init_net+0x295/0xa40 net/ipv6/sit.c:1848
        [<00000000871019fa>] ops_init+0xad/0x3e0 net/core/net_namespace.c:129
        [<00000000319507f6>] setup_net+0x2ba/0x690 net/core/net_namespace.c:314
        [<0000000087db4f96>] copy_net_ns+0x1dc/0x330 net/core/net_namespace.c:437
        [<0000000057efc651>] create_new_namespaces+0x382/0x730 kernel/nsproxy.c:107
        [<00000000676f83de>] copy_namespaces+0x2ed/0x3d0 kernel/nsproxy.c:165
        [<0000000030b74bac>] copy_process.part.27+0x231e/0x6db0 kernel/fork.c:1919
        [<00000000fff78746>] copy_process kernel/fork.c:1713 [inline]
        [<00000000fff78746>] _do_fork+0x1bc/0xe90 kernel/fork.c:2224
        [<000000001c2e0d1c>] do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
        [<00000000ec48bd44>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
        [<0000000039acff8a>] 0xffffffffffffffff
    
    Signed-off-by: Mao Wenan <maowenan@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05d3d2d0b8574d0f61d12a64e2c6475a5c3d5ba6
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Fri Feb 22 15:37:58 2019 +0800

    net: nfc: Fix NULL dereference on nfc_llcp_build_tlv fails
    
    [ Upstream commit 58bdd544e2933a21a51eecf17c3f5f94038261b5 ]
    
    KASAN report this:
    
    BUG: KASAN: null-ptr-deref in nfc_llcp_build_gb+0x37f/0x540 [nfc]
    Read of size 3 at addr 0000000000000000 by task syz-executor.0/5401
    
    CPU: 0 PID: 5401 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0xfa/0x1ce lib/dump_stack.c:113
     kasan_report+0x171/0x18d mm/kasan/report.c:321
     memcpy+0x1f/0x50 mm/kasan/common.c:130
     nfc_llcp_build_gb+0x37f/0x540 [nfc]
     nfc_llcp_register_device+0x6eb/0xb50 [nfc]
     nfc_register_device+0x50/0x1d0 [nfc]
     nfcsim_device_new+0x394/0x67d [nfcsim]
     ? 0xffffffffc1080000
     nfcsim_init+0x6b/0x1000 [nfcsim]
     do_one_initcall+0xfa/0x5ca init/main.c:887
     do_init_module+0x204/0x5f6 kernel/module.c:3460
     load_module+0x66b2/0x8570 kernel/module.c:3808
     __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
     do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x462e99
    Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f9cb79dcc58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
    RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
    RDX: 0000000000000000 RSI: 0000000020000280 RDI: 0000000000000003
    RBP: 00007f9cb79dcc70 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9cb79dd6bc
    R13: 00000000004bcefb R14: 00000000006f7030 R15: 0000000000000004
    
    nfc_llcp_build_tlv will return NULL on fails, caller should check it,
    otherwise will trigger a NULL dereference.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: eda21f16a5ed ("NFC: Set MIU and RW values from CONNECT and CC LLCP frames")
    Fixes: d646960f7986 ("NFC: Initial LLCP support")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 009510a90e230bb495f3fe25c7db956679263b07
Author: Sheng Lan <lansheng@huawei.com>
Date:   Thu Feb 28 18:47:58 2019 +0800

    net: netem: fix skb length BUG_ON in __skb_to_sgvec
    
    [ Upstream commit 5845f706388a4cde0f6b80f9e5d33527e942b7d9 ]
    
    It can be reproduced by following steps:
    1. virtio_net NIC is configured with gso/tso on
    2. configure nginx as http server with an index file bigger than 1M bytes
    3. use tc netem to produce duplicate packets and delay:
       tc qdisc add dev eth0 root netem delay 100ms 10ms 30% duplicate 90%
    4. continually curl the nginx http server to get index file on client
    5. BUG_ON is seen quickly
    
    [10258690.371129] kernel BUG at net/core/skbuff.c:4028!
    [10258690.371748] invalid opcode: 0000 [#1] SMP PTI
    [10258690.372094] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G        W         5.0.0-rc6 #2
    [10258690.372094] RSP: 0018:ffffa05797b43da0 EFLAGS: 00010202
    [10258690.372094] RBP: 00000000000005ea R08: 0000000000000000 R09: 00000000000005ea
    [10258690.372094] R10: ffffa0579334d800 R11: 00000000000002c0 R12: 0000000000000002
    [10258690.372094] R13: 0000000000000000 R14: ffffa05793122900 R15: ffffa0578f7cb028
    [10258690.372094] FS:  0000000000000000(0000) GS:ffffa05797b40000(0000) knlGS:0000000000000000
    [10258690.372094] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [10258690.372094] CR2: 00007f1a6dc00868 CR3: 000000001000e000 CR4: 00000000000006e0
    [10258690.372094] Call Trace:
    [10258690.372094]  <IRQ>
    [10258690.372094]  skb_to_sgvec+0x11/0x40
    [10258690.372094]  start_xmit+0x38c/0x520 [virtio_net]
    [10258690.372094]  dev_hard_start_xmit+0x9b/0x200
    [10258690.372094]  sch_direct_xmit+0xff/0x260
    [10258690.372094]  __qdisc_run+0x15e/0x4e0
    [10258690.372094]  net_tx_action+0x137/0x210
    [10258690.372094]  __do_softirq+0xd6/0x2a9
    [10258690.372094]  irq_exit+0xde/0xf0
    [10258690.372094]  smp_apic_timer_interrupt+0x74/0x140
    [10258690.372094]  apic_timer_interrupt+0xf/0x20
    [10258690.372094]  </IRQ>
    
    In __skb_to_sgvec(), the skb->len is not equal to the sum of the skb's
    linear data size and nonlinear data size, thus BUG_ON triggered.
    Because the skb is cloned and a part of nonlinear data is split off.
    
    Duplicate packet is cloned in netem_enqueue() and may be delayed
    some time in qdisc. When qdisc len reached the limit and returns
    NET_XMIT_DROP, the skb will be retransmit later in write queue.
    the skb will be fragmented by tso_fragment(), the limit size
    that depends on cwnd and mss decrease, the skb's nonlinear
    data will be split off. The length of the skb cloned by netem
    will not be updated. When we use virtio_net NIC and invoke skb_to_sgvec(),
    the BUG_ON trigger.
    
    To fix it, netem returns NET_XMIT_SUCCESS to upper stack
    when it clones a duplicate packet.
    
    Fixes: 35d889d1 ("sch_netem: fix skb leak in netem_enqueue()")
    Signed-off-by: Sheng Lan <lansheng@huawei.com>
    Reported-by: Qin Ji <jiqin.ji@huawei.com>
    Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c973f9c7cc2b3caae93192fdc8ecb3f0b4ac000
Author: Paul Moore <paul@paul-moore.com>
Date:   Mon Feb 25 19:06:06 2019 -0500

    netlabel: fix out-of-bounds memory accesses
    
    [ Upstream commit 5578de4834fe0f2a34fedc7374be691443396d1f ]
    
    There are two array out-of-bounds memory accesses, one in
    cipso_v4_map_lvl_valid(), the other in netlbl_bitmap_walk().  Both
    errors are embarassingly simple, and the fixes are straightforward.
    
    As a FYI for anyone backporting this patch to kernels prior to v4.8,
    you'll want to apply the netlbl_bitmap_walk() patch to
    cipso_v4_bitmap_walk() as netlbl_bitmap_walk() doesn't exist before
    Linux v4.8.
    
    Reported-by: Jann Horn <jannh@google.com>
    Fixes: 446fda4f2682 ("[NetLabel]: CIPSOv4 engine")
    Fixes: 3faa8f982f95 ("netlabel: Move bitmap manipulation functions to the NetLabel core.")
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23e34d11b000be877d4cd3df00f03894791542d4
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Thu Feb 28 18:14:03 2019 +0100

    net: dsa: mv88e6xxx: Fix u64 statistics
    
    [ Upstream commit 6e46e2d821bb22b285ae8187959096b65d063b0d ]
    
    The switch maintains u64 counters for the number of octets sent and
    received. These are kept as two u32's which need to be combined.  Fix
    the combing, which wrongly worked on u16's.
    
    Fixes: 80c4627b2719 ("dsa: mv88x6xxx: Refactor getting a single statistic")
    Reported-by: Chris Healy <Chris.Healy@zii.aero>
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc693a59689f1d790841ece7db9de8d6659a58a3
Author: Haiyang Zhang <haiyangz@microsoft.com>
Date:   Fri Feb 22 18:25:03 2019 +0000

    hv_netvsc: Fix IP header checksum for coalesced packets
    
    [ Upstream commit bf48648d650db1146b75b9bd358502431e86cf4f ]
    
    Incoming packets may have IP header checksum verified by the host.
    They may not have IP header checksum computed after coalescing.
    This patch re-compute the checksum when necessary, otherwise the
    packets may be dropped, because Linux network stack always checks it.
    
    Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64a458de60e06900429155fa9c9db4154264829d
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Wed Feb 27 03:58:53 2019 -0500

    bnxt_en: Drop oversize TX packets to prevent errors.
    
    [ Upstream commit 2b3c6885386020b1b9d92d45e8349637e27d1f66 ]
    
    There have been reports of oversize UDP packets being sent to the
    driver to be transmitted, causing error conditions.  The issue is
    likely caused by the dst of the SKB switching between 'lo' with
    64K MTU and the hardware device with a smaller MTU.  Patches are
    being proposed by Mahesh Bandewar <maheshb@google.com> to fix the
    issue.
    
    In the meantime, add a quick length check in the driver to prevent
    the error.  The driver uses the TX packet size as index to look up an
    array to setup the TX BD.  The array is large enough to support all MTU
    sizes supported by the driver.  The oversize TX packet causes the
    driver to index beyond the array and put garbage values into the
    TX BD.  Add a simple check to prevent this.
    
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b9adaf706c4341834fdf73bcb2bd5b27b1979fa
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Sun Mar 3 07:35:51 2019 +0000

    team: Free BPF filter when unregistering netdev
    
    [ Upstream commit 692c31bd4054212312396b1d303bffab2c5b93a7 ]
    
    When team is used in loadbalance mode a BPF filter can be used to
    provide a hash which will determine the Tx port.
    
    When the netdev is later unregistered the filter is not freed which
    results in memory leaks [1].
    
    Fix by freeing the program and the corresponding filter when
    unregistering the netdev.
    
    [1]
    unreferenced object 0xffff8881dbc47cc8 (size 16):
      comm "teamd", pid 3068, jiffies 4294997779 (age 438.247s)
      hex dump (first 16 bytes):
        a3 00 6b 6b 6b 6b 6b 6b 88 a5 82 e1 81 88 ff ff  ..kkkkkk........
      backtrace:
        [<000000008a3b47e3>] team_nl_cmd_options_set+0x88f/0x11b0
        [<00000000c4f4f27e>] genl_family_rcv_msg+0x78f/0x1080
        [<00000000610ef838>] genl_rcv_msg+0xca/0x170
        [<00000000a281df93>] netlink_rcv_skb+0x132/0x380
        [<000000004d9448a2>] genl_rcv+0x29/0x40
        [<000000000321b2f4>] netlink_unicast+0x4c0/0x690
        [<000000008c25dffb>] netlink_sendmsg+0x929/0xe10
        [<00000000068298c5>] sock_sendmsg+0xc8/0x110
        [<0000000082a61ff0>] ___sys_sendmsg+0x77a/0x8f0
        [<00000000663ae29d>] __sys_sendmsg+0xf7/0x250
        [<0000000027c5f11a>] do_syscall_64+0x14d/0x610
        [<000000006cfbc8d3>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
        [<00000000e23197e2>] 0xffffffffffffffff
    unreferenced object 0xffff8881e182a588 (size 2048):
      comm "teamd", pid 3068, jiffies 4294997780 (age 438.247s)
      hex dump (first 32 bytes):
        20 00 00 00 02 00 00 00 30 00 00 00 28 f0 ff ff   .......0...(...
        07 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00  ........(.......
      backtrace:
        [<000000002daf01fb>] lb_bpf_func_set+0x45c/0x6d0
        [<000000008a3b47e3>] team_nl_cmd_options_set+0x88f/0x11b0
        [<00000000c4f4f27e>] genl_family_rcv_msg+0x78f/0x1080
        [<00000000610ef838>] genl_rcv_msg+0xca/0x170
        [<00000000a281df93>] netlink_rcv_skb+0x132/0x380
        [<000000004d9448a2>] genl_rcv+0x29/0x40
        [<000000000321b2f4>] netlink_unicast+0x4c0/0x690
        [<000000008c25dffb>] netlink_sendmsg+0x929/0xe10
        [<00000000068298c5>] sock_sendmsg+0xc8/0x110
        [<0000000082a61ff0>] ___sys_sendmsg+0x77a/0x8f0
        [<00000000663ae29d>] __sys_sendmsg+0xf7/0x250
        [<0000000027c5f11a>] do_syscall_64+0x14d/0x610
        [<000000006cfbc8d3>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
        [<00000000e23197e2>] 0xffffffffffffffff
    
    Fixes: 01d7f30a9f96 ("team: add loadbalance mode")
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reported-by: Amit Cohen <amitc@mellanox.com>
    Acked-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b7e29ea049efb1f39ac262e34b4843329045f69
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Mon Mar 4 15:00:03 2019 +0800

    sky2: Disable MSI on Dell Inspiron 1545 and Gateway P-79
    
    [ Upstream commit b33b7cd6fd86478dd2890a9abeb6f036aa01fdf7 ]
    
    Some sky2 chips fire IRQ after S3, before the driver is fully resumed:
    [ 686.804877] do_IRQ: 1.37 No irq handler for vector
    
    This is likely a platform bug that device isn't fully quiesced during
    S3. Use MSI-X, maskable MSI or INTx can prevent this issue from
    happening.
    
    Since MSI-X and maskable MSI are not supported by this device, fallback
    to use INTx on affected platforms.
    
    BugLink: https://bugs.launchpad.net/bugs/1807259
    BugLink: https://bugs.launchpad.net/bugs/1809843
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d81778b842536c9437acb43138f3fc8520b1b12c
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Sat Mar 2 10:34:55 2019 +0800

    net-sysfs: Fix mem leak in netdev_register_kobject
    
    [ Upstream commit 895a5e96dbd6386c8e78e5b78e067dcc67b7f0ab ]
    
    syzkaller report this:
    BUG: memory leak
    unreferenced object 0xffff88837a71a500 (size 256):
      comm "syz-executor.2", pid 9770, jiffies 4297825125 (age 17.843s)
      hex dump (first 32 bytes):
        00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........
        ff ff ff ff ff ff ff ff 20 c0 ef 86 ff ff ff ff  ........ .......
      backtrace:
        [<00000000db12624b>] netdev_register_kobject+0x124/0x2e0 net/core/net-sysfs.c:1751
        [<00000000dc49a994>] register_netdevice+0xcc1/0x1270 net/core/dev.c:8516
        [<00000000e5f3fea0>] tun_set_iff drivers/net/tun.c:2649 [inline]
        [<00000000e5f3fea0>] __tun_chr_ioctl+0x2218/0x3d20 drivers/net/tun.c:2883
        [<000000001b8ac127>] vfs_ioctl fs/ioctl.c:46 [inline]
        [<000000001b8ac127>] do_vfs_ioctl+0x1a5/0x10e0 fs/ioctl.c:690
        [<0000000079b269f8>] ksys_ioctl+0x89/0xa0 fs/ioctl.c:705
        [<00000000de649beb>] __do_sys_ioctl fs/ioctl.c:712 [inline]
        [<00000000de649beb>] __se_sys_ioctl fs/ioctl.c:710 [inline]
        [<00000000de649beb>] __x64_sys_ioctl+0x74/0xb0 fs/ioctl.c:710
        [<000000007ebded1e>] do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
        [<00000000db315d36>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
        [<00000000115be9bb>] 0xffffffffffffffff
    
    It should call kset_unregister to free 'dev->queues_kset'
    in error path of register_queue_kobjects, otherwise will cause a mem leak.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: 1d24eb4815d1 ("xps: Transmit Packet Steering")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5a32e427ba87d9c772958280e6edbc86e8929ad
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Sun Mar 3 07:34:57 2019 +0000

    ip6mr: Do not call __IP6_INC_STATS() from preemptible context
    
    [ Upstream commit 87c11f1ddbbad38ad8bad47af133a8208985fbdf ]
    
    Similar to commit 44f49dd8b5a6 ("ipmr: fix possible race resulting from
    improper usage of IP_INC_STATS_BH() in preemptible context."), we cannot
    assume preemption is disabled when incrementing the counter and
    accessing a per-CPU variable.
    
    Preemption can be enabled when we add a route in process context that
    corresponds to packets stored in the unresolved queue, which are then
    forwarded using this route [1].
    
    Fix this by using IP6_INC_STATS() which takes care of disabling
    preemption on architectures where it is needed.
    
    [1]
    [  157.451447] BUG: using __this_cpu_add() in preemptible [00000000] code: smcrouted/2314
    [  157.460409] caller is ip6mr_forward2+0x73e/0x10e0
    [  157.460434] CPU: 3 PID: 2314 Comm: smcrouted Not tainted 5.0.0-rc7-custom-03635-g22f2712113f1 #1336
    [  157.460449] Hardware name: Mellanox Technologies Ltd. MSN2100-CB2FO/SA001017, BIOS 5.6.5 06/07/2016
    [  157.460461] Call Trace:
    [  157.460486]  dump_stack+0xf9/0x1be
    [  157.460553]  check_preemption_disabled+0x1d6/0x200
    [  157.460576]  ip6mr_forward2+0x73e/0x10e0
    [  157.460705]  ip6_mr_forward+0x9a0/0x1510
    [  157.460771]  ip6mr_mfc_add+0x16b3/0x1e00
    [  157.461155]  ip6_mroute_setsockopt+0x3cb/0x13c0
    [  157.461384]  do_ipv6_setsockopt.isra.8+0x348/0x4060
    [  157.462013]  ipv6_setsockopt+0x90/0x110
    [  157.462036]  rawv6_setsockopt+0x4a/0x120
    [  157.462058]  __sys_setsockopt+0x16b/0x340
    [  157.462198]  __x64_sys_setsockopt+0xbf/0x160
    [  157.462220]  do_syscall_64+0x14d/0x610
    [  157.462349]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Fixes: 0912ea38de61 ("[IPV6] MROUTE: Add stats in multicast routing module method ip6_mr_forward().")
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reported-by: Amit Cohen <amitc@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc5c173e7fab9ae711b1aa9bb5965e51e43f1737
Author: Qing Xia <saberlily.xia@hisilicon.com>
Date:   Fri Feb 1 14:59:46 2019 +0800

    staging: android: ion: fix sys heap pool's gfp_flags
    
    commit 9bcf065e28122588a6cbee08cf847826dacbb438 upstream.
    
    In the first loop, gfp_flags will be modified to high_order_gfp_flags,
    and there will be no chance to change back to low_order_gfp_flags.
    
    Fixes: e7f63771b60e ("ION: Sys_heap: Add cached pool to spead up cached buffer alloc")
    Signed-off-by: Qing Xia <saberlily.xia@hisilicon.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Jing Xia <jing.xia@unisoc.com>
    Reviewed-by: Yuming Han <yuming.han@unisoc.com>
    Reviewed-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
    Reviewed-by: Orson Zhai <orson.zhai@unisoc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5762d86d5b8c398bf929f26df3b149f0348779ff
Author: Ajay Singh <ajay.kathat@microchip.com>
Date:   Thu Feb 7 11:28:58 2019 +0000

    staging: wilc1000: fix to set correct value for 'vif_num'
    
    commit dda037057a572f5c82ac2499eb4e6fb17600ba3e upstream.
    
    Set correct value in '->vif_num' for the total number of interfaces and
    set '->idx' value using 'i'.
    
    Fixes: 735bb39ca3be ("staging: wilc1000: simplify vif[i]->ndev accesses")
    Fixes: 0e490657c721 ("staging: wilc1000: Fix problem with wrong vif index")
    Cc: <stable@vger.kernel.org>
    Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af742361d1e659504777b70f21b507f9baba07d0
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Feb 12 12:44:50 2019 -0600

    staging: comedi: ni_660x: fix missing break in switch statement
    
    commit 479826cc86118e0d87e5cefb3df5b748e0480924 upstream.
    
    Add missing break statement in order to prevent the code from falling
    through to the default case and return -EINVAL every time.
    
    This bug was found thanks to the ongoing efforts to enable
    -Wimplicit-fallthrough.
    
    Fixes: aa94f2888825 ("staging: comedi: ni_660x: tidy up ni_660x_set_pfi_routing()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47b002658f6cefb3db465910add7069b696935a0
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Mar 7 18:06:23 2019 +0100

    isdn: isdn_tty: fix build warning of strncpy
    
    Not upstream as isdn is long deleted.
    
    Fix up a strncpy build warning for isdn_tty_suspend() using strscpy.
    
    It's not like anyone uses this code anyway, and this gets rid of a build
    warnings so that we can see real warnings as they pop up over time.
    
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 675fd5a6814aade5ceb9f14e4eca9a3099fe922b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Mar 7 17:02:50 2019 +0100

    ncpfs: fix build warning of strncpy
    
    Not upstream as ncpfs is long deleted.
    
    Fix up two strncpy build warnings in ncp_get_charsets() by using strscpy
    and the max size of the array.
    
    It's not like anyone uses this code anyway, and this gets rid of two
    build warnings so that we can see real warnings as they pop up over
    time.
    
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c09b19974ee35c72699862719b6d6035945013f
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Fri Jan 25 12:53:07 2019 +0530

    cpufreq: Use struct kobj_attribute instead of struct global_attr
    
    commit 625c85a62cb7d3c79f6e16de3cfa972033658250 upstream.
    
    The cpufreq_global_kobject is created using kobject_create_and_add()
    helper, which assigns the kobj_type as dynamic_kobj_ktype and show/store
    routines are set to kobj_attr_show() and kobj_attr_store().
    
    These routines pass struct kobj_attribute as an argument to the
    show/store callbacks. But all the cpufreq files created using the
    cpufreq_global_kobject expect the argument to be of type struct
    attribute. Things work fine currently as no one accesses the "attr"
    argument. We may not see issues even if the argument is used, as struct
    kobj_attribute has struct attribute as its first element and so they
    will both get same address.
    
    But this is logically incorrect and we should rather use struct
    kobj_attribute instead of struct global_attr in the cpufreq core and
    drivers and the show/store callbacks should take struct kobj_attribute
    as argument instead.
    
    This bug is caught using CFI CLANG builds in android kernel which
    catches mismatch in function prototypes for such callbacks.
    
    Reported-by: Donghee Han <dh.han@samsung.com>
    Reported-by: Sangkyu Kim <skwith.kim@samsung.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f732a55e905a30766f86eec3ac2c6aa4965d939
Author: Mans Rullgard <mans@mansr.com>
Date:   Thu Feb 14 19:45:33 2019 +0000

    USB: serial: ftdi_sio: add ID for Hjelmslund Electronics USB485
    
    commit 8d7fa3d4ea3f0ca69554215e87411494e6346fdc upstream.
    
    This adds the USB ID of the Hjelmslund Electronics USB485 Iso stick.
    
    Signed-off-by: Mans Rullgard <mans@mansr.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4cec65e37d3b59c492359194a0f48ba7db7fea3d
Author: Ivan Mironov <mironov.ivan@gmail.com>
Date:   Wed Feb 6 21:14:13 2019 +0500

    USB: serial: cp210x: add ID for Ingenico 3070
    
    commit dd9d3d86b08d6a106830364879c42c78db85389c upstream.
    
    Here is how this device appears in kernel log:
    
            usb 3-1: new full-speed USB device number 18 using xhci_hcd
            usb 3-1: New USB device found, idVendor=0b00, idProduct=3070
            usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
            usb 3-1: Product: Ingenico 3070
            usb 3-1: Manufacturer: Silicon Labs
            usb 3-1: SerialNumber: 0001
    
    Apparently this is a POS terminal with embedded USB-to-Serial converter.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ivan Mironov <mironov.ivan@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 122ccdfbf7d3b521f999f7649616a9c8a24e2f3d
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Wed Feb 20 11:43:17 2019 +0100

    USB: serial: option: add Telit ME910 ECM composition
    
    commit 6431866b6707d27151be381252d6eef13025cfce upstream.
    
    This patch adds Telit ME910 family ECM composition 0x1102.
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>