commit 19c04ca5b239e6e2277a5b381d1e79482ab9bbc5
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Feb 25 11:05:56 2018 +0100

    Linux 4.9.84

commit 266da9f8d0e650d1d27e06b9cfdbc47e7ad820f4
Author: Kamil Konieczny <k.konieczny@partner.samsung.com>
Date:   Wed Feb 7 16:52:09 2018 +0100

    crypto: s5p-sss - Fix kernel Oops in AES-ECB mode
    
    commit c927b080c67e3e97193c81fc1d27f4251bf4e036 upstream.
    
    In AES-ECB mode crypt is done with key only, so any use of IV
    can cause kernel Oops. Use IV only in AES-CBC and AES-CTR.
    
    Signed-off-by: Kamil Konieczny <k.konieczny@partner.samsung.com>
    Reported-by: Anand Moon <linux.amoon@gmail.com>
    Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
    Tested-by: Anand Moon <linux.amoon@gmail.com>
    Cc: stable@vger.kernel.org # can be applied after commit 8f9702aad138
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04c776eecc6ddf37166cd30f4e9c50d19480b18f
Author: Jan Dakinevich <jan.dakinevich@gmail.com>
Date:   Fri Feb 23 11:42:18 2018 +0100

    KVM: nVMX: invvpid handling improvements
    
    commit bcdde302b8268ef7dbc4ddbdaffb5b44eafe9a1e upstream
    
     - Expose all invalidation types to the L1
    
     - Reject invvpid instruction, if L1 passed zero vpid value to single
       context invalidations
    
    Signed-off-by: Jan Dakinevich <jan.dakinevich@gmail.com>
    Tested-by: Ladi Prosek <lprosek@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    [jwang: port to 4.4]
    Signed-off-by: Jack Wang <jinpu.wang@profitbricks.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f157269c0607effa13c1478be96f1ebebad2a714
Author: Jan Dakinevich <jan.dakinevich@gmail.com>
Date:   Fri Feb 23 11:42:17 2018 +0100

    KVM: VMX: clean up declaration of VPID/EPT invalidation types
    
    commit 63f3ac48133a19110c8a3666028dbd9b1bf3dcb3 upstream
    
    - Remove VMX_EPT_EXTENT_INDIVIDUAL_ADDR, since there is no such type of
       EPT invalidation
    
     - Add missing VPID types names
    
    Signed-off-by: Jan Dakinevich <jan.dakinevich@gmail.com>
    Tested-by: Ladi Prosek <lprosek@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    [jwang: port to 4.4]
    Signed-off-by: Jack Wang <jinpu.wang@profitbricks.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afff83e6733b50803c26ac761bbc0926848939e9
Author: Wanpeng Li <wanpeng.li@hotmail.com>
Date:   Thu Sep 14 03:54:16 2017 -0700

    KVM: async_pf: Fix #DF due to inject "Page not Present" and "Page Ready" exceptions simultaneously
    
    commit 9a6e7c39810e4a8bc7fc95056cefb40583fe07ef upstream.
    
    qemu-system-x86-8600  [004] d..1  7205.687530: kvm_entry: vcpu 2
    qemu-system-x86-8600  [004] ....  7205.687532: kvm_exit: reason EXCEPTION_NMI rip 0xffffffffa921297d info ffffeb2c0e44e018 80000b0e
    qemu-system-x86-8600  [004] ....  7205.687532: kvm_page_fault: address ffffeb2c0e44e018 error_code 0
    qemu-system-x86-8600  [004] ....  7205.687620: kvm_try_async_get_page: gva = 0xffffeb2c0e44e018, gfn = 0x427e4e
    qemu-system-x86-8600  [004] .N..  7205.687628: kvm_async_pf_not_present: token 0x8b002 gva 0xffffeb2c0e44e018
        kworker/4:2-7814  [004] ....  7205.687655: kvm_async_pf_completed: gva 0xffffeb2c0e44e018 address 0x7fcc30c4e000
    qemu-system-x86-8600  [004] ....  7205.687703: kvm_async_pf_ready: token 0x8b002 gva 0xffffeb2c0e44e018
    qemu-system-x86-8600  [004] d..1  7205.687711: kvm_entry: vcpu 2
    
    After running some memory intensive workload in guest, I catch the kworker
    which completes the GUP too quickly, and queues an "Page Ready" #PF exception
    after the "Page not Present" exception before the next vmentry as the above
    trace which will result in #DF injected to guest.
    
    This patch fixes it by clearing the queue for "Page not Present" if "Page Ready"
    occurs before the next vmentry since the GUP has already got the required page
    and shadow page table has already been fixed by "Page Ready" handler.
    
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
    Fixes: 7c90705bf2a3 ("KVM: Inject asynchronous page fault into a PV guest if page is swapped out.")
    [Changed indentation and added clearing of injected. - Radim]
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    [port from upstream v4.14-rc1, Don't assign to kvm_queued_exception::injected or
     x86_exception::async_page_fault]
    Signed-off-by: Jack Wang <jinpu.wang@profitbricks.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1acf767c213a0be16a9e1bacb140dd5bf0bb644a
Author: Borislav Petkov <bp@suse.de>
Date:   Mon Feb 19 11:13:28 2018 +0100

    x86/microcode/AMD: Change load_microcode_amd()'s param to bool to fix preemptibility bug
    
    commit dac6ca243c4c49a9ca7507d3d66140ebfac8b04b upstream.
    
    With CONFIG_DEBUG_PREEMPT enabled, I get:
    
      BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
      caller is debug_smp_processor_id
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2+ #2
      Call Trace:
       dump_stack
       check_preemption_disabled
       debug_smp_processor_id
       save_microcode_in_initrd_amd
       ? microcode_init
       save_microcode_in_initrd
       ...
    
    because, well, it says it above, we're using smp_processor_id() in
    preemptible code.
    
    But passing the CPU number is not really needed. It is only used to
    determine whether we're on the BSP, and, if so, to save the microcode
    patch for early loading.
    
     [ We don't absolutely need to do it on the BSP but we do that
       customarily there. ]
    
    Instead, convert that function parameter to a boolean which denotes
    whether the patch should be saved or not, thereby avoiding the use of
    smp_processor_id() in preemptible code.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20170528200414.31305-1-bp@alien8.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [arnd: rebased to 4.9, after running into warning:
     arch/x86/kernel/cpu/microcode/amd.c:881:30: self-comparison always evaluates to true]
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 353727e3b4565aaf0eeff57278fac3e1d01547f8
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Feb 19 11:13:27 2018 +0100

    usb: phy: msm add regulator dependency
    
    On linux-4.4 and linux-4.9 we get a warning about an array that is
    never initialized when CONFIG_REGULATOR is disabled:
    
    drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_probe':
    drivers/usb/phy/phy-msm-usb.c:1911:14: error: 'regs[0].consumer' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      motg->vddcx = regs[0].consumer;
      ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
    drivers/usb/phy/phy-msm-usb.c:1912:14: error: 'regs[1].consumer' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      motg->v3p3  = regs[1].consumer;
      ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
    drivers/usb/phy/phy-msm-usb.c:1913:14: error: 'regs[2].consumer' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      motg->v1p8  = regs[2].consumer;
    
    This adds a Kconfig dependency for it. In newer kernels, the driver no
    longer exists, so this is only needed for stable kernels.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd2e662a75a319c3d10d23a9f218a04acb8ed210
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Feb 19 11:13:26 2018 +0100

    arm64: fix warning about swapper_pg_dir overflow
    
    commit 12f043ff2b28fa64c9123b454cbe30a8a9e1967e upstream.
    
    With 4 levels of 16KB pages, we get this warning about the fact that we are
    copying a whole page into an array that is declared as having only two pointers
    for the top level of the page table:
    
    arch/arm64/mm/mmu.c: In function 'paging_init':
    arch/arm64/mm/mmu.c:528:2: error: 'memcpy' writing 16384 bytes into a region of size 16 overflows the destination [-Werror=stringop-overflow=]
    
    This is harmless since we actually reserve a whole page in the definition of the
    array that comes from, and just the extern declaration is short. The pgdir
    is initialized to zero either way, so copying the actual entries here seems
    like the best solution.
    
    Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    [slightly adapted to apply on 4.9]
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7f3e605fca372a54cce63ee6f447fa25672337d
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Feb 19 11:13:25 2018 +0100

    idle: i7300: add PCI dependency
    
    GCC correctly points out an uninitialized variable use when CONFIG_PCI is disabled.
    
    drivers/idle/i7300_idle.c: In function 'i7300_idle_notifier':
    include/asm-generic/bug.h:119:5: error: 'got_ctl' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      if (unlikely(__ret_warn_once && !__warned)) {  \
         ^
    drivers/idle/i7300_idle.c:415:5: note: 'got_ctl' was declared here
      u8 got_ctl;
         ^~~~~~~
    
    The driver no longer exists in later kernels, so this patch only appplies to
    linux-4.9.y and earlier.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c30e6636ce101fd61331092c490b9d9c55b2d143
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Feb 19 11:13:24 2018 +0100

    spi: bcm-qspi: shut up warning about cfi header inclusion
    
    When CONFIG_MTD_CFI is disabled, we get a warning for this spi driver:
    
    include/linux/mtd/cfi.h:76:2: #warning No CONFIG_MTD_CFI_Ix selected. No NOR chip support can work. [-Werror=cpp]
    
    The problem here is a layering violation that was fixed in mainline kernels with
    a larger rework in commit 054e532f8f90 ("spi: bcm-qspi: Remove hardcoded settings
    and spi-nor.h dependency"). We can't really backport that to stable kernels, so
    this just adds a Kconfig dependency to make it either build cleanly or force it
    to be disabled.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 890c52ab3d2a7e19714f698d36e83ef8e1a8e1b3
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Feb 19 11:13:23 2018 +0100

    binfmt_elf: compat: avoid unused function warning
    
    When CONFIG_ELF_CORE is disabled, we get a harmless warning in the compat
    version of binfmt_elf:
    
    fs/compat_binfmt_elf.c:58:13: error: 'cputime_to_compat_timeval' defined but not used [-Werror=unused-function]
    
    This was addressed in mainline Linux as part of a larger rework with commit
    cd19c364b313 ("fs/binfmt: Convert obsolete cputime type to nsecs").
    
    For 4.9 and earlier, this just shuts up the warning by adding an #ifdef
    around the function definition.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fe751401360595346f375cabcb8c04a5aa2bf37
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Feb 19 11:13:22 2018 +0100

    arm64: sunxi: always enable reset controller
    
    commit 900a9020af7a023f9b64c919fddf8a7486108962 upstream.
    
    The sunxi clk driver causes a link error when the reset controller
    subsystem is disabled:
    
    drivers/clk/built-in.o: In function `sun4i_ve_clk_setup':
    :(.init.text+0xd040): undefined reference to `reset_controller_register'
    drivers/clk/built-in.o: In function `sun4i_a10_display_init':
    :(.init.text+0xe5e0): undefined reference to `reset_controller_register'
    drivers/clk/built-in.o: In function `sunxi_usb_clk_setup':
    :(.init.text+0x10074): undefined reference to `reset_controller_register'
    
    We already force it to be enabled on arm32 and some other arm64 platforms,
    but not on arm64/sunxi. This adds the respective Kconfig statements to
    also select it here.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    [arnd: manually rebased to 4.9]
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6429e2f183c9fcfb446a4e6595a8811956cbf4f5
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Feb 19 11:13:21 2018 +0100

    drm/i915: hide unused intel_panel_set_backlight function
    
    commit fd94d53e55bd487368dfee9f1af24da78b2bb582 upstream.
    
    Building i915 without backlight support results in a harmless warning
    for intel_panel_set_backlight:
    
    drivers/gpu/drm/i915/intel_panel.c:653:13: error: 'intel_panel_set_backlight' defined but not used [-Werror=unused-function]
    
    This moves it into the CONFIG_BACKLIGHT_CLASS_DEVICE section that
    its caller is in.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20171127151239.1813673-2-arnd@arndb.de
    [arnd: manually rebased to 4.9]
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef3af3465ab4ed02b0d3ca5243752d3ef1d98eda
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Feb 19 11:13:20 2018 +0100

    kasan: rework Kconfig settings
    
    commit e7c52b84fb18f08ce49b6067ae6285aca79084a8 upstream.
    
    We get a lot of very large stack frames using gcc-7.0.1 with the default
    -fsanitize-address-use-after-scope --param asan-stack=1 options, which can
    easily cause an overflow of the kernel stack, e.g.
    
      drivers/gpu/drm/i915/gvt/handlers.c:2434:1: warning: the frame size of 46176 bytes is larger than 3072 bytes
      drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame size of 23632 bytes is larger than 3072 bytes
      lib/atomic64_test.c:250:1: warning: the frame size of 11200 bytes is larger than 3072 bytes
      drivers/gpu/drm/i915/gvt/handlers.c:2621:1: warning: the frame size of 9208 bytes is larger than 3072 bytes
      drivers/media/dvb-frontends/stv090x.c:3431:1: warning: the frame size of 6816 bytes is larger than 3072 bytes
      fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger than 3072 bytes
    
    To reduce this risk, -fsanitize-address-use-after-scope is now split out
    into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack
    frames that are smaller than 2 kilobytes most of the time on x86_64.  An
    earlier version of this patch also prevented combining KASAN_EXTRA with
    KASAN_INLINE, but that is no longer necessary with gcc-7.0.1.
    
    All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y
    and CONFIG_KASAN_EXTRA=n have been merged by maintainers now, so we can
    bring back that default now.  KASAN_EXTRA=y still causes lots of
    warnings but now defaults to !COMPILE_TEST to disable it in
    allmodconfig, and it remains disabled in all other defconfigs since it
    is a new option.  I arbitrarily raise the warning limit for KASAN_EXTRA
    to 3072 to reduce the noise, but an allmodconfig kernel still has around
    50 warnings on gcc-7.
    
    I experimented a bit more with smaller stack frames and have another
    follow-up series that reduces the warning limit for 64-bit architectures
    to 1280 bytes (without CONFIG_KASAN).
    
    With earlier versions of this patch series, I also had patches to address
    the warnings we get with KASAN and/or KASAN_EXTRA, using a
    "noinline_if_stackbloat" annotation.
    
    That annotation now got replaced with a gcc-8 bugfix (see
    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715) and a workaround for
    older compilers, which means that KASAN_EXTRA is now just as bad as
    before and will lead to an instant stack overflow in a few extreme
    cases.
    
    This reverts parts of commit 3f181b4d8652 ("lib/Kconfig.debug: disable
    -Wframe-larger-than warnings with KASAN=y").  Two patches in linux-next
    should be merged first to avoid introducing warnings in an allmodconfig
    build:
      3cd890dbe2a4 ("media: dvb-frontends: fix i2c access helpers for KASAN")
      16c3ada89cff ("media: r820t: fix r820t_write_reg for KASAN")
    
    Do we really need to backport this?
    
    I think we do: without this patch, enabling KASAN will lead to
    unavoidable kernel stack overflow in certain device drivers when built
    with gcc-7 or higher on linux-4.10+ or any version that contains a
    backport of commit c5caf21ab0cf8.  Most people are probably still on
    older compilers, but it will get worse over time as they upgrade their
    distros.
    
    The warnings we get on kernels older than this should all be for code
    that uses dangerously large stack frames, though most of them do not
    cause an actual stack overflow by themselves.The asan-stack option was
    added in linux-4.0, and commit 3f181b4d8652 ("lib/Kconfig.debug:
    disable -Wframe-larger-than warnings with KASAN=y") effectively turned
    off the warning for allmodconfig kernels, so I would like to see this
    fix backported to any kernels later than 4.0.
    
    I have done dozens of fixes for individual functions with stack frames
    larger than 2048 bytes with asan-stack, and I plan to make sure that
    all those fixes make it into the stable kernels as well (most are
    already there).
    
    Part of the complication here is that asan-stack (from 4.0) was
    originally assumed to always require much larger stacks, but that
    turned out to be a combination of multiple gcc bugs that we have now
    worked around and fixed, but sanitize-address-use-after-scope (from
    v4.10) has a much higher inherent stack usage and also suffers from at
    least three other problems that we have analyzed but not yet fixed
    upstream, each of them makes the stack usage more severe than it should
    be.
    
    Link: http://lkml.kernel.org/r/20171221134744.2295529-1-arnd@arndb.de
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Andrey Konovalov <andreyknvl@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [arnd: rebase to v4.9; only re-enable warning]
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4f0069c647e94d8070fc6f6ae1d753d14684c14
Author: Tobias Regnery <tobias.regnery@gmail.com>
Date:   Mon Apr 24 12:05:42 2017 +0200

    clk: meson: gxbb: fix build error without RESET_CONTROLLER
    
    commit dbed87a9d3a857a86f602775b5845f5f6d9652b5 upstream.
    
    With CONFIG_RESET_CONTROLLER=n we see the following link error in the
    meson gxbb clk driver:
    
    drivers/built-in.o: In function 'gxbb_aoclkc_probe':
    drivers/clk/meson/gxbb-aoclk.c:161: undefined reference to 'devm_reset_controller_register'
    
    Fix this by selecting the reset controller subsystem.
    
    Fixes: f8c11f79912d ("clk: meson: Add GXBB AO Clock and Reset controller driver")
    Signed-off-by: Tobias Regnery <tobias.regnery@gmail.com>
    Acked-by: Neil Armstrong <narmstrong@baylibre.com>
    [narmstrong: Added fixes-by tag]
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04c64a88ceaf7f27da37a375de519fab1b6080fa
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jan 25 23:15:53 2017 +0100

    ISDN: eicon: reduce stack size of sig_ind function
    
    commit 27d807180ae0a9e50d90adf9b22573c21be904c2 upstream.
    
    I noticed that this function uses a lot of kernel stack when the
    "latent entropy" plugin is enabled:
    
    drivers/isdn/hardware/eicon/message.c: In function 'sig_ind':
    drivers/isdn/hardware/eicon/message.c:6113:1: error: the frame size of 1168 bytes is larger than 1152 bytes [-Werror=frame-larger-than=]
    
    We currently don't warn about this, as we raise the warning limit
    to 2048 bytes in mainline, but I'd like to lower that limit again
    in the future, and this function can easily be changed to be more
    efficient and avoid that warning, by making some of its local
    variables 'const'.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7cc1178e8ccf9a0816ebf8f82ec4a778d4ca68ac
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Feb 28 18:14:37 2017 -0300

    tw5864: use dev_warn instead of WARN to shut up warning
    
    commit 27430d19a91615245babaa9b216d0807636903a0 upstream.
    
    tw5864_frameinterval_get() only initializes its output when it successfully
    identifies the video standard in tw5864_input. We get a warning here because
    gcc can't always track the state if initialized warnings across a WARN()
    macro, and thinks it might get used incorrectly in tw5864_s_parm:
    
    media/pci/tw5864/tw5864-video.c: In function 'tw5864_s_parm':
    media/pci/tw5864/tw5864-video.c:816:38: error: 'time_base.numerator' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    media/pci/tw5864/tw5864-video.c:819:31: error: 'time_base.denominator' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    
    Using dev_warn() instead of WARN() avoids the __branch_check__() in
    unlikely and lets the compiler see that the initialization is correct.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 507baad9ffb8fc01985337a964e3c6530e9ad5ab
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jan 26 12:09:59 2016 -0200

    em28xx: only use mt9v011 if camera support is enabled
    
    commit 190b23b4eb997767afad186bd8c96badceabf39e upstream.
    
    In randconfig builds that select VIDEO_EM28XX_V4L2 and
    MEDIA_SUBDRV_AUTOSELECT, but not MEDIA_CAMERA_SUPPORT, we get
    a Kconfig warning:
    
     warning: (VIDEO_EM28XX_V4L2) selects VIDEO_MT9V011 which has unmet direct dependencies (MEDIA_SUPPORT && I2C && VIDEO_V4L2 && MEDIA_CAMERA_SUPPORT)
    
    This avoids the warning by making that 'select' conditional on
    MEDIA_CAMERA_SUPPORT. Alternatively we could mark EM28XX as
    'depends on MEDIA_CAMERA_SUPPORT', but it does not seem to
    have any real dependency on that itself.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25df0c385c5a856dd24c74cb74295ccb805fe93a
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jan 26 12:10:01 2016 -0200

    go7007: add MEDIA_CAMERA_SUPPORT dependency
    
    commit fa6317eedd6341f2144ed1097706d8c34f18b6e4 upstream.
    
    If MEDIA_SUBDRV_AUTOSELECT and VIDEO_GO7007 are both set, we
    automatically select VIDEO_OV7640, but that depends on MEDIA_CAMERA_SUPPORT,
    so we get a Kconfig warning if that is disabled:
    
    warning: (VIDEO_GO7007) selects VIDEO_OV7640 which has unmet direct dependencies (MEDIA_SUPPORT && I2C && VIDEO_V4L2 && MEDIA_CAMERA_SUPPORT)
    
    This adds another dependency so we don't accidentally select
    it when it is unavailable.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4e204f548a0577781f228f92b5fb879af5e32d5
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Feb 8 19:14:13 2017 -0200

    tc358743: fix register i2c_rd/wr functions
    
    commit 3538aa6ecfb2dd727a40f9ebbbf25a0c2afe6226 upstream.
    
    While testing with CONFIG_UBSAN, I got this warning:
    
    drivers/media/i2c/tc358743.c: In function 'tc358743_probe':
    drivers/media/i2c/tc358743.c:1930:1: error: the frame size of 2480 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
    
    The problem is that the i2c_rd8/wr8/rd16/... functions in this driver pass
    a pointer to a local variable into a common function, and each call to one
    of them adds another variable plus redzone to the stack.
    
    I also noticed that the way this is done is broken on big-endian machines,
    as we copy the registers in CPU byte order.
    
    To address both those problems, I'm adding two helper functions for reading
    a register of up to 32 bits with correct endianess and change all other
    functions to use that instead. Just to be sure we don't get the problem
    back with changed optimizations in gcc, I'm also marking the new functions
    as 'noinline', although my tests with gcc-7 don't require that.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bec83b2cfd92597bcbd928a78ca904f7de90908
Author: Jérémy Lefaure <jeremy.lefaure@lse.epita.fr>
Date:   Mon Dec 12 16:43:23 2016 -0800

    shmem: fix compilation warnings on unused functions
    
    commit f1f5929cd9715c1cdfe07a890f12ac7d2c5304ec upstream.
    
    Compiling shmem.c with SHMEM and TRANSAPRENT_HUGE_PAGECACHE enabled
    raises warnings on two unused functions when CONFIG_TMPFS and
    CONFIG_SYSFS are both disabled:
    
      mm/shmem.c:390:20: warning: `shmem_format_huge' defined but not used [-Wunused-function]
       static const char *shmem_format_huge(int huge)
                          ^~~~~~~~~~~~~~~~~
      mm/shmem.c:373:12: warning: `shmem_parse_huge' defined but not used [-Wunused-function]
       static int shmem_parse_huge(const char *str)
                   ^~~~~~~~~~~~~~~~
    
    A conditional compilation on tmpfs or sysfs removes the warnings.
    
    Link: http://lkml.kernel.org/r/20161118055749.11313-1-jeremy.lefaure@lse.epita.fr
    Signed-off-by: Jérémy Lefaure <jeremy.lefaure@lse.epita.fr>
    Acked-by: Hugh Dickins <hughd@google.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 703d672a63e1feeb6f86a17b8bd09ce37bb3a31a
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Oct 4 12:28:18 2017 +0200

    KVM: add X86_LOCAL_APIC dependency
    
    commit e42eef4ba38806b18c4a74f0c276fb2e0b548173 upstream.
    
    The rework of the posted interrupt handling broke building without
    support for the local APIC:
    
    ERROR: "boot_cpu_physical_apicid" [arch/x86/kvm/kvm-intel.ko] undefined!
    
    That configuration is probably not particularly useful anyway, so
    we can avoid the randconfig failures by adding a Kconfig dependency.
    
    Fixes: 8b306e2f3c41 ("KVM: VMX: avoid double list add with VT-d posted interrupts")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7c3e5db3a92a3c92b0acd63f39974cae0b6f35d
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Oct 26 15:55:02 2016 -0700

    Input: tca8418_keypad - hide gcc-4.9 -Wmaybe-uninitialized warning
    
    commit ea4348c8462a20e8b1b6455a7145d2b86f8a49b6 upstream.
    
    Older versions of gcc warn about the tca8418_irq_handler function
    as they can't keep track of the variable assignment inside of the
    loop when using the -Wmaybe-unintialized flag:
    
    drivers/input/keyboard/tca8418_keypad.c: In function ‘tca8418_irq_handler’:
    drivers/input/keyboard/tca8418_keypad.c:172:9: error: ‘reg’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
    drivers/input/keyboard/tca8418_keypad.c:165:5: note: ‘reg’ was declared here
    
    This is fixed in gcc-6, but it's possible to rearrange the code
    in a way that avoids the warning on older compilers as well.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit edba1c1f78748cc5c0195433346c8bd87ee75b29
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Oct 24 17:30:38 2016 +0200

    drm/nouveau: hide gcc-4.9 -Wmaybe-uninitialized
    
    commit b74c0a9969f25217a5e5bbcac56a11bee16718d3 upstream.
    
    gcc-4.9 notices that the validate_init() function returns unintialized
    data when called with a zero 'nr_buffers' argument, when called with the
    -Wmaybe-uninitialized flag:
    
    drivers/gpu/drm/nouveau/nouveau_gem.c: In function ‘validate_init.isra.6’:
    drivers/gpu/drm/nouveau/nouveau_gem.c:457:5: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
    
    However, the only caller of this function always passes a nonzero
    argument, and gcc-6 is clever enough to take this into account and
    not warn about it any more.
    
    Adding an explicit initialization to -EINVAL here is correct even if
    the caller changed, and it avoids the warning on gcc-4.9 as well.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-By: Karol Herbst <karolherbst@gmail.com>
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 282a7a472f597bd70b5a731524d448abf88fff2a
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Tue Sep 6 11:15:48 2016 +0200

    rbd: silence bogus -Wmaybe-uninitialized warning
    
    commit d4c2269b3d5d06a8ea434b1841fbcaec336ed396 upstream.
    
    drivers/block/rbd.c: In function ‘rbd_watch_cb’:
    drivers/block/rbd.c:3690:5: error: ‘struct_v’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
    drivers/block/rbd.c:3759:5: note: ‘struct_v’ was declared here
    
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2105905bc5831a4bf110de6c2c4479843aa78454
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Jul 21 22:47:18 2017 +0200

    drm: exynos: mark pm functions as __maybe_unused
    
    commit 7e1751001818209b214b8c3df0b3c91fae250ea2 upstream.
    
    The rework of the exynos DRM clock handling introduced
    warnings for configurations that have CONFIG_PM disabled:
    
    drivers/gpu/drm/exynos/exynos_hdmi.c:736:13: error: 'hdmi_clk_disable_gates' defined but not used [-Werror=unused-function]
     static void hdmi_clk_disable_gates(struct hdmi_context *hdata)
                 ^~~~~~~~~~~~~~~~~~~~~~
    drivers/gpu/drm/exynos/exynos_hdmi.c:717:12: error: 'hdmi_clk_enable_gates' defined but not used [-Werror=unused-function]
     static int hdmi_clk_enable_gates(struct hdmi_context *hdata)
    
    The problem is that the PM functions themselves are inside of
    an #ifdef, but some functions they call are not.
    
    This patch removes the #ifdef and instead marks the PM functions
    as __maybe_unused, which is a more reliable way to get it right.
    
    Link: https://patchwork.kernel.org/patch/8436281/
    Fixes: 9be7e9898444 ("drm/exynos/hdmi: clock code re-factoring")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 077463be4fd5ec4ea2eb2101074893498a152066
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Oct 4 12:27:00 2017 +0200

    security/keys: BIG_KEY requires CONFIG_CRYPTO
    
    commit 3cd18d1981731d5f74b8e437009124ac99905d14 upstream.
    
    The recent rework introduced a possible randconfig build failure
    when CONFIG_CRYPTO configured to only allow modules:
    
    security/keys/big_key.o: In function `big_key_crypt':
    big_key.c:(.text+0x29f): undefined reference to `crypto_aead_setkey'
    security/keys/big_key.o: In function `big_key_init':
    big_key.c:(.init.text+0x1a): undefined reference to `crypto_alloc_aead'
    big_key.c:(.init.text+0x45): undefined reference to `crypto_aead_setauthsize'
    big_key.c:(.init.text+0x77): undefined reference to `crypto_destroy_tfm'
    crypto/gcm.o: In function `gcm_hash_crypt_remain_continue':
    gcm.c:(.text+0x167): undefined reference to `crypto_ahash_finup'
    crypto/gcm.o: In function `crypto_gcm_exit_tfm':
    gcm.c:(.text+0x847): undefined reference to `crypto_destroy_tfm'
    
    When we 'select CRYPTO' like the other users, we always get a
    configuration that builds.
    
    Fixes: 428490e38b2e ("security/keys: rewrite all of big_key crypto")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee2f58b4d33710cbbcbc87e078b709320c10b1d9
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Oct 25 22:21:04 2016 +0200

    cw1200: fix bogus maybe-uninitialized warning
    
    commit 7fc1503c906f0fac62d3506a6e993e49fb996248 upstream.
    
    On x86, the cw1200 driver produces a rather silly warning about the
    possible use of the 'ret' variable without an initialization
    presumably after being confused by the architecture specific definition
    of WARN_ON:
    
    drivers/net/wireless/st/cw1200/wsm.c: In function ‘wsm_handle_rx’:
    drivers/net/wireless/st/cw1200/wsm.c:1457:9: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
    
    We have already checked that 'count' is larger than 0 here, so
    we know that 'ret' is initialized. Changing the 'for' loop
    into do/while also makes this clear to the compiler.
    
    Suggested-by: David Laight <David.Laight@ACULAB.COM>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 445e8f85d87d1a56982c3f9ccdce3faa6e091654
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Mar 23 16:06:13 2017 +0100

    reiserfs: avoid a -Wmaybe-uninitialized warning
    
    commit ab4949640d6674b617b314ad3c2c00353304bab9 upstream.
    
    The latest gcc-7.0.1 snapshot warns about an unintialized variable use:
    
    In file included from fs/reiserfs/lbalance.c:8:0:
    fs/reiserfs/lbalance.c: In function 'leaf_item_bottle.isra.3':
    fs/reiserfs/reiserfs.h:1279:13: error: '*((void *)&n_ih+8).v' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      v2->v = (v2->v & cpu_to_le64(15ULL << 60)) | cpu_to_le64(offset);
               ~~^~~
    fs/reiserfs/reiserfs.h:1279:13: error: '*((void *)&n_ih+8).v' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      v2->v = (v2->v & cpu_to_le64(15ULL << 60)) | cpu_to_le64(offset);
    
    This happens because the offset/type pair that is stored in
    ih.key.u.k_offset_v2 is actually uninitialized when we call
    set_le_ih_k_offset() and set_le_ih_k_type(). After we have called both,
    all data is correct, but the first of the two reads uninitialized data
    for the type field and writes it back before it gets overwritten.
    
    This works around the warning by initializing the k_offset_v2 through
    the slightly larger memcpy().
    
    [JK: Remove now unused define and make it obvious we initialize the key]
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37b440a995114c897f70426a2f36f673239fa96b
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jan 11 14:39:44 2017 +0100

    ALSA: hda/ca0132 - fix possible NULL pointer use
    
    commit 46a049dae771b95e77ac6c823330f4a60f600236 upstream.
    
    gcc-7 caught what it considers a NULL pointer dereference:
    
    sound/pci/hda/patch_ca0132.c: In function 'dspio_scp.constprop':
    sound/pci/hda/patch_ca0132.c:1487:4: error: argument 1 null where non-null expected [-Werror=nonnull]
    
    This is plausible from looking at the function, as we compare 'reply'
    to NULL earlier in it. I have not tried to analyze if there are constraints
    that make it impossible to hit the bug, but adding another NULL check in
    the end kills the warning and makes the function more robust.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e631a1aa0075930d107cd7ae0537825ec70ebd0b
Author: Kefeng Wang <wangkefeng.wang@huawei.com>
Date:   Thu Jan 26 11:19:55 2017 +0800

    arm64: Kconfig: select COMPAT_BINFMT_ELF only when BINFMT_ELF is set
    
    commit 2e449048a25eb75d48dff12882b93f26d130a1c6 upstream.
    
    Fix warning:
    "(COMPAT) selects COMPAT_BINFMT_ELF which has unmet direct dependencies
    (COMPAT && BINFMT_ELF)"
    
    Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0ecbd663fe6961c6ff181a211f090005858656f
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Mar 23 16:02:18 2017 +0100

    scsi: advansys: fix uninitialized data access
    
    commit 44a5b977128c0ffff0654392b40f4c2ce72a619b upstream.
    
    gcc-7.0.1 now warns about a previously unnoticed access of uninitialized
    struct members:
    
    drivers/scsi/advansys.c: In function 'AscMsgOutSDTR':
    drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
             ((ushort)s_buffer[i + 1] << 8) | s_buffer[i]);
                              ^
    drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+7)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    drivers/scsi/advansys.c:3860:26: error: '*((void *)&sdtr_buf+7)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    
    The code has existed in this exact form at least since v2.6.12, and the
    warning seems correct. This uses named initializers to ensure we
    initialize all members of the structure.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6215c811b3a8a5fef320588ac0193ea70574c8e6
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Mon Feb 13 15:52:28 2017 +0300

    x86/vm86: Fix unused variable warning if THP is disabled
    
    commit 3ba5b5ea7dc3a10ef50819b43a9f8de2705f4eec upstream.
    
    GCC complains about unused variable 'vma' in mark_screen_rdonly() if THP is
    disabled:
    
    arch/x86/kernel/vm86_32.c: In function ‘mark_screen_rdonly’:
    arch/x86/kernel/vm86_32.c:180:26: warning: unused variable ‘vma’
    [-Wunused-variable]
       struct vm_area_struct *vma = find_vma(mm, 0xA0000);
    
    That's silly. pmd_trans_huge() resolves to 0 when THP is disabled, so the
    whole block should be eliminated.
    
    Moving the variable declaration outside the if() block shuts GCC up.
    
    Reported-by: Jérémy Lefaure <jeremy.lefaure@lse.epita.fr>
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Tested-by: Borislav Petkov <bp@suse.de>
    Cc: Carlos O'Donell <carlos@redhat.com>
    Link: http://lkml.kernel.org/r/20170213125228.63645-1-kirill.shutemov@linux.intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb70b2a03c7c150b292ba2ba83afd31481b11fd6
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jul 19 14:53:05 2017 +0200

    x86/platform: Add PCI dependency for PUNIT_ATOM_DEBUG
    
    commit d689c64d189e43d782fec5649fb0afe303c5b3f9 upstream.
    
    The IOSF_MBI option requires PCI support, without it we get a harmless
    Kconfig warning when it gets selected by PUNIT_ATOM_DEBUG:
    
      warning: (X86_INTEL_LPSS && SND_SST_IPC_ACPI && MMC_SDHCI_ACPI && PUNIT_ATOM_DEBUG) selects IOSF_MBI which has unmet direct dependencies (PCI)
    
    This adds another dependency to avoid the warning.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20170719125310.2487451-8-arnd@arndb.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5d98b6400263309b9208a63ee3d273f730ef80f
Author: Jun Nie <jun.nie@linaro.org>
Date:   Tue Jan 10 17:23:40 2017 +0800

    dmaengine: zx: fix build warning
    
    commit 067fdeb2f391bfa071f741a2b3eb74b8ff3785cd upstream.
    
    Fix build warning that related to PAGE_SIZE. The maximum DMA
    length has nothing to do with PAGE_SIZE, just use a fix number
    for the definition.
    
    drivers/dma/zx_dma.c: In function 'zx_dma_prep_memcpy':
    drivers/dma/zx_dma.c:523:8: warning: division by zero [-Wdiv-by-zero]
    drivers/dma/zx_dma.c: In function 'zx_dma_prep_slave_sg':
    drivers/dma/zx_dma.c:567:11: warning: division by zero [-Wdiv-by-zero]
    
    Signed-off-by: Jun Nie <jun.nie@linaro.org>
    Tested-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb0519fb37e9c59e31393e5cf6c94d71261f25bd
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jul 19 14:53:04 2017 +0200

    x86: add MULTIUSER dependency for KVM
    
    commit c2ce3f5d89d57301e2756ac325fe2ebc33bfec30 upstream.
    
    KVM tries to select 'TASKSTATS', which had additional dependencies:
    
    warning: (KVM) selects TASKSTATS which has unmet direct dependencies (NET && MULTIUSER)
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3bdcbc647bd0cae4b28ef6c92eb068f0a1bb3eba
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Jul 21 18:16:28 2017 +0200

    thermal: fix INTEL_SOC_DTS_IOSF_CORE dependencies
    
    commit 68fd77cf8a4b045594231f07e5fc92e1a34c0a9e upstream.
    
    We get a Kconfig warning when selecting this without also enabling
    CONFIG_PCI:
    
    warning: (X86_INTEL_LPSS && INTEL_SOC_DTS_IOSF_CORE
    && SND_SST_IPC_ACPI && MMC_SDHCI_ACPI && PUNIT_ATOM_DEBUG)
    selects IOSF_MBI which has unmet direct dependencies (PCI)
    
    This adds a new depedency.
    
    Fixes: 3a2419f865a6 ("Thermal: Intel SoC: DTS thermal use common APIs")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fd22bcdaf62e83fa7f7af083bae83334856df65
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jul 19 14:53:03 2017 +0200

    x86/build: Silence the build with "make -s"
    
    commit d460131dd50599e0e9405d5f4ae02c27d529a44a upstream.
    
    Every kernel build on x86 will result in some output:
    
      Setup is 13084 bytes (padded to 13312 bytes).
      System is 4833 kB
      CRC 6d35fa35
      Kernel: arch/x86/boot/bzImage is ready  (#2)
    
    This shuts it up, so that 'make -s' is truely silent as long as
    everything works. Building without '-s' should produce unchanged
    output.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Matt Fleming <matt@codeblueprint.co.uk>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20170719125310.2487451-6-arnd@arndb.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afdfe5f58fe1ced6da222d7d058b4c522dc0ce05
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Wed Jan 18 22:16:55 2017 -0600

    tools build: Add tools tree support for 'make -s'
    
    commit e572d0887137acfc53f18175522964ec19d88175 upstream.
    
    When doing a kernel build with 'make -s', everything is silenced except
    the objtool build.  That's because the tools tree support for silent
    builds is some combination of missing and broken.
    
    Three changes are needed to fix it:
    
    - Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the
      tools Makefiles can see it.
    
    - tools/scripts/Makefile.include: fix the tools Makefiles' ability to
      recognize '-s'.  The MAKE_VERSION and MAKEFLAGS checks are copied from
      the top-level Makefile.  This silences the "DESCEND objtool" message.
    
    - tools/build/Makefile.build: add support to the tools Build files for
      recognizing '-s'.  Again the MAKE_VERSION and MAKEFLAGS checks are
      copied from the top-level Makefile.  This silences all the object
      compile/link messages.
    
    Reported-and-Tested-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Michal Marek <mmarek@suse.com>
    Link: http://lkml.kernel.org/r/e8967562ef640c3ae9a76da4ae0f4e47df737c34.1484799200.git.jpoimboe@redhat.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 826a83a2f94019e8b7dfc957448c156a06c98452
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jul 19 14:53:00 2017 +0200

    x86/fpu/math-emu: Fix possible uninitialized variable use
    
    commit 75e2f0a6b16141cb347f442033ec907380d4d66e upstream.
    
    When building the kernel with "make EXTRA_CFLAGS=...", this overrides
    the "PARANOID" preprocessor macro defined in arch/x86/math-emu/Makefile,
    and we run into a build warning:
    
      arch/x86/math-emu/reg_compare.c: In function ‘compare_i_st_st’:
      arch/x86/math-emu/reg_compare.c:254:6: error: ‘f’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
    
    This fixes the implementation to work correctly even without the PARANOID
    flag, and also fixes the Makefile to not use the EXTRA_CFLAGS variable
    but instead use the ccflags-y variable in the Makefile that is meant
    for this purpose.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Bill Metzenthen <billm@melbpc.org.au>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20170719125310.2487451-3-arnd@arndb.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e44ee5fc97657ef53b79118814f787449fbd6b8
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Mar 14 22:39:21 2017 +0100

    arm64: define BUG() instruction without CONFIG_BUG
    
    commit f13d52cb3fad03c237572be2ee691e1fe2d1d7bb upstream.
    
    This mirrors commit e9c38ceba8d9 ("ARM: 8455/1: define __BUG as
    asm(BUG_INSTR) without CONFIG_BUG") to make the behavior of
    arm64 consistent with arm and x86, and avoids lots of warnings in
    randconfig builds, such as:
    
    kernel/seccomp.c: In function '__seccomp_filter':
    kernel/seccomp.c:666:1: error: no return statement in function returning non-void [-Werror=return-type]
    
    Acked-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f47b68eabcf126cd1caec7fcbbb16e1ecc0f09c
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Feb 17 16:13:44 2017 +0100

    gpio: xgene: mark PM functions as __maybe_unused
    
    commit b115bebc07f282067eccc06fd5aa3060ab1426da upstream.
    
    When CONFIG_PM_SLEEP is disabled, we get a warning about unused functions:
    
    drivers/gpio/gpio-xgene.c:155:12: warning: 'xgene_gpio_resume' defined but not used [-Wunused-function]
     static int xgene_gpio_resume(struct device *dev)
                ^~~~~~~~~~~~~~~~~
    drivers/gpio/gpio-xgene.c:142:12: warning: 'xgene_gpio_suspend' defined but not used [-Wunused-function]
     static int xgene_gpio_suspend(struct device *dev)
    
    The warnings are harmless and can be avoided by simplifying the code and marking
    the functions as __maybe_unused.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10170a9abae7fbe34ddf2c0ecf230c30e21afc53
Author: Borislav Petkov <bp@suse.de>
Date:   Mon Jan 23 19:35:06 2017 +0100

    x86/ras/inject: Make it depend on X86_LOCAL_APIC=y
    
    commit d4b2ac63b0eae461fc10c9791084be24724ef57a upstream.
    
    ... and get rid of the annoying:
    
      arch/x86/kernel/cpu/mcheck/mce-inject.c:97:13: warning: ‘mce_irq_ipi’ defined but not used [-Wunused-function]
    
    when doing randconfig builds.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Yazen Ghannam <Yazen.Ghannam@amd.com>
    Cc: linux-edac <linux-edac@vger.kernel.org>
    Link: http://lkml.kernel.org/r/20170123183514.13356-2-bp@alien8.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 630e2b891cfdae9680a1a43597c05143d7c7ad88
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Oct 24 17:51:55 2016 +0200

    scsi: advansys: fix build warning for PCI=n
    
    commit f46e7cd36b5f2ce2bfb567e278a10ca717f85b84 upstream.
    
    The advansys probe function tries to handle both ISA and PCI cases, each
    hidden in an #ifdef when unused. This leads to a warning indicating that
    when PCI is disabled we could be using uninitialized data:
    
    drivers/scsi/advansys.c: In function  advansys_board_found :
    drivers/scsi/advansys.c:11036:5: error:  ret  may be used uninitialized in this function [-Werror=maybe-uninitialized]
    drivers/scsi/advansys.c:10928:28: note:  ret  was declared here
    drivers/scsi/advansys.c:11309:8: error:  share_irq  may be used uninitialized in this function [-Werror=maybe-uninitialized]
    drivers/scsi/advansys.c:10928:6: note:  share_irq  was declared here
    
    This cannot happen in practice because the hardware in question only
    exists for PCI, but changing the code to just error out here is better
    for consistency and avoids the warning.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d07cb5cc399651b6d0c172d699052bc2aac1fc1
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jun 14 12:40:36 2017 +0200

    video: fbdev: via: remove possibly unused variables
    
    commit 484c7bbf2649831714da3a0fa30213977458e9b5 upstream.
    
    When CONFIG_PROC_FS is disabled, we get warnings about unused variables
    as remove_proc_entry() evaluates to an empty macro.
    
    drivers/video/fbdev/via/viafbdev.c: In function 'viafb_remove_proc':
    drivers/video/fbdev/via/viafbdev.c:1635:4: error: unused variable 'iga2_entry' [-Werror=unused-variable]
    drivers/video/fbdev/via/viafbdev.c:1634:4: error: unused variable 'iga1_entry' [-Werror=unused-variable]
    
    These are easy to avoid by using the pointer from the structure.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 28fab4ff2e9c404e9720776e2d06c4d00980ed56
Author: Stephen Boyd <sboyd@codeaurora.org>
Date:   Wed Jan 25 15:46:58 2017 -0800

    perf: xgene: Include module.h
    
    commit c0bfc549e96231e0ead4424de6e4933fde819d70 upstream.
    
    I ran into a build error when I disabled CONFIG_ACPI and tried to
    compile this driver:
    
    drivers/perf/xgene_pmu.c:1242:1: warning: data definition has no type or storage class
     MODULE_DEVICE_TABLE(of, xgene_pmu_of_match);
     ^
    drivers/perf/xgene_pmu.c:1242:1: error: type defaults to 'int' in declaration of 'MODULE_DEVICE_TABLE' [-Werror=implicit-int]
    
    Include module.h for the MODULE_DEVICE_TABLE macro that's
    implicitly included through ACPI.
    
    Tested-by: Tai Nguyen <ttnguyen@apm.com>
    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4890abc7814be49a7d4e448c7b7421e1cea44ec1
Author: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
Date:   Tue Apr 18 14:21:04 2017 -0500

    PCI: Change pci_host_common_probe() visibility
    
    commit de5bbdd01cf9ee3cd4586b5a970d3ea015c6d7e3 upstream.
    
    pci_host_common_probe() is defined when CONFIG_PCI_HOST_COMMON=y;
    therefore the function declaration should match that.
    
      drivers/pci/host/pcie-tango.c:300:9: error:
            implicit declaration of function 'pci_host_common_probe'
    
    Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 157c02d2feaefd4eb8ae02ec37c7bd73d869f7d0
Author: Jérémy Lefaure <jeremy.lefaure@lse.epita.fr>
Date:   Tue Jan 3 18:13:49 2017 -0600

    usb: musb: fix compilation warning on unused function
    
    commit c8bd2ac3b4c6c84c4a7cdceaed626247db698ab2 upstream.
    
    The function musb_run_resume_work is called only when CONFIG_PM is
    enabled. So this function should not be defined when CONFIG_PM is
    disabled. Otherwise the compiler issues a warning:
    
    drivers/usb/musb/musb_core.c:2057:12: error: ‘musb_run_resume_work’ defined but
    not used [-Werror=unused-function]
     static int musb_run_resume_work(struct musb *musb)
                ^~~~~~~~~~~~~~~~~~~~
    
    Signed-off-by: Jérémy Lefaure <jeremy.lefaure@lse.epita.fr>
    Signed-off-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0d61d463d0de1c6ebc69bdb9bd9da01773c831f
Author: Borislav Petkov <bp@suse.de>
Date:   Sat Nov 26 17:01:51 2016 +0100

    platform/x86: intel_mid_thermal: Fix suspend handlers unused warning
    
    commit b4aca383f9afb5f84b05de272656e6d4a919d995 upstream.
    
    Fix:
    
      drivers/platform/x86/intel_mid_thermal.c:424:12: warning: ‘mid_thermal_resume’
      defined but not used [-Wunused-function]
       static int mid_thermal_resume(struct device *dev)
                  ^
      drivers/platform/x86/intel_mid_thermal.c:436:12: warning: ‘mid_thermal_suspend’
      defined but not used [-Wunused-function]
       static int mid_thermal_suspend(struct device *dev)
                  ^
    
    which I see during randbuilds here.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: Darren Hart <dvhart@infradead.org>
    Cc: platform-driver-x86@vger.kernel.org
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 092bddf5c848ca5f3a865846b372ae1a3ffd2f42
Author: Augusto Mecking Caringi <augustocaringi@gmail.com>
Date:   Mon Jan 16 14:30:41 2017 +0000

    gpio: intel-mid: Fix build warning when !CONFIG_PM
    
    commit fbc2a294f29e726787a0f5238b27137904f26b81 upstream.
    
    The only usage of function intel_gpio_runtime_idle() is here (in the
    same file):
    
    static const struct dev_pm_ops intel_gpio_pm_ops = {
            SET_RUNTIME_PM_OPS(NULL, NULL, intel_gpio_runtime_idle)
    };
    
    And when CONFIG_PM is not set, the macro SET_RUNTIME_PM_OPS expands to
    nothing, causing the following compiler warning:
    
    drivers/gpio/gpio-intel-mid.c:324:12: warning: ‘intel_gpio_runtime_idle’
    defined but not used [-Wunused-function]
    static int intel_gpio_runtime_idle(struct device *dev)
    
    Fix it by annotating the function with __maybe_unused.
    
    Signed-off-by: Augusto Mecking Caringi <augustocaringi@gmail.com>
    Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8947af550462c600d90cd672dad732a1575b9f36
Author: Borislav Petkov <bp@suse.de>
Date:   Sat Nov 26 19:29:57 2016 +0100

    PCI: vmd: Fix suspend handlers defined-but-not-used warning
    
    commit 42db500a551f97551a901e2258f84a60baf4edfc upstream.
    
    Fix the following warnings:
    
      drivers/pci/host/vmd.c:731:12: warning: ‘vmd_suspend’ defined but not used [-Wunused-function]
       static int vmd_suspend(struct device *dev)
                  ^
      drivers/pci/host/vmd.c:739:12: warning: ‘vmd_resume’ defined but not used [-Wunused-function]
       static int vmd_resume(struct device *dev)
                  ^
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
    Reviewed-by: Keith Busch <keith.busch@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e72c7a3b48db4b72abb201c3d85f68a3c41c9448
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jul 19 14:52:59 2017 +0200

    perf/x86: Shut up false-positive -Wmaybe-uninitialized warning
    
    commit 11d8b05855f3749bcb6c57e2c4052921b9605c77 upstream.
    
    The intialization function checks for various failure scenarios, but
    unfortunately the compiler gets a little confused about the possible
    combinations, leading to a false-positive build warning when
    -Wmaybe-uninitialized is set:
    
      arch/x86/events/core.c: In function ‘init_hw_perf_events’:
      arch/x86/events/core.c:264:3: warning: ‘reg_fail’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      arch/x86/events/core.c:264:3: warning: ‘val_fail’ may be used uninitialized in this function [-Wmaybe-uninitialized]
         pr_err(FW_BUG "the BIOS has corrupted hw-PMU resources (MSR %x is %Lx)\n",
    
    We can't actually run into this case, so this shuts up the warning
    by initializing the variables to a known-invalid state.
    
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20170719125310.2487451-2-arnd@arndb.de
    Link: https://patchwork.kernel.org/patch/9392595/
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad47e672e47e5a70d9c3750800c017503786598a
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Feb 17 16:08:30 2017 +0100

    vmxnet3: prevent building with 64K pages
    
    commit fbdf0e28d061708cf18ba0f8e0db5360dc9a15b9 upstream.
    
    I got a warning about broken code on ARM64 with 64K pages:
    
    drivers/net/vmxnet3/vmxnet3_drv.c: In function 'vmxnet3_rq_init':
    drivers/net/vmxnet3/vmxnet3_drv.c:1679:29: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
        rq->buf_info[0][i].len = PAGE_SIZE;
    
    'len' here is a 16-bit integer, so this clearly won't work. I don't think
    this driver is used much on anything other than x86, so there is no need
    to fix this properly and we can work around it with a Kconfig dependency
    to forbid known-broken configurations. qemu in theory supports it on
    other architectures too, but presumably only for compatibility with x86
    guests that also run on vmware.
    
    CONFIG_PAGE_SIZE_64KB is used on hexagon, mips, sh and tile, the other
    symbols are architecture-specific names for the same thing.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89b6f091e7d7d4724aadb489026f2a5b5044af5e
Author: Tobias Regnery <tobias.regnery@gmail.com>
Date:   Mon Mar 27 11:57:53 2017 +0200

    clk: sunxi-ng: fix build error without CONFIG_RESET_CONTROLLER
    
    commit aa01338c018469274848a973bcbd287ef341937c upstream.
    
    With CONFIG_RESET_CONTROLLER=n we get the following link error in the
    sunxi-ng clk driver:
    
    drivers/built-in.o: In function `sunxi_ccu_probe':
    mux-core.c:(.text+0x12fe68): undefined reference to 'reset_controller_register'
    mux-core.c:(.text+0x12fe68): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'reset_controller_register'
    
    Fix this by adding the appropriate select statement.
    
    Signed-off-by: Tobias Regnery <tobias.regnery@gmail.com>
    Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1dc6839336341d4091a3bc33379c32cdd4fc1139
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Dec 12 16:42:28 2016 -0800

    shmem: avoid maybe-uninitialized warning
    
    commit 23f919d4ad0eb325595f10f55be4301b2965d6d6 upstream.
    
    After enabling -Wmaybe-uninitialized warnings, we get a false-postive
    warning for shmem:
    
      mm/shmem.c: In function `shmem_getpage_gfp':
      include/linux/spinlock.h:332:21: error: `info' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    
    This can be easily avoided, since the correct 'info' pointer is known at
    the time we first enter the function, so we can simply move the
    initialization up.  Moving it before the first label avoids the warning
    and lets us remove two later initializations.
    
    Note that the function is so hard to read that it not only confuses the
    compiler, but also most readers and without this patch it could\ easily
    break if one of the 'goto's changed.
    
    Link: https://www.spinics.net/lists/kernel/msg2368133.html
    Link: http://lkml.kernel.org/r/20161024205725.786455-1-arnd@arndb.de
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Andreas Gruenbacher <agruenba@redhat.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 7af1c18c2736c9bf3b1fec23e83ff587454fdb24
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Nov 27 16:10:27 2017 +0100

    drm/i915: fix intel_backlight_device_register declaration
    
    commit ac29fc66855b79c2960c63a4a66952d5b721d698 upstream.
    
    The alternative intel_backlight_device_register() definition apparently
    never got used, but I have now run into a case of i915 being compiled
    without CONFIG_BACKLIGHT_CLASS_DEVICE, resulting in a number of
    identical warnings:
    
    drivers/gpu/drm/i915/intel_drv.h:1739:12: error: 'intel_backlight_device_register' defined but not used [-Werror=unused-function]
    
    This marks the function as 'inline', which was surely the original
    intention here.
    
    Fixes: 1ebaa0b9c2d4 ("drm/i915: Move backlight registration to connector registration")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20171127151239.1813673-1-arnd@arndb.de
    (cherry picked from commit 2de2d0b063b08becb2c67a2c338c44e37bdcffee)
    Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4cef78556df50c3f15dc0e98d92a3098971bde7
Author: LEROY Christophe <christophe.leroy@c-s.fr>
Date:   Fri Jan 26 17:09:59 2018 +0100

    crypto: talitos - fix Kernel Oops on hashing an empty file
    
    commit 87a81dce53b1ea61acaeefa5191a0376a2d1d721 upstream.
    
    Performing the hash of an empty file leads to a kernel Oops
    
    [   44.504600] Unable to handle kernel paging request for data at address 0x0000000c
    [   44.512819] Faulting instruction address: 0xc02d2be8
    [   44.524088] Oops: Kernel access of bad area, sig: 11 [#1]
    [   44.529171] BE PREEMPT CMPC885
    [   44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 4.15.0-rc8-00211-g3a968610b6ea #81
    [   44.540814] NIP:  c02d2be8 LR: c02d2984 CTR: 00000000
    [   44.545812] REGS: c6813c90 TRAP: 0300   Not tainted  (4.15.0-rc8-00211-g3a968610b6ea)
    [   44.554223] MSR:  00009032 <EE,ME,IR,DR,RI>  CR: 48222822  XER: 20000000
    [   44.560855] DAR: 0000000c DSISR: c0000000
    [   44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 00000001 00000001 00000001 00000000
    [   44.560855] GPR08: 0000004c 00000000 c000bfcc 00000000 28222822 100280d4 00000000 10020008
    [   44.560855] GPR16: 00000000 00000020 00000000 00000000 10024008 00000000 c646f9f0 c6179a10
    [   44.560855] GPR24: 00000000 00000001 c62f0018 c6179a10 00000000 c6367a30 c62f0000 c646f9c0
    [   44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700
    [   44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700
    [   44.608868] Call Trace:
    [   44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unreliable)
    [   44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210
    [   44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138
    [   44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84
    [   44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4
    [   44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38
    [   44.645530] Instruction dump:
    [   44.648465] 38c00001 7f63db78 4e800421 7c791b78 54690ffe 0f090000 80ff0190 2f870000
    [   44.656122] 40befe50 2f990001 409e0210 813f01bc <8129000c> b39e003a 7d29c214 913e003c
    
    This patch fixes that Oops by checking if src is NULL.
    
    Fixes: 6a1e8d14156d4 ("crypto: talitos - making mapping helpers more generic")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec0084d082137b73460303b39f4089970a213ad7
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Thu Feb 22 23:35:45 2018 +1100

    powerpc/64s: Improve RFI L1-D cache flush fallback
    
    commit bdcb1aefc5b3f7d0f1dc8b02673602bca2ff7a4b upstream.
    
    The fallback RFI flush is used when firmware does not provide a way
    to flush the cache. It's a "displacement flush" that evicts useful
    data by displacing it with an uninteresting buffer.
    
    The flush has to take care to work with implementation specific cache
    replacment policies, so the recipe has been in flux. The initial
    slow but conservative approach is to touch all lines of a congruence
    class, with dependencies between each load. It has since been
    determined that a linear pattern of loads without dependencies is
    sufficient, and is significantly faster.
    
    Measuring the speed of a null syscall with RFI fallback flush enabled
    gives the relative improvement:
    
    P8 - 1.83x
    P9 - 1.75x
    
    The flush also becomes simpler and more adaptable to different cache
    geometries.
    
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    [mpe: Backport to 4.9]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efe8bc07c47fff196bbc0822e249a27ae0574d24
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Thu Feb 22 23:35:44 2018 +1100

    powerpc/64s: Simple RFI macro conversions
    
    commit 222f20f140623ef6033491d0103ee0875fe87d35 upstream.
    
    This commit does simple conversions of rfi/rfid to the new macros that
    include the expected destination context. By simple we mean cases
    where there is a single well known destination context, and it's
    simply a matter of substituting the instruction for the appropriate
    macro.
    
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    [mpe: Backport to 4.9, use RFI_TO_KERNEL in idle_book3s.S]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3146a32b39cd78722869bca6e839b3c59155e012
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu Feb 22 23:35:43 2018 +1100

    powerpc/64s: Fix conversion of slb_miss_common to use RFI_TO_USER/KERNEL
    
    The back port of commit c7305645eb0c ("powerpc/64s: Convert
    slb_miss_common to use RFI_TO_USER/KERNEL") missed a hunk needed to
    restore cr6.
    
    Fixes: 48cc95d4e4d6 ("powerpc/64s: Convert slb_miss_common to use RFI_TO_USER/KERNEL")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e767d353299a9be2acaa0dd618fdedefff184546
Author: Jia-Ju Bai <baijiaju1990@163.com>
Date:   Tue Dec 12 16:49:52 2017 +0800

    hippi: Fix a Fix a possible sleep-in-atomic bug in rr_close
    
    
    [ Upstream commit 6e266610eb6553cfb7e7eb5d11914bd01509c406 ]
    
    The driver may sleep under a spinlock.
    The function call path is:
    rr_close (acquire the spinlock)
      free_irq --> may sleep
    
    To fix it, free_irq is moved to the place without holding the spinlock.
    
    This bug is found by my static analysis tool(DSAC) and checked by my code review.
    
    Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d295bb9993524119cdca6226dafa76a448a4c71b
Author: Jan Beulich <JBeulich@suse.com>
Date:   Tue Dec 12 03:18:11 2017 -0700

    xen: XEN_ACPI_PROCESSOR is Dom0-only
    
    
    [ Upstream commit c4f9d9cb2c29ff04c6b4bb09b72802d8aedfc7cb ]
    
    Add a respective dependency.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit debe057b1ff529ee958cfc9b77d1900c9c9d4411
Author: Pali Rohár <pali.rohar@gmail.com>
Date:   Thu Nov 2 21:25:24 2017 +0100

    platform/x86: dell-laptop: Fix keyboard max lighting for Dell Latitude E6410
    
    
    [ Upstream commit 68a213d325c23d39f109f4c7c824b906a7d209de ]
    
    This machine reports number of keyboard backlight led levels, instead of
    value of the last led level index. Therefore max_brightness properly needs
    to be subtracted by 1 to match led max_brightness API.
    
    Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
    Reported-by: Gabriel M. Elder <gabriel@tekgnowsys.com>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=196913
    Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f77841b74963effcc2087f520083efe6ff3e653
Author: Karol Herbst <kherbst@redhat.com>
Date:   Mon Nov 27 08:51:39 2017 +0100

    x86/mm/kmmio: Fix mmiotrace for page unaligned addresses
    
    
    [ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ]
    
    If something calls ioremap() with an address not aligned to PAGE_SIZE, the
    returned address might be not aligned as well. This led to a probe
    registered on exactly the returned address, but the entire page was armed
    for mmiotracing.
    
    On calling iounmap() the address passed to unregister_kmmio_probe() was
    PAGE_SIZE aligned by the caller leading to a complete freeze of the
    machine.
    
    We should always page align addresses while (un)registerung mappings,
    because the mmiotracer works on top of pages, not mappings. We still keep
    track of the probes based on their real addresses and lengths though,
    because the mmiotrace still needs to know what are mapped memory regions.
    
    Also move the call to mmiotrace_iounmap() prior page aligning the address,
    so that all probes are unregistered properly, otherwise the kernel ends up
    failing memory allocations randomly after disabling the mmiotracer.
    
    Tested-by: Lyude <lyude@redhat.com>
    Signed-off-by: Karol Herbst <kherbst@redhat.com>
    Acked-by: Pekka Paalanen <ppaalanen@gmail.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: nouveau@lists.freedesktop.org
    Link: http://lkml.kernel.org/r/20171127075139.4928-1-kherbst@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b5b4f6f553e47f0a675d60cbaf48445e27abd04
Author: Dave Young <dyoung@redhat.com>
Date:   Sat Dec 9 12:16:10 2017 +0800

    mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep
    
    
    [ Upstream commit 7f6f60a1ba52538c16f26930bfbcfe193d9d746a ]
    
    earlyprintk=efi,keep does not work any more with a warning
    in mm/early_ioremap.c: WARN_ON(system_state != SYSTEM_BOOTING):
    Boot just hangs because of the earlyprintk within the earlyprintk
    implementation code itself.
    
    This is caused by a new introduced middle state in:
    
      69a78ff226fe ("init: Introduce SYSTEM_SCHEDULING state")
    
    early_ioremap() is fine in both SYSTEM_BOOTING and SYSTEM_SCHEDULING
    states, original condition should be updated accordingly.
    
    Signed-off-by: Dave Young <dyoung@redhat.com>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: bp@suse.de
    Cc: linux-efi@vger.kernel.org
    Cc: linux-mm@kvack.org
    Link: http://lkml.kernel.org/r/20171209041610.GA3249@dhcp-128-65.nay.redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93c9e1c63ac6f5d87dc262dd268d735447b0abf9
Author: Andreas Platschek <andreas.platschek@opentech.at>
Date:   Thu Dec 7 11:32:20 2017 +0100

    usb: dwc3: of-simple: fix missing clk_disable_unprepare
    
    
    [ Upstream commit ded600ea9fb51a495d2fcd21e90351df876488e8 ]
    
    If of_clk_get() fails, the clean-up of already initialized clocks should be
    the same as when clk_prepare_enable() fails. Thus a clk_disable_unprepare()
    for each clock should be called before the clk_put().
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Fixes: 16adc674d0d6 ("usb: dwc3: ep0: fix setup_packet_pending initialization")
    
    Signed-off-by: Andreas Platschek <andreas.platschek@opentech.at>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d947e0d510a328d30c399c99a41be558e35a4390
Author: Vincent Pelletier <plr.vincent@gmail.com>
Date:   Thu Nov 30 15:31:06 2017 +0000

    usb: dwc3: gadget: Wait longer for controller to end command processing
    
    
    [ Upstream commit 8722e095f5a44d0e409e45c5ddc2ee9cf589c777 ]
    
    DWC3_DEPCMD_ENDTRANSFER has been witnessed to require around 600 iterations
    before controller would become idle again after unplugging the USB cable
    with AIO reads submitted.
    Bump timeout from 500 iterations to 1000 so dwc3_stop_active_transfer does
    not receive -ETIMEDOUT and does not WARN:
    
    [   81.326273] ------------[ cut here ]------------
    [   81.335341] WARNING: CPU: 0 PID: 1874 at drivers/usb/dwc3/gadget.c:2627 dwc3_stop_active_transfer.constprop.23+0x69/0xc0 [dwc3]
    [   81.347094] Modules linked in: usb_f_fs libcomposite configfs bnep btsdio bluetooth ecdh_generic brcmfmac brcmutil dwc3 intel_powerclamp coretemp ulpi kvm_intel udc_core kvm irqbypass crc32_pclmul crc32c_intel pcbc dwc3_pci aesni_intel aes_i586 crypto_simd cryptd ehci_pci ehci_hcd basincove_gpadc industrialio gpio_keys usbcore usb_common
    [   81.378142] CPU: 0 PID: 1874 Comm: irq/34-dwc3 Not tainted 4.14.0-edison+ #119
    [   81.385545] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48
    [   81.394548] task: f5b1be00 task.stack: f420a000
    [   81.399219] EIP: dwc3_stop_active_transfer.constprop.23+0x69/0xc0 [dwc3]
    [   81.406086] EFLAGS: 00010086 CPU: 0
    [   81.409672] EAX: 0000001f EBX: f5729800 ECX: c132a2a2 EDX: 00000000
    [   81.416096] ESI: f4054014 EDI: f41cf400 EBP: f420be10 ESP: f420bdf4
    [   81.422521]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
    [   81.428061] CR0: 80050033 CR2: b7a3f000 CR3: 01d94000 CR4: 001006d0
    [   81.434483] Call Trace:
    [   81.437063]  __dwc3_gadget_ep_disable+0xa3/0x2b0 [dwc3]
    [   81.442438]  ? _raw_spin_lock_irqsave+0x32/0x40
    [   81.447135]  dwc3_gadget_ep_disable+0xbf/0xe0 [dwc3]
    [   81.452269]  usb_ep_disable+0x1c/0xd0 [udc_core]
    [   81.457048]  ffs_func_eps_disable.isra.15+0x3b/0x90 [usb_f_fs]
    [   81.463070]  ffs_func_set_alt+0x7d/0x310 [usb_f_fs]
    [   81.468132]  ffs_func_disable+0x14/0x20 [usb_f_fs]
    [   81.473075]  reset_config+0x5b/0x90 [libcomposite]
    [   81.478023]  composite_disconnect+0x2b/0x50 [libcomposite]
    [   81.483685]  dwc3_disconnect_gadget+0x39/0x50 [dwc3]
    [   81.488808]  dwc3_gadget_disconnect_interrupt+0x21b/0x250 [dwc3]
    [   81.495014]  dwc3_thread_interrupt+0x2a8/0xf70 [dwc3]
    [   81.500219]  ? __schedule+0x78c/0x7e0
    [   81.504027]  irq_thread_fn+0x18/0x30
    [   81.507715]  ? irq_thread+0xb7/0x180
    [   81.511400]  irq_thread+0x111/0x180
    [   81.515000]  ? irq_finalize_oneshot+0xe0/0xe0
    [   81.519490]  ? wake_threads_waitq+0x30/0x30
    [   81.523806]  kthread+0x107/0x110
    [   81.527131]  ? disable_percpu_irq+0x50/0x50
    [   81.531439]  ? kthread_stop+0x150/0x150
    [   81.535397]  ret_from_fork+0x19/0x24
    [   81.539136] Code: 89 d8 c7 45 ec 00 00 00 00 c7 45 f0 00 00 00 00 c7 45 f4 00 00 00 00 e8 56 ef ff ff 85 c0 74 12 50 68 b9 1c 14 f8 e8 64 0f f7 c8 <0f> ff 58 5a 8d 76 00 8b 83 98 00 00 00 c6 83 a0 00 00 00 00 83
    [   81.559295] ---[ end trace f3133eec81a473b8 ]---
    
    Number of iterations measured on 4 consecutive unplugs:
    [ 1088.799777] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 605 times
    [ 1222.024986] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 580 times
    [ 1317.590452] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 598 times
    [ 1453.218314] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 594 times
    
    Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3e60306161cedda47cb961d27632c9b083aeb8e
Author: Tobias Jordan <Tobias.Jordan@elektrobit.com>
Date:   Wed Dec 6 14:28:27 2017 +0100

    dmaengine: jz4740: disable/unprepare clk if probe fails
    
    
    [ Upstream commit eb9436966fdc84cebdf222952a99898ab46d9bb0 ]
    
    in error path of jz4740_dma_probe(), call clk_disable_unprepare() to clean
    up.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Fixes: 25ce6c35fea0 MIPS: jz4740: Remove custom DMA API
    Signed-off-by: Tobias Jordan <Tobias.Jordan@elektrobit.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5dcc25c233b66c3446a2c249e1a4ed83118f2f0b
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Fri Dec 8 12:16:22 2017 +0000

    drm/armada: fix leak of crtc structure
    
    
    [ Upstream commit 33cd3c07a976e11c3c4cc6b0b3db6760ad1590c5 ]
    
    Fix the leak of the CRTC structure in the failure paths of
    armada_drm_crtc_create().
    
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a54c510014b3a1d24d6a2e13dbb6a2eacb5a46c
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Fri Dec 8 08:07:25 2017 +0100

    xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies.
    
    
    [ Upstream commit 732706afe1cc46ef48493b3d2b69c98f36314ae4 ]
    
    On policies with a transport mode template, we pass the addresses
    from the flowi to xfrm_state_find(), assuming that the IP addresses
    (and address family) don't change during transformation.
    
    Unfortunately our policy template validation is not strict enough.
    It is possible to configure policies with transport mode template
    where the address family of the template does not match the selectors
    address family. This lead to stack-out-of-bound reads because
    we compare arddesses of the wrong family. Fix this by refusing
    such a configuration, address family can not change on transport
    mode.
    
    We use the assumption that, on transport mode, the first templates
    address family must match the address family of the policy selector.
    Subsequent transport mode templates must mach the address family of
    the previous template.
    
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ae4f528030800598c91cd1e814997d6284ca2c1
Author: Takuo Koguchi <takuo.koguchi@gmail.com>
Date:   Thu Dec 7 16:20:14 2017 +0900

    spi: sun4i: disable clocks in the remove function
    
    
    [ Upstream commit c810daba0ab5226084a56893a789af427a801146 ]
    
    mclk and hclk need to be disabled. Since pm_runtime_disable does
    not disable the clocks, use pm_runtime_force_suspend instead.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Takuo Koguchi <takuo.koguchi.sw@hitachi.com>
    Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f99ff84b3654ab5fda483fee9a2b3d28ac8307b6
Author: Stefan Potyra <Stefan.Potyra@elektrobit.com>
Date:   Wed Dec 6 16:03:24 2017 +0100

    ASoC: rockchip: disable clock on error
    
    
    [ Upstream commit c7b92172a61b91936be985cb9bc499a4ebc6489b ]
    
    Disable the clocks in  rk_spdif_probe when an error occurs after one
    of the clocks has been enabled previously.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Fixes: f874b80e1571 ASoC: rockchip: Add rockchip SPDIF transceiver driver
    Signed-off-by: Stefan Potyra <Stefan.Potyra@elektrobit.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82acb5fc22ece01395dc01e51159c4544bb75297
Author: Cai Li <cai.li@spreadtrum.com>
Date:   Tue Nov 21 17:24:38 2017 +0800

    clk: fix a panic error caused by accessing NULL pointer
    
    
    [ Upstream commit 975b820b6836b6b6c42fb84cd2e772e2b41bca67 ]
    
    In some cases the clock parent would be set NULL when doing re-parent,
    it will cause a NULL pointer accessing if clk_set trace event is
    enabled.
    
    This patch sets the parent as "none" if the input parameter is NULL.
    
    Fixes: dfc202ead312 (clk: Add tracepoints for hardware operations)
    Signed-off-by: Cai Li <cai.li@spreadtrum.com>
    Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3250df9fa82bb8c25af7acfd5875d684b9995119
Author: Gustavo A. R. Silva <garsilva@embeddedor.com>
Date:   Mon Nov 20 08:28:14 2017 -0600

    dmaengine: at_hdmac: fix potential NULL pointer dereference in atc_prep_dma_interleaved
    
    
    [ Upstream commit 62a277d43d47e74972de44d33bd3763e31992414 ]
    
    _xt_ is being dereferenced before it is null checked, hence there is a
    potential null pointer dereference.
    
    Fix this by moving the pointer dereference after _xt_ has been null
    checked.
    
    This issue was detected with the help of Coccinelle.
    
    Fixes: 4483320e241c ("dmaengine: Use Pointer xt after NULL check.")
    Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3df69b4abe6cfd8efc8c3c187cff7f02aeff642
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Nov 17 22:37:53 2017 +0100

    dmaengine: ioat: Fix error handling path
    
    
    [ Upstream commit 5c9afbda911ce20b3f2181d1e440a0222e1027dd ]
    
    If the last test in 'ioat_dma_self_test()' fails, we must release all
    the allocated resources and not just part of them.
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ac3ffdb493fa80645c51030d6344a8bf7189197
Author: Claudiu Manoil <claudiu.manoil@nxp.com>
Date:   Thu Dec 7 18:44:23 2017 +0200

    gianfar: Disable EEE autoneg by default
    
    
    [ Upstream commit b6b5e8a691185606dfffff3198c89e3b4fd9d4f6 ]
    
    This controller does not support EEE, but it may connect to a PHY
    which supports EEE and advertises EEE by default, while its link
    partner also advertises EEE. If this happens, the PHY enters low
    power mode when the traffic rate is low and causes packet loss.
    This patch disables EEE advertisement by default for any PHY that
    gianfar connects to, to prevent the above unwanted outcome.
    
    Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
    Tested-by: Yangbo Lu <Yangbo.lu@nxp.com>
    Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d39838a5565984e9488775c0dff7dc95dd10994f
Author: Eric Biggers <ebiggers3@gmail.com>
Date:   Fri Dec 8 15:13:28 2017 +0000

    509: fix printing uninitialized stack memory when OID is empty
    
    
    [ Upstream commit 8dfd2f22d3bf3ab7714f7495ad5d897b8845e8c1 ]
    
    Callers of sprint_oid() do not check its return value before printing
    the result.  In the case where the OID is zero-length, -EBADMSG was
    being returned without anything being written to the buffer, resulting
    in uninitialized stack memory being printed.  Fix this by writing
    "(bad)" to the buffer in the cases where -EBADMSG is returned.
    
    Fixes: 4f73175d0375 ("X.509: Add utility functions to render OIDs as strings")
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 472a0d5bc8ec20eda9d1abe89b24acf6a8c78f04
Author: Branislav Radocaj <branislav@radocaj.org>
Date:   Thu Dec 7 00:07:38 2017 +0100

    net: ethernet: arc: fix error handling in emac_rockchip_probe
    
    
    [ Upstream commit e46772a6946a7d1f3fbbc1415871851d6651f1d4 ]
    
    If clk_set_rate() fails, we should disable clk before return.
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Branislav Radocaj <branislav@radocaj.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31d3d76094a1e07f21a89b4b30a41bae86c292e5
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Nov 23 17:57:04 2017 +0200

    brcmfmac: Avoid build error with make W=1
    
    
    [ Upstream commit 51ef7925e10688c57186d438e784532e063492e4 ]
    
    When I run make W=1 on gcc (Debian 7.2.0-16) 7.2.0 I got an error for
    the first run, all next ones are okay.
    
      CC [M]  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o
    drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union!
    scripts/Makefile.build:310: recipe for target 'drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o' failed
    
    Seems like something happened with W=1 and wrong kernel doc format.
    As a quick fix remove dubious /** in the code.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c3aae50cec79164955e920432a7aba748c1b09a
Author: Nikolay Borisov <nborisov@suse.com>
Date:   Fri Dec 1 11:19:42 2017 +0200

    btrfs: Fix possible off-by-one in btrfs_search_path_in_tree
    
    
    [ Upstream commit c8bcbfbd239ed60a6562964b58034ac8a25f4c31 ]
    
    The name char array passed to btrfs_search_path_in_tree is of size
    BTRFS_INO_LOOKUP_PATH_MAX (4080). So the actual accessible char indexes
    are in the range of [0, 4079]. Currently the code uses the define but this
    represents an off-by-one.
    
    Implications:
    
    Size of btrfs_ioctl_ino_lookup_args is 4096, so the new byte will be
    written to extra space, not some padding that could be provided by the
    allocator.
    
    btrfs-progs store the arguments on stack, but kernel does own copy of
    the ioctl buffer and the off-by-one overwrite does not affect userspace,
    but the ending 0 might be lost.
    
    Kernel ioctl buffer is allocated dynamically so we're overwriting
    somebody else's memory, and the ioctl is privileged if args.objectid is
    not 256. Which is in most cases, but resolving a subvolume stored in
    another directory will trigger that path.
    
    Before this patch the buffer was one byte larger, but then the -1 was
    not added.
    
    Fixes: ac8e9819d71f907 ("Btrfs: add search and inode lookup ioctls")
    Signed-off-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    [ added implications ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0514c0ba76a5a941ed3b8efa7a952273c1ca421
Author: Nogah Frankel <nogahf@mellanox.com>
Date:   Mon Dec 4 13:31:11 2017 +0200

    net_sched: red: Avoid illegal values
    
    
    [ Upstream commit 8afa10cbe281b10371fee5a87ab266e48d71a7f9 ]
    
    Check the qmin & qmax values doesn't overflow for the given Wlog value.
    Check that qmin <= qmax.
    
    Fixes: a783474591f2 ("[PKT_SCHED]: Generic RED layer")
    Signed-off-by: Nogah Frankel <nogahf@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c03903e973c276f9e75d6f7f3727b51b97c803b
Author: Nogah Frankel <nogahf@mellanox.com>
Date:   Mon Dec 4 13:31:10 2017 +0200

    net_sched: red: Avoid devision by zero
    
    
    [ Upstream commit 5c472203421ab4f928aa1ae9e1dbcfdd80324148 ]
    
    Do not allow delta value to be zero since it is used as a divisor.
    
    Fixes: 8af2a218de38 ("sch_red: Adaptative RED AQM")
    Signed-off-by: Nogah Frankel <nogahf@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cb73895efa3cb4420452d89e17984410612c3fc
Author: Zumeng Chen <zumeng.chen@gmail.com>
Date:   Mon Dec 4 11:22:02 2017 +0800

    gianfar: fix a flooded alignment reports because of padding issue.
    
    
    [ Upstream commit 58117672943734715bbe7565ac9f062effa524f0 ]
    
    According to LS1021A RM, the value of PAL can be set so that the start of the
    IP header in the receive data buffer is aligned to a 32-bit boundary. Normally,
    setting PAL = 2 provides minimal padding to ensure such alignment of the IP
    header.
    
    However every incoming packet's 8-byte time stamp will be inserted into the
    packet data buffer as padding alignment bytes when hardware time stamping is
    enabled.
    
    So we set the padding 8+2 here to avoid the flooded alignment faults:
    
    root@128:~# cat /proc/cpu/alignment
    User:           0
    System:         17539 (inet_gro_receive+0x114/0x2c0)
    Skipped:        0
    Half:           0
    Word:           0
    DWord:          0
    Multi:          17539
    User faults:    2 (fixup)
    
    Also shown when exception report enablement
    
    CPU: 0 PID: 161 Comm: irq/66-eth1_g0_ Not tainted 4.1.21-rt13-WR8.0.0.0_preempt-rt #16
    Hardware name: Freescale LS1021A
    [<8001b420>] (unwind_backtrace) from [<8001476c>] (show_stack+0x20/0x24)
    [<8001476c>] (show_stack) from [<807cfb48>] (dump_stack+0x94/0xac)
    [<807cfb48>] (dump_stack) from [<80025d70>] (do_alignment+0x720/0x958)
    [<80025d70>] (do_alignment) from [<80009224>] (do_DataAbort+0x40/0xbc)
    [<80009224>] (do_DataAbort) from [<80015398>] (__dabt_svc+0x38/0x60)
    Exception stack(0x86ad1cc0 to 0x86ad1d08)
    1cc0: f9b3e080 86b3d072 2d78d287 00000000 866816c0 86b3d05e 86e785d0 00000000
    1ce0: 00000011 0000000e 80840ab0 86ad1d3c 86ad1d08 86ad1d08 806d7fc0 806d806c
    1d00: 40070013 ffffffff
    [<80015398>] (__dabt_svc) from [<806d806c>] (inet_gro_receive+0x114/0x2c0)
    [<806d806c>] (inet_gro_receive) from [<80660eec>] (dev_gro_receive+0x21c/0x3c0)
    [<80660eec>] (dev_gro_receive) from [<8066133c>] (napi_gro_receive+0x44/0x17c)
    [<8066133c>] (napi_gro_receive) from [<804f0538>] (gfar_clean_rx_ring+0x39c/0x7d4)
    [<804f0538>] (gfar_clean_rx_ring) from [<804f0bf4>] (gfar_poll_rx_sq+0x58/0xe0)
    [<804f0bf4>] (gfar_poll_rx_sq) from [<80660b10>] (net_rx_action+0x27c/0x43c)
    [<80660b10>] (net_rx_action) from [<80033638>] (do_current_softirqs+0x1e0/0x3dc)
    [<80033638>] (do_current_softirqs) from [<800338c4>] (__local_bh_enable+0x90/0xa8)
    [<800338c4>] (__local_bh_enable) from [<8008025c>] (irq_forced_thread_fn+0x70/0x84)
    [<8008025c>] (irq_forced_thread_fn) from [<800805e8>] (irq_thread+0x16c/0x244)
    [<800805e8>] (irq_thread) from [<8004e490>] (kthread+0xe8/0x104)
    [<8004e490>] (kthread) from [<8000fda8>] (ret_from_fork+0x14/0x2c)
    
    Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 013cf65277a576af1e067ab65c619320bcc38dc3
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Dec 4 08:27:17 2017 -0800

    ARM: dts: Fix elm interrupt compiler warning
    
    
    [ Upstream commit d364b038bc962f494cffb8f6cb6cddbe41bcb5b6 ]
    
    Looks like the interrupt property is missing the controller and level
    information causing:
    
    Warning (interrupts_property): interrupts size is (4), expected multiple
    of 12 in /ocp/elm@48078000
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b659e15da5ab95e68cee9860d18d41e1926cc08b
Author: Stefan Haberland <sth@linux.vnet.ibm.com>
Date:   Thu Oct 26 14:37:35 2017 +0200

    s390/dasd: prevent prefix I/O error
    
    
    [ Upstream commit da340f921d3454f1521671c7a5a43ad3331fbe50 ]
    
    Prevent that a prefix flag is set based on invalid configuration data.
    The validity.verify_base flag should only be set for alias devices.
    Usually the unit address type is either one of base, PAV alias or
    HyperPAV alias. But in cases where the unit address type is not set or
    any other value the validity.verify_base flag might be set as well.
    This would lead to follow on errors.
    Explicitly check for alias devices and set the validity flag only for
    them.
    
    Signed-off-by: Stefan Haberland <sth@linux.vnet.ibm.com>
    Reviewed-by: Jan Hoeppner <hoeppner@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d532f6283928bfe0b028ca0972f42997837468e7
Author: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Date:   Thu Nov 30 14:03:22 2017 +0530

    powerpc/perf: Fix oops when grouping different pmu events
    
    
    [ Upstream commit 5aa04b3eb6fca63d2e9827be656dcadc26d54e11 ]
    
    When user tries to group imc (In-Memory Collections) event with
    normal event, (sometime) kernel crashes with following log:
    
        Faulting instruction address: 0x00000000
        [link register   ] c00000000010ce88 power_check_constraints+0x128/0x980
        ...
        c00000000010e238 power_pmu_event_init+0x268/0x6f0
        c0000000002dc60c perf_try_init_event+0xdc/0x1a0
        c0000000002dce88 perf_event_alloc+0x7b8/0xac0
        c0000000002e92e0 SyS_perf_event_open+0x530/0xda0
        c00000000000b004 system_call+0x38/0xe0
    
    'event_base' field of 'struct hw_perf_event' is used as flags for
    normal hw events and used as memory address for imc events. While
    grouping these two types of events, collect_events() tries to
    interpret imc 'event_base' as a flag, which causes a corruption
    resulting in a crash.
    
    Consider only those events which belongs to 'perf_hw_context' in
    collect_events().
    
    Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
    Reviewed-By: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7693bb5dd56eb5e8746373d65ce414ab6d6ac838
Author: Greg Ungerer <gerg@linux-m68k.org>
Date:   Tue Nov 14 11:50:07 2017 +1000

    m68k: add missing SOFTIRQENTRY_TEXT linker section
    
    
    [ Upstream commit 969de0988b77e5a57aac2f7270191a3c50540c52 ]
    
    Commit be7635e7287e ("arch, ftrace: for KASAN put hard/soft IRQ entries
    into separate sections") added a new linker section, SOFTIRQENTRY_TEXT,
    to the linker scripts for most architectures. It didn't add it to any of
    the linker scripts for the m68k architecture. This was not really a problem
    because it is only defined if either of CONFIG_FUNCTION_GRAPH_TRACER or
    CONFIG_KASAN are enabled - which can never be true for m68k.
    
    However commit 229a71860547 ("irq: Make the irqentry text section
    unconditional") means that SOFTIRQENTRY_TEXT is now always defined. So on
    m68k we now end up with a separate ELF section for .softirqentry.text
    instead of it being part of the .text section. On some m68k targets in some
    configurations this can also cause a fatal link error:
    
      LD      vmlinux
    /usr/local/bin/../m68k-uclinux/bin/ld.real: section .softirqentry.text loaded at [0000000010de10c0,0000000010de12dd] overlaps section .rodata loaded at [0000000010de10c0,0000000010e0fd67]
    
    To fix add in the missing SOFTIRQENTRY_TEXT section into the m68k linker
    scripts. I noticed that m68k is also missing the IRQENTRY_TEXT section,
    so this patch also adds an entry for that too.
    
    Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 671d901f226beccbb528ccbf4c1fa99ed7d9e118
Author: Gao Feng <gfree.wind@vip.163.com>
Date:   Fri Dec 1 09:58:42 2017 +0800

    ipvlan: Add the skb->mark as flow4's member to lookup route
    
    
    [ Upstream commit a98a4ebc8c61d20f0150d6be66e0e65223a347af ]
    
    Current codes don't use skb->mark to assign flowi4_mark, it would
    make the policy route rule with fwmark doesn't work as expected.
    
    Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e985f5a9487f2c9c30fe652a9922ff78a700aebd
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Nov 29 15:20:03 2017 +0000

    scripts/kernel-doc: Don't fail with status != 0 if error encountered with -none
    
    
    [ Upstream commit e814bccbafece52a24e152d2395b5d49eef55841 ]
    
    My bisect scripts starting running into build failures when trying to
    compile 4.15-rc1 with the builds failing with things like:
    
    drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union!
    
    The line in question is actually just a #define, but after some digging
    it turns out that my scripts pass W=1 and since commit 3a025e1d1c2ea
    ("Add optional check for bad kernel-doc comments") that results in
    kernel-doc running on each source file. The file in question has a
    badly formatted comment immediately before the #define:
    
    /**
     * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for
     * bus layer usage.
     */
    
    which causes the regex in dump_struct to fail (lack of braces following
    struct declaration) and kernel-doc returns 1, which causes the build
    to fail.
    
    Fix the issue by always returning 0 from kernel-doc when invoked with
    -none. It successfully generates no documentation, and prints out any
    issues.
    
    Cc: Matthew Wilcox <mawilcox@microsoft.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f4ed764ad1834fc0d64b903cf1e43b23e3f9f21
Author: Xin Long <lucien.xin@gmail.com>
Date:   Sat Nov 25 21:18:34 2017 +0800

    sctp: only update outstanding_bytes for transmitted queue when doing prsctp_prune
    
    
    [ Upstream commit d30fc5126efb0c33b7adf5966d3051db2c3d7721 ]
    
    Now outstanding_bytes is only increased when appending chunks into one
    packet and sending it at 1st time, while decreased when it is about to
    move into retransmit queue. It means outstanding_bytes value is already
    decreased for all chunks in retransmit queue.
    
    However sctp_prsctp_prune_sent is a common function to check the chunks
    in both transmitted and retransmit queue, it decrease outstanding_bytes
    when moving a chunk into abandoned queue from either of them.
    
    It could cause outstanding_bytes underflow, as it also decreases it's
    value for the chunks in retransmit queue.
    
    This patch fixes it by only updating outstanding_bytes for transmitted
    queue when pruning queues for prsctp prio policy, the same fix is also
    needed in sctp_check_transmitted.
    
    Fixes: 8dbdf1f5b09c ("sctp: implement prsctp PRIO policy")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7fb8b5d4867eb99d1f936c06add86603020c97d2
Author: Moni Shoua <monis@mellanox.com>
Date:   Sun Nov 26 20:23:54 2017 +0200

    RDMA/cma: Make sure that PSN is not over max allowed
    
    
    [ Upstream commit 23a9cd2ad90543e9da3786878d2b2729c095439d ]
    
    This patch limits the initial value for PSN to 24 bits as
    spec requires.
    
    Signed-off-by: Moni Shoua <monis@mellanox.com>
    Signed-off-by: Mukesh Kacker <mukesh.kacker@oracle.com>
    Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
    Reviewed-by: Parav Pandit <parav@mellanox.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82f9ba5ee2f7bde5f894786f74f0bb401130fafe
Author: Mustafa Ismail <mustafa.ismail@intel.com>
Date:   Tue Nov 21 16:18:32 2017 -0600

    i40iw: Correct ARP index mask
    
    
    [ Upstream commit a283cdc4d3670700182c820b59078387f9a01a30 ]
    
    The ARP table entry indexes are aliased to 12bits
    instead of the intended 16bits when uploaded to
    the QP Context. This will present an issue when the
    number of connections exceeds 4096 as ARP entries are
    reused. Fix this by adjusting the mask to account for
    the full 16bits.
    
    Fixes: 4e9042e647ff ("i40iw: add hw and utils files")
    Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e535dafc07baa606d238e8f4d869b0a732d11d5
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Sat Nov 25 12:12:30 2017 +0000

    pinctrl: sunxi: Fix A64 UART mux value
    
    
    [ Upstream commit 7c5c2c2d18d778e51fd8b899965097168306031c ]
    
    To use pin PF4 as the RX signal of UART0, we have to write 0b011 into
    the respective pin controller register.
    Fix the wrong value we had in our table so far.
    
    Fixes: 96851d391d02 ("drivers: pinctrl: add driver for Allwinner A64 SoC")
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Acked-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 416871776a0147475850a0eeb870540682207f74
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Sat Nov 25 12:19:48 2017 +0000

    pinctrl: sunxi: Fix A80 interrupt pin bank
    
    
    [ Upstream commit 6ad4cc8d1ac483e0fd33f605fb2788b0ecf51ed4 ]
    
    On the A80 the pins on port B can trigger interrupts, and those are
    assigned to the second interrupt bank.
    Having two pins assigned to the same interrupt bank/pin combination does
    not look healthy (instead more like a copy&paste bug from pins PA14-PA16),
    so fix the interrupt bank for pins PB14-PB16, which is actually 1.
    
    I don't have any A80 board, so could not test this.
    
    Fixes: d5e9fb31baa2 ("pinctrl: sunxi: Add A80 pinctrl muxing options")
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Acked-by: Chen-Yu Tsai <wens@csie.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74e9c5b29b12217e37e3c626110a7d0eb187ccca
Author: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Date:   Wed Nov 29 08:44:41 2017 -0500

    media: s5k6aa: describe some function parameters
    
    
    [ Upstream commit 070250a1715cee2297de0d9e7e2cea58be999d37 ]
    
    as warned:
      drivers/media/i2c/s5k6aa.c:429: warning: No description found for parameter 's5k6aa'
      drivers/media/i2c/s5k6aa.c:679: warning: No description found for parameter 's5k6aa'
      drivers/media/i2c/s5k6aa.c:733: warning: No description found for parameter 's5k6aa'
      drivers/media/i2c/s5k6aa.c:733: warning: No description found for parameter 'preset'
      drivers/media/i2c/s5k6aa.c:787: warning: No description found for parameter 'sd'
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 510b5d8dd8b8d197c3401fee7dd7e0595cf01d99
Author: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Date:   Wed Nov 22 22:13:53 2017 +0530

    perf bench numa: Fixup discontiguous/sparse numa nodes
    
    
    [ Upstream commit 321a7c35c90cc834851ceda18a8ee18f1d032b92 ]
    
    Certain systems are designed to have sparse/discontiguous nodes.  On
    such systems, 'perf bench numa' hangs, shows wrong number of nodes and
    shows values for non-existent nodes. Handle this by only taking nodes
    that are exposed by kernel to userspace.
    
    Signed-off-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
    Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Link: http://lkml.kernel.org/r/1edbcd353c009e109e93d78f2f46381930c340fe.1511368645.git.sathnaga@linux.vnet.ibm.com
    Signed-off-by: Balamuruhan S <bala24@linux.vnet.ibm.com>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2eca0cda2d6fb4a539f3369172d0d045d872360
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Tue Nov 14 10:23:39 2017 +0100

    perf top: Fix window dimensions change handling
    
    
    [ Upstream commit 89d0aeab4252adc2a7ea693637dd21c588bfa2d1 ]
    
    The stdio perf top crashes when we change the terminal
    window size. The reason is that we assumed we get the
    perf_top pointer as a signal handler argument which is
    not the case.
    
    Changing the SIGWINCH handler logic to change global
    resize variable, which is checked in the main thread
    loop.
    
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Tested-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Wang Nan <wangnan0@huawei.com>
    Link: http://lkml.kernel.org/n/tip-ysuzwz77oev1ftgvdscn9bpu@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e41d6c98e893db96105d8fe3ed8a81469f815554
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Wed Nov 1 11:03:40 2017 +0200

    ARM: dts: am437x-cm-t43: Correct the dmas property of spi0
    
    
    [ Upstream commit ca41e244517d6d3f1600c229ff7ca615049c1e9c ]
    
    The DMA binding for eDMA needs 2 parameters, not 1.
    The second, missing parameter is the tptc to be used for the channel.
    
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0497ca7dda9e9e2bf0f2589d6f3cbf057c067fb9
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Wed Nov 1 11:03:31 2017 +0200

    ARM: dts: am4372: Correct the interrupts_properties of McASP
    
    
    [ Upstream commit 627395a6f8091c0aa18f49dca7df59ba3ec147ef ]
    
    Fixes the following warnings:
    
    arch/arm/boot/dts/am437x-cm-t43.dtb: Warning (interrupts_property):
    interrupts size is (8), expected multiple of 12 in
    /ocp@44000000/mcasp@48038000
    
    arch/arm/boot/dts/am437x-cm-t43.dtb: Warning (interrupts_property):
    interrupts size is (8), expected multiple of 12 in
    /ocp@44000000/mcasp@4803C000
    
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10a889b659f3a1b0a07a60f07267f7c0fc1d9a24
Author: Adam Ford <aford173@gmail.com>
Date:   Tue Oct 31 13:45:59 2017 -0500

    ARM: dts: logicpd-somlv: Fix wl127x pinmux
    
    
    [ Upstream commit cd7594ac3281722cb8f10d6f6c7e4287747c7a9d ]
    
    The pin assignment for the wl127x interrupt was incorrect.  I am
    not sure how this every worked.  This also eliminates a conflict with
    the SMC911x ethernet driver and properly moves pinmuxes for the
    related gpio to omap3_pmx_wkup from omap3_pmx_core.
    
    Fixes: ab8dd3aed011 ("ARM: DTS: Add minimal Support for Logic PD
    DM3730 SOM-LV")
    
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84adf1934a75eac40c75356d213b525c50b7fb0e
Author: Adam Ford <aford173@gmail.com>
Date:   Tue Oct 31 13:42:13 2017 -0500

    ARM: dts: logicpd-som-lv: Fix gpmc addresses for NAND and enet
    
    
    [ Upstream commit 3c18bbf3d11d2005da08b57ff26f44ff1c2b12d0 ]
    
    This patch fixes and issue where the NAND and GPMC based ethernet
    controller stopped working.  This also updates the GPMC settings
    to be consistent with the Logic PD Torpedo development from the
    commit listed above.
    
    Fixes: 44e4716499b8 ("ARM: dts: omap3: Fix NAND device nodes")
    
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 898efc96227aa2fcc9d1b2a94e8e428deed9d580
Author: Tony Lindgren <tony@atomide.com>
Date:   Fri Nov 17 08:56:58 2017 -0800

    ARM: dts: Fix omap4 hang with GPS connected to USB by using wakeupgen
    
    
    [ Upstream commit cf87634c8b24e24bf379b8c6807c8b0fb5f23567 ]
    
    There's been a reproducable USB OHCI/EHCI cpuidle related hang on omap4
    for a while that happens after about 20 - 40 minutes on an idle system
    with some data feeding device being connected, like a USB GPS device or
    a cellular modem.
    
    This issue happens in cpuidle states C2 and C3 and does not happen if
    cpuidle is limited to C1 state only. The symptoms are that the whole
    system hangs and never wakes up from idle, and if a watchdog is
    configured the system reboots after a while.
    
    Turns out that OHCI/EHCI devices on omap4 are trying to use the GIC
    interrupt controller directly as a parent instead of the WUGEN. We
    need to pass the interrupts through WUGEN to GIC to provide the wakeup
    events for the processor.
    
    Let's fix the issue by removing the gic interrupt-parent and use the
    default interrupt-parent wakeupgen instead. Note that omap5.dtsi had
    this already fixes earlier by commit 7136d457f365 ("ARM: omap: convert
    wakeupgen to stacked domains") but we somehow missed omap4 at that
    point.
    
    Fixes: 7136d457f365 ("ARM: omap: convert wakeupgen to stacked domains")
    Cc: Dave Gerlach <d-gerlach@ti.com>
    Cc: Nishanth Menon <nm@ti.com>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
    Reviewed-by: Roger Quadros <rogerq@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c56be1d94eeeb68d4247e15a616082e1c1f8b09
Author: Keerthy <j-keerthy@ti.com>
Date:   Fri Nov 10 16:56:52 2017 +0530

    ARM: AM33xx: PRM: Remove am33xx_pwrdm_read_prev_pwrst function
    
    
    [ Upstream commit b6d6af7226465b6d11eac09d0be2ab78a4a9eb62 ]
    
    Referring TRM Am335X series:
    http://www.ti.com/lit/ug/spruh73p/spruh73p.pdf
    
    The LastPowerStateEntered bitfield is present only for PM_CEFUSE
    domain. This is not present in any of the other power domains. Hence
    remove the generic am33xx_pwrdm_read_prev_pwrst hook which wrongly
    reads the reserved bit fields for all the other power domains.
    
    Reading the reserved bits leads to wrongly interpreting the low
    power transitions for various power domains that do not have the
    LastPowerStateEntered field. The pm debug counters values are wrong
    currently as we are incrementing them based on the reserved bits.
    
    Signed-off-by: Keerthy <j-keerthy@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 909ae61c74f6bd404aaeddbcf78e5cd81f9ceaed
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Nov 27 08:57:26 2017 -0800

    ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context
    
    
    [ Upstream commit d09220a887f70368afa79e850c95e74890c0a32d ]
    
    With the CMA changes from Joonsoo Kim <iamjoonsoo.kim@lge.com>, it
    was noticed that n900 stopped booting. After investigating it turned
    out that n900 save_secure_ram_context does some whacky virtual to
    physical address translation for the SRAM data address.
    
    As we now only have minimal parts of omap3 idle code copied to SRAM,
    running save_secure_ram_context() in SRAM is not needed. It only gets
    called on PM init. And it seems there's no need to ever call this from
    SRAM idle code.
    
    So let's just keep save_secure_ram_context() in DDR, and pass it the
    physical address of the parameters. We can do everything else in
    omap-secure.c like we already do for other secure code.
    
    And since we don't have any documentation, I still have no clue what
    the values for 0, 1 and 1 for the parameters might be. If somebody has
    figured it out, please do send a patch to add some comments.
    
    Debugged-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b25d766c27a053284fb23f6805071f5555cf3592
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Fri Nov 17 11:00:45 2017 -0800

    usb: build drivers/usb/common/ when USB_SUPPORT is set
    
    
    [ Upstream commit c9d24f78268be444e803fb2bb138a2f598de9c23 ]
    
    PHY drivers can use ULPI interfaces when CONFIG_USB (which is host side
    support) is not enabled, so also build drivers/usb/ when CONFIG_USB_SUPPORT
    is enabled so that drivers/usb/common/ is built.
    
    ERROR: "ulpi_unregister_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined!
    ERROR: "__ulpi_register_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined!
    ERROR: "ulpi_read" [drivers/phy/ti/phy-tusb1210.ko] undefined!
    ERROR: "ulpi_write" [drivers/phy/ti/phy-tusb1210.ko] undefined!
    ERROR: "ulpi_unregister_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined!
    ERROR: "__ulpi_register_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined!
    ERROR: "ulpi_write" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined!
    
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8690825ea691c689a1c21fbf5f8000df35cf043b
Author: Shuah Khan <shuahkh@osg.samsung.com>
Date:   Fri Jan 26 11:56:50 2018 -0700

    usbip: keep usbip_device sockfd state in sync with tcp_socket
    
    commit 009f41aed4b3e11e6dc1e3c07377a10c20f1a5ed upstream.
    
    Keep usbip_device sockfd state in sync with tcp_socket. When tcp_socket
    is reset to null, reset sockfd to -1 to keep it in sync.
    
    Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f23830925a33186636f229f5d20abd3178aa38e1
Author: Alexandru Ardelean <alexandru.ardelean@analog.com>
Date:   Thu Jan 25 14:30:45 2018 +0200

    staging: iio: ad5933: switch buffer mode to software
    
    commit 7d2b8e6aaf9ee87910c2337e1c59bb5d3e3ba8c5 upstream.
    
    Since commit 152a6a884ae1 ("staging:iio:accel:sca3000 move
    to hybrid hard / soft buffer design.")
    the buffer mechanism has changed and the
    INDIO_BUFFER_HARDWARE flag has been unused.
    
    Since commit 2d6ca60f3284 ("iio: Add a DMAengine framework
    based buffer")
    the INDIO_BUFFER_HARDWARE flag has been re-purposed for
    DMA buffers.
    
    This driver has lagged behind these changes, and
    in order for buffers to work, the INDIO_BUFFER_SOFTWARE
    needs to be used.
    
    Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Fixes: 2d6ca60f3284 ("iio: Add a DMAengine framework based buffer")
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d00bf35965be429e5426f84baafd3c2d8df435cd
Author: Alexandru Ardelean <alexandru.ardelean@analog.com>
Date:   Mon Jan 22 11:53:12 2018 +0200

    staging: iio: adc: ad7192: fix external frequency setting
    
    commit e31b617d0a63c6558485aaa730fd162faa95a766 upstream.
    
    The external clock frequency was set only when selecting
    the internal clock, which is fixed at 4.9152 Mhz.
    
    This is incorrect, since it should be set when any of
    the external clock or crystal settings is selected.
    
    Added range validation for the external (crystal/clock)
    frequency setting.
    Valid values are between 2.4576 and 5.12 Mhz.
    
    Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4be5a281048964854c0b1c145e57597e7116ea9f
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Jan 30 23:11:24 2018 -0800

    binder: check for binder_thread allocation failure in binder_poll()
    
    commit f88982679f54f75daa5b8eff3da72508f1e7422f upstream.
    
    If the kzalloc() in binder_get_thread() fails, binder_poll()
    dereferences the resulting NULL pointer.
    
    Fix it by returning POLLERR if the memory allocation failed.
    
    This bug was found by syzkaller using fault injection.
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2dfe49da487cf92b45083deb38e37062a5b8f83e
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Feb 4 02:06:27 2018 +0000

    staging: android: ashmem: Fix a race condition in pin ioctls
    
    commit ce8a3a9e76d0193e2e8d74a06d275b3c324ca652 upstream.
    
    ashmem_pin_unpin() reads asma->file and asma->size before taking the
    ashmem_mutex, so it can race with other operations that modify them.
    
    Build-tested only.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fedae0f64845933a0f28604a09be2e0323d66236
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 15 16:59:49 2018 +0100

    dn_getsockoptdecnet: move nf_{get/set}sockopt outside sock lock
    
    commit dfec091439bb2acf763497cfc58f2bdfc67c56b7 upstream.
    
    After commit 3f34cfae1238 ("netfilter: on sockopt() acquire sock lock
    only in the required scope"), the caller of nf_{get/set}sockopt() must
    not hold any lock, but, in such changeset, I forgot to cope with DECnet.
    
    This commit addresses the issue moving the nf call outside the lock,
    in the dn_{get,set}sockopt() with the same schema currently used by
    ipv4 and ipv6. Also moves the unhandled sockopts of the end of the main
    switch statements, to improve code readability.
    
    Reported-by: Petr Vandrovec <petr@vandrovec.name>
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198791#c2
    Fixes: 3f34cfae1238 ("netfilter: on sockopt() acquire sock lock only in the required scope")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5a8a31db2cc2ddc549df75f7beaada6eaf4060e
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jan 10 22:06:48 2018 +0100

    arm64: dts: add #cooling-cells to CPU nodes
    
    commit acbf76ee05067c3942852019993f7beb69a0f45f upstream.
    
    dtc complains about the lack of #coolin-cells properties for the
    CPU nodes that are referred to as "cooling-device":
    
    arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning (cooling_device_property): Missing property '#cooling-cells' in node /cpus/cpu@0 or bad phandle (referred from /thermal-zones/cpu_thermal/cooling-maps/map@0:cooling-device[0])
    arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning (cooling_device_property): Missing property '#cooling-cells' in node /cpus/cpu@100 or bad phandle (referred from /thermal-zones/cpu_thermal/cooling-maps/map@1:cooling-device[0])
    
    Apparently this property must be '<2>' to match the binding.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Tested-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    [arnd: backported to 4.15]
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f10bcae2c98ea15bf67148d9f52ed63ed8ee6287
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jan 10 17:53:18 2018 +0100

    ARM: 8743/1: bL_switcher: add MODULE_LICENSE tag
    
    commit a21b4c10c7bf5b58112afa20d6fa829e8d74e3e6 upstream.
    
    Without this tag, we get a build warning:
    
    WARNING: modpost: missing MODULE_LICENSE() in arch/arm/common/bL_switcher_dummy_if.o
    
    For completeness, I'm also adding author and description fields.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc428560984ce1705a092fe94305689849ccb7f6
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Jan 15 17:04:22 2018 +0100

    video: fbdev/mmp: add MODULE_LICENSE
    
    commit c1530ac5a3ce93a1f02adabc4508b5fbf862dfe2 upstream.
    
    Kbuild complains about the lack of a license tag in this driver:
    
    WARNING: modpost: missing MODULE_LICENSE() in drivers/video/fbdev/mmp/mmp_disp.o
    
    This adds the license, author and description tags.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec677e0687ded48154852faa7d5ff25d171a691b
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jan 10 17:34:45 2018 +0100

    ASoC: ux500: add MODULE_LICENSE tag
    
    commit 1783c9d7cb7bc3181b9271665959b87280d98d8e upstream.
    
    This adds MODULE_LICENSE/AUTHOR/DESCRIPTION tags to the ux500
    platform drivers, to avoid these build warnings:
    
    WARNING: modpost: missing MODULE_LICENSE() in sound/soc/ux500/snd-soc-ux500-plat-dma.o
    WARNING: modpost: missing MODULE_LICENSE() in sound/soc/ux500/snd-soc-ux500-mach-mop500.o
    
    The company no longer exists, so the email addresses of the authors
    don't work any more, but I've added them anyway for consistency.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit adf26e87f4b73d1f820352b0bfa085f6aaf3f51a
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Jan 3 11:16:27 2018 -0800

    crypto: hash - prevent using keyed hashes without setting key
    
    commit 9fa68f620041be04720d0cbfb1bd3ddfc6310b24 upstream.
    
    Currently, almost none of the keyed hash algorithms check whether a key
    has been set before proceeding.  Some algorithms are okay with this and
    will effectively just use a key of all 0's or some other bogus default.
    However, others will severely break, as demonstrated using
    "hmac(sha3-512-generic)", the unkeyed use of which causes a kernel crash
    via a (potentially exploitable) stack buffer overflow.
    
    A while ago, this problem was solved for AF_ALG by pairing each hash
    transform with a 'has_key' bool.  However, there are still other places
    in the kernel where userspace can specify an arbitrary hash algorithm by
    name, and the kernel uses it as unkeyed hash without checking whether it
    is really unkeyed.  Examples of this include:
    
        - KEYCTL_DH_COMPUTE, via the KDF extension
        - dm-verity
        - dm-crypt, via the ESSIV support
        - dm-integrity, via the "internal hash" mode with no key given
        - drbd (Distributed Replicated Block Device)
    
    This bug is especially bad for KEYCTL_DH_COMPUTE as that requires no
    privileges to call.
    
    Fix the bug for all users by adding a flag CRYPTO_TFM_NEED_KEY to the
    ->crt_flags of each hash transform that indicates whether the transform
    still needs to be keyed or not.  Then, make the hash init, import, and
    digest functions return -ENOKEY if the key is still needed.
    
    The new flag also replaces the 'has_key' bool which algif_hash was
    previously using, thereby simplifying the algif_hash implementation.
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b392a53b11f325b30b7d54e575352a8cac4c300d
Author: Eric Biggers <ebiggers@google.com>
Date:   Wed Jan 3 11:16:26 2018 -0800

    crypto: hash - annotate algorithms taking optional key
    
    commit a208fa8f33031b9e0aba44c7d1b7e68eb0cbd29e upstream.
    
    We need to consistently enforce that keyed hashes cannot be used without
    setting the key.  To do this we need a reliable way to determine whether
    a given hash algorithm is keyed or not.  AF_ALG currently does this by
    checking for the presence of a ->setkey() method.  However, this is
    actually slightly broken because the CRC-32 algorithms implement
    ->setkey() but can also be used without a key.  (The CRC-32 "key" is not
    actually a cryptographic key but rather represents the initial state.
    If not overridden, then a default initial state is used.)
    
    Prepare to fix this by introducing a flag CRYPTO_ALG_OPTIONAL_KEY which
    indicates that the algorithm has a ->setkey() method, but it is not
    required to be called.  Then set it on all the CRC-32 algorithms.
    
    The same also applies to the Adler-32 implementation in Lustre.
    
    Also, the cryptd and mcryptd templates have to pass through the flag
    from their underlying algorithm.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb9c7c7d9542a33011b1e217e5a283ebf94fac01
Author: Willem de Bruijn <willemb@google.com>
Date:   Tue Dec 12 11:39:04 2017 -0500

    net: avoid skb_warn_bad_offload on IS_ERR
    
    commit 8d74e9f88d65af8bb2e095aff506aa6eac755ada upstream.
    
    skb_warn_bad_offload warns when packets enter the GSO stack that
    require skb_checksum_help or vice versa. Do not warn on arbitrary
    bad packets. Packet sockets can craft many. Syzkaller was able to
    demonstrate another one with eth_type games.
    
    In particular, suppress the warning when segmentation returns an
    error, which is for reasons other than checksum offload.
    
    See also commit 36c92474498a ("net: WARN if skb_checksum_help() is
    called on skb requiring segmentation") for context on this warning.
    
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4dc0159458d607c8ccf36ba91a262d7bba7d4bbc
Author: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date:   Thu Nov 30 11:11:29 2017 -0800

    rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete
    
    commit f10b4cff98c6977668434fbf5dd58695eeca2897 upstream.
    
    The rds_tcp_kill_sock() function parses the rds_tcp_conn_list
    to find the rds_connection entries marked for deletion as part
    of the netns deletion under the protection of the rds_tcp_conn_lock.
    Since the rds_tcp_conn_list tracks rds_tcp_connections (which
    have a 1:1 mapping with rds_conn_path), multiple tc entries in
    the rds_tcp_conn_list will map to a single rds_connection, and will
    be deleted as part of the rds_conn_destroy() operation that is
    done outside the rds_tcp_conn_lock.
    
    The rds_tcp_conn_list traversal done under the protection of
    rds_tcp_conn_lock should not leave any doomed tc entries in
    the list after the rds_tcp_conn_lock is released, else another
    concurrently executiong netns delete (for a differnt netns) thread
    may trip on these entries.
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d5c422fc709def69d574b03052c73bb6442a638
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Mon Feb 5 14:41:45 2018 -0800

    netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
    
    commit 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 upstream.
    
    rateest_hash is supposed to be protected by xt_rateest_mutex,
    and, as suggested by Eric, lookup and insert should be atomic,
    so we should acquire the xt_rateest_mutex once for both.
    
    So introduce a non-locking helper for internal use and keep the
    locking one for external.
    
    Reported-by: <syzbot+5cb189720978275e4c75@syzkaller.appspotmail.com>
    Fixes: 5859034d7eb8 ("[NETFILTER]: x_tables: add RATEEST target")
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6f3be756b784b69253a1d4bcd72c2e891f87a74
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Wed Jan 31 15:02:47 2018 -0800

    netfilter: xt_cgroup: initialize info->priv in cgroup_mt_check_v1()
    
    commit ba7cd5d95f25cc6005f687dabdb4e7a6063adda9 upstream.
    
    xt_cgroup_info_v1->priv is an internal pointer only used for kernel,
    we should not trust what user-space provides.
    
    Reported-by: <syzbot+4fbcfcc0d2e6592bd641@syzkaller.appspotmail.com>
    Fixes: c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match")
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ec264d8128958e66d048f45fd1c4c28cfedb119
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue Jan 30 19:01:40 2018 +0100

    netfilter: on sockopt() acquire sock lock only in the required scope
    
    commit 3f34cfae1238848fd53f25e5c8fd59da57901f4b upstream.
    
    Syzbot reported several deadlocks in the netfilter area caused by
    rtnl lock and socket lock being acquired with a different order on
    different code paths, leading to backtraces like the following one:
    
    ======================================================
    WARNING: possible circular locking dependency detected
    4.15.0-rc9+ #212 Not tainted
    ------------------------------------------------------
    syzkaller041579/3682 is trying to acquire lock:
      (sk_lock-AF_INET6){+.+.}, at: [<000000008775e4dd>] lock_sock
    include/net/sock.h:1463 [inline]
      (sk_lock-AF_INET6){+.+.}, at: [<000000008775e4dd>]
    do_ipv6_setsockopt.isra.8+0x3c5/0x39d0 net/ipv6/ipv6_sockglue.c:167
    
    but task is already holding lock:
      (rtnl_mutex){+.+.}, at: [<000000004342eaa9>] rtnl_lock+0x17/0x20
    net/core/rtnetlink.c:74
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 (rtnl_mutex){+.+.}:
            __mutex_lock_common kernel/locking/mutex.c:756 [inline]
            __mutex_lock+0x16f/0x1a80 kernel/locking/mutex.c:893
            mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
            rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
            register_netdevice_notifier+0xad/0x860 net/core/dev.c:1607
            tee_tg_check+0x1a0/0x280 net/netfilter/xt_TEE.c:106
            xt_check_target+0x22c/0x7d0 net/netfilter/x_tables.c:845
            check_target net/ipv6/netfilter/ip6_tables.c:538 [inline]
            find_check_entry.isra.7+0x935/0xcf0
    net/ipv6/netfilter/ip6_tables.c:580
            translate_table+0xf52/0x1690 net/ipv6/netfilter/ip6_tables.c:749
            do_replace net/ipv6/netfilter/ip6_tables.c:1165 [inline]
            do_ip6t_set_ctl+0x370/0x5f0 net/ipv6/netfilter/ip6_tables.c:1691
            nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
            nf_setsockopt+0x67/0xc0 net/netfilter/nf_sockopt.c:115
            ipv6_setsockopt+0x115/0x150 net/ipv6/ipv6_sockglue.c:928
            udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1422
            sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2978
            SYSC_setsockopt net/socket.c:1849 [inline]
            SyS_setsockopt+0x189/0x360 net/socket.c:1828
            entry_SYSCALL_64_fastpath+0x29/0xa0
    
    -> #0 (sk_lock-AF_INET6){+.+.}:
            lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3914
            lock_sock_nested+0xc2/0x110 net/core/sock.c:2780
            lock_sock include/net/sock.h:1463 [inline]
            do_ipv6_setsockopt.isra.8+0x3c5/0x39d0 net/ipv6/ipv6_sockglue.c:167
            ipv6_setsockopt+0xd7/0x150 net/ipv6/ipv6_sockglue.c:922
            udpv6_setsockopt+0x45/0x80 net/ipv6/udp.c:1422
            sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2978
            SYSC_setsockopt net/socket.c:1849 [inline]
            SyS_setsockopt+0x189/0x360 net/socket.c:1828
            entry_SYSCALL_64_fastpath+0x29/0xa0
    
    other info that might help us debug this:
    
      Possible unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
       lock(rtnl_mutex);
                                    lock(sk_lock-AF_INET6);
                                    lock(rtnl_mutex);
       lock(sk_lock-AF_INET6);
    
      *** DEADLOCK ***
    
    1 lock held by syzkaller041579/3682:
      #0:  (rtnl_mutex){+.+.}, at: [<000000004342eaa9>] rtnl_lock+0x17/0x20
    net/core/rtnetlink.c:74
    
    The problem, as Florian noted, is that nf_setsockopt() is always
    called with the socket held, even if the lock itself is required only
    for very tight scopes and only for some operation.
    
    This patch addresses the issues moving the lock_sock() call only
    where really needed, namely in ipv*_getorigdst(), so that nf_setsockopt()
    does not need anymore to acquire both locks.
    
    Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
    Reported-by: syzbot+a4c2dc980ac1af699b36@syzkaller.appspotmail.com
    Suggested-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab2b0f7b23447d138be6c4147ec5d2596a94c5ce
Author: Dmitry Vyukov <dvyukov@google.com>
Date:   Tue Jan 30 15:21:34 2018 +0100

    netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
    
    commit 1a38956cce5eabd7b74f94bab70265e4df83165e upstream.
    
    Commit 136e92bbec0a switched local_nodes from an array to a bitmask
    but did not add proper bounds checks. As the result
    clusterip_config_init_nodelist() can both over-read
    ipt_clusterip_tgt_info.local_nodes and over-write
    clusterip_config.local_nodes.
    
    Add bounds checks for both.
    
    Fixes: 136e92bbec0a ("[NETFILTER] CLUSTERIP: use a bitmap to store node responsibility data")
    Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b39f3f381bf3ba387d62655539a8979085cb6ff6
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Jan 24 17:16:09 2018 -0800

    netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
    
    commit da17c73b6eb74aad3c3c0654394635675b623b3e upstream.
    
    It looks like syzbot found its way into netfilter territory.
    
    Issue here is that @name comes from user space and might
    not be null terminated.
    
    Out-of-bound reads happen, KASAN is not happy.
    
    v2 added similar fix for xt_request_find_target(),
    as Florian advised.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1099c708d7b7bcb701ac9f892d8f26811842abdd
Author: Dmitry Vyukov <dvyukov@google.com>
Date:   Thu Dec 28 09:48:54 2017 +0100

    netfilter: x_tables: fix int overflow in xt_alloc_table_info()
    
    commit 889c604fd0b5f6d3b8694ade229ee44124de1127 upstream.
    
    syzkaller triggered OOM kills by passing ipt_replace.size = -1
    to IPT_SO_SET_REPLACE. The root cause is that SMP_ALIGN() in
    xt_alloc_table_info() causes int overflow and the size check passes
    when it should not. SMP_ALIGN() is no longer needed leftover.
    
    Remove SMP_ALIGN() call in xt_alloc_table_info().
    
    Reported-by: syzbot+4396883fa8c4f64e0175@syzkaller.appspotmail.com
    Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c33f9272eefe349fed598999943e626fcef8a708
Author: Dmitry Vyukov <dvyukov@google.com>
Date:   Tue Feb 6 15:40:28 2018 -0800

    kcov: detect double association with a single task
    
    commit a77660d231f8b3d84fd23ed482e0964f7aa546d6 upstream.
    
    Currently KCOV_ENABLE does not check if the current task is already
    associated with another kcov descriptor.  As the result it is possible
    to associate a single task with more than one kcov descriptor, which
    later leads to a memory leak of the old descriptor.  This relation is
    really meant to be one-to-one (task has only one back link).
    
    Extend validation to detect such misuse.
    
    Link: http://lkml.kernel.org/r/20180122082520.15716-1-dvyukov@google.com
    Fixes: 5c9a8750a640 ("kernel: add kcov code coverage")
    Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
    Reported-by: Shankara Pailoor <sp3485@columbia.edu>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: syzbot <syzkaller@googlegroups.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 9748fd5ba546bb93d403208d2fd40dd5fc557b6b
Author: Wanpeng Li <wanpeng.li@hotmail.com>
Date:   Wed Dec 13 10:46:40 2017 +0100

    KVM: x86: fix escape of guest dr6 to the host
    
    commit efdab992813fb2ed825745625b83c05032e9cda2 upstream.
    
    syzkaller reported:
    
       WARNING: CPU: 0 PID: 12927 at arch/x86/kernel/traps.c:780 do_debug+0x222/0x250
       CPU: 0 PID: 12927 Comm: syz-executor Tainted: G           OE    4.15.0-rc2+ #16
       RIP: 0010:do_debug+0x222/0x250
       Call Trace:
        <#DB>
        debug+0x3e/0x70
       RIP: 0010:copy_user_enhanced_fast_string+0x10/0x20
        </#DB>
        _copy_from_user+0x5b/0x90
        SyS_timer_create+0x33/0x80
        entry_SYSCALL_64_fastpath+0x23/0x9a
    
    The testcase sets a watchpoint (with perf_event_open) on a buffer that is
    passed to timer_create() as the struct sigevent argument.  In timer_create(),
    copy_from_user()'s rep movsb triggers the BP.  The testcase also sets
    the debug registers for the guest.
    
    However, KVM only restores host debug registers when the host has active
    watchpoints, which triggers a race condition when running the testcase with
    multiple threads.  The guest's DR6.BS bit can escape to the host before
    another thread invokes timer_create(), and do_debug() complains.
    
    The fix is to respect do_debug()'s dr6 invariant when leaving KVM.
    
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Radim Krčmář <rkrcmar@redhat.com>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7abb5e9dd5683d693376635ff05ec729216fd726
Author: Douglas Gilbert <dgilbert@interlog.com>
Date:   Sun Jan 14 17:00:48 2018 -0500

    blk_rq_map_user_iov: fix error override
    
    commit 69e0927b3774563c19b5fb32e91d75edc147fb62 upstream.
    
    During stress tests by syzkaller on the sg driver the block layer
    infrequently returns EINVAL. Closer inspection shows the block
    layer was trying to return ENOMEM (which is much more
    understandable) but for some reason overroad that useful error.
    
    Patch below does not show this (unchanged) line:
       ret =__blk_rq_map_user_iov(rq, map_data, &i, gfp_mask, copy);
    That 'ret' was being overridden when that function failed.
    
    Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ee287d35b25076b626898284d610465145aa43b
Author: Laura Abbott <labbott@redhat.com>
Date:   Fri Jan 5 11:14:09 2018 -0800

    staging: android: ion: Switch from WARN to pr_warn
    
    commit e4e179a844f52e907e550f887d0a2171f1508af1 upstream.
    
    Syzbot reported a warning with Ion:
    
    WARNING: CPU: 0 PID: 3502 at drivers/staging/android/ion/ion-ioctl.c:73 ion_ioctl+0x2db/0x380 drivers/staging/android/ion/ion-ioctl.c:73
    Kernel panic - not syncing: panic_on_warn set ...
    
    This is a warning that validation of the ioctl fields failed. This was
    deliberately added as a warning to make it very obvious to developers that
    something needed to be fixed. In reality, this is overkill and disturbs
    fuzzing. Switch to pr_warn for a message instead.
    
    Reported-by: syzbot+fa2d5f63ee5904a0115a@syzkaller.appspotmail.com
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Laura Abbott <labbott@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 458d2fc92405836fc949c6779170dad18a508f0f
Author: Laura Abbott <labbott@redhat.com>
Date:   Fri Jan 5 11:14:08 2018 -0800

    staging: android: ion: Add __GFP_NOWARN for system contig heap
    
    commit 0c75f10312a35b149b2cebb1832316b35c2337ca upstream.
    
    syzbot reported a warning from Ion:
    
      WARNING: CPU: 1 PID: 3485 at mm/page_alloc.c:3926
    
      ...
       __alloc_pages_nodemask+0x9fb/0xd80 mm/page_alloc.c:4252
      alloc_pages_current+0xb6/0x1e0 mm/mempolicy.c:2036
      alloc_pages include/linux/gfp.h:492 [inline]
      ion_system_contig_heap_allocate+0x40/0x2c0
      drivers/staging/android/ion/ion_system_heap.c:374
      ion_buffer_create drivers/staging/android/ion/ion.c:93 [inline]
      ion_alloc+0x2c1/0x9e0 drivers/staging/android/ion/ion.c:420
      ion_ioctl+0x26d/0x380 drivers/staging/android/ion/ion-ioctl.c:84
      vfs_ioctl fs/ioctl.c:46 [inline]
      do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
      SYSC_ioctl fs/ioctl.c:701 [inline]
      SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
    
    This is a warning about attempting to allocate order > MAX_ORDER. This
    is coming from a userspace Ion allocation request. Since userspace is
    free to request however much memory it wants (and the kernel is free to
    deny its allocation), silence the allocation attempt with __GFP_NOWARN
    in case it fails.
    
    Reported-by: syzbot+76e7efc4748495855a4d@syzkaller.appspotmail.com
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Laura Abbott <labbott@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eda4a83657b8e289560b40bb2dc33ed3b654142f
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Dec 18 16:40:26 2017 -0800

    crypto: x86/twofish-3way - Fix %rbp usage
    
    commit d8c7fe9f2a486a6e5f0d5229ca43807af5ab22c6 upstream.
    
    Using %rbp as a temporary register breaks frame pointer convention and
    breaks stack traces when unwinding from an interrupt in the crypto code.
    
    In twofish-3way, we can't simply replace %rbp with another register
    because there are none available.  Instead, we use the stack to hold the
    values that %rbp, %r11, and %r12 were holding previously.  Each of these
    values represents the half of the output from the previous Feistel round
    that is being passed on unchanged to the following round.  They are only
    used once per round, when they are exchanged with %rax, %rbx, and %rcx.
    
    As a result, we free up 3 registers (one per block) and can reassign
    them so that %rbp is not used, and additionally %r14 and %r15 are not
    used so they do not need to be saved/restored.
    
    There may be a small overhead caused by replacing 'xchg REG, REG' with
    the needed sequence 'mov MEM, REG; mov REG, MEM; mov REG, REG' once per
    round.  But, counterintuitively, when I tested "ctr-twofish-3way" on a
    Haswell processor, the new version was actually about 2% faster.
    (Perhaps 'xchg' is not as well optimized as plain moves.)
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e6f51aac15ac93605187fd11b9bc75a240a53f8
Author: Paul Moore <paul@paul-moore.com>
Date:   Tue Dec 5 17:17:43 2017 -0500

    selinux: skip bounded transition processing if the policy isn't loaded
    
    commit 4b14752ec4e0d87126e636384cf37c8dd9df157c upstream.
    
    We can't do anything reasonable in security_bounded_transition() if we
    don't have a policy loaded, and in fact we could run into problems
    with some of the code inside expecting a policy.  Fix these problems
    like we do many others in security/selinux/ss/services.c by checking
    to see if the policy is loaded (ss_initialized) and returning quickly
    if it isn't.
    
    Reported-by: syzbot <syzkaller-bugs@googlegroups.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
    Reviewed-by: James Morris <james.l.morris@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe1cb580e84865f3c6be99b952a626323228e781
Author: Paul Moore <paul@paul-moore.com>
Date:   Tue Nov 28 18:51:12 2017 -0500

    selinux: ensure the context is NUL terminated in security_context_to_sid_core()
    
    commit ef28df55ac27e1e5cd122e19fa311d886d47a756 upstream.
    
    The syzbot/syzkaller automated tests found a problem in
    security_context_to_sid_core() during early boot (before we load the
    SELinux policy) where we could potentially feed context strings without
    NUL terminators into the strcmp() function.
    
    We already guard against this during normal operation (after the SELinux
    policy has been loaded) by making a copy of the context strings and
    explicitly adding a NUL terminator to the end.  The patch extends this
    protection to the early boot case (no loaded policy) by moving the context
    copy earlier in security_context_to_sid_core().
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Reviewed-By: William Roberts <william.c.roberts@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cab144f072bdae16f37a06efb0dad210c7ff7bb
Author: David Howells <dhowells@redhat.com>
Date:   Tue Jul 4 17:25:02 2017 +0100

    Provide a function to create a NUL-terminated string from unterminated data
    
    commit f35157417215ec138c920320c746fdb3e04ef1d5 upstream.
    
    Provide a function, kmemdup_nul(), that will create a NUL-terminated string
    from an unterminated character array where the length is known in advance.
    
    This is better than kstrndup() in situations where we already know the
    string length as the strnlen() in kstrndup() is superfluous.
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fd4db305f2750418151d2d5553bfaec2956167a
Author: Jason Wang <jasowang@redhat.com>
Date:   Fri Feb 9 17:45:49 2018 +0800

    ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE
    
    commit 6e6e41c3112276288ccaf80c70916779b84bb276 upstream.
    
    To avoid slab to warn about exceeded size, fail early if queue
    occupies more than KMALLOC_MAX_SIZE.
    
    Reported-by: syzbot+e4d4f9ddd4295539735d@syzkaller.appspotmail.com
    Fixes: 2e0ab8ca83c12 ("ptr_ring: array based FIFO for pointers")
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eeb1f9bd2480eab16f77aeafacec08c82f71a972
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Oct 31 11:55:35 2017 +0000

    drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all
    
    commit d18d1a5ac811d12f7ebc1129230312b5f2c50cb8 upstream.
    
    To acquire all modeset locks requires a ww_ctx to be allocated. As this
    is the legacy path and the allocation small, to reduce the changes
    required (and complex untested error handling) to the legacy drivers, we
    simply assume that the allocation succeeds. At present, it relies on the
    too-small-to-fail rule, but syzbot found that by injecting a failure
    here we would hit the WARN. Document that this allocation must succeed
    with __GFP_NOFAIL.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20171031115535.15166-1-chris@chris-wilson.co.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7569adcf396a2b17fcc45d4172c0857e60ed32df
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sun Nov 5 09:16:09 2017 -0700

    blktrace: fix unlocked registration of tracepoints
    
    commit a6da0024ffc19e0d47712bb5ca4fd083f76b07df upstream.
    
    We need to ensure that tracepoints are registered and unregistered
    with the users of them. The existing atomic count isn't enough for
    that. Add a lock around the tracepoints, so we serialize access
    to them.
    
    This fixes cases where we have multiple users setting up and
    tearing down tracepoints, like this:
    
    CPU: 0 PID: 2995 Comm: syzkaller857118 Not tainted
    4.14.0-rc5-next-20171018+ #36
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
    Google 01/01/2011
    Call Trace:
      __dump_stack lib/dump_stack.c:16 [inline]
      dump_stack+0x194/0x257 lib/dump_stack.c:52
      panic+0x1e4/0x41c kernel/panic.c:183
      __warn+0x1c4/0x1e0 kernel/panic.c:546
      report_bug+0x211/0x2d0 lib/bug.c:183
      fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:177
      do_trap_no_signal arch/x86/kernel/traps.c:211 [inline]
      do_trap+0x260/0x390 arch/x86/kernel/traps.c:260
      do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:297
      do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:310
      invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905
    RIP: 0010:tracepoint_add_func kernel/tracepoint.c:210 [inline]
    RIP: 0010:tracepoint_probe_register_prio+0x397/0x9a0 kernel/tracepoint.c:283
    RSP: 0018:ffff8801d1d1f6c0 EFLAGS: 00010293
    RAX: ffff8801d22e8540 RBX: 00000000ffffffef RCX: ffffffff81710f07
    RDX: 0000000000000000 RSI: ffffffff85b679c0 RDI: ffff8801d5f19818
    RBP: ffff8801d1d1f7c8 R08: ffffffff81710c10 R09: 0000000000000004
    R10: ffff8801d1d1f6b0 R11: 0000000000000003 R12: ffffffff817597f0
    R13: 0000000000000000 R14: 00000000ffffffff R15: ffff8801d1d1f7a0
      tracepoint_probe_register+0x2a/0x40 kernel/tracepoint.c:304
      register_trace_block_rq_insert include/trace/events/block.h:191 [inline]
      blk_register_tracepoints+0x1e/0x2f0 kernel/trace/blktrace.c:1043
      do_blk_trace_setup+0xa10/0xcf0 kernel/trace/blktrace.c:542
      blk_trace_setup+0xbd/0x180 kernel/trace/blktrace.c:564
      sg_ioctl+0xc71/0x2d90 drivers/scsi/sg.c:1089
      vfs_ioctl fs/ioctl.c:45 [inline]
      do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:685
      SYSC_ioctl fs/ioctl.c:700 [inline]
      SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
      entry_SYSCALL_64_fastpath+0x1f/0xbe
    RIP: 0033:0x444339
    RSP: 002b:00007ffe05bb5b18 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00000000006d66c0 RCX: 0000000000444339
    RDX: 000000002084cf90 RSI: 00000000c0481273 RDI: 0000000000000009
    RBP: 0000000000000082 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000206 R12: ffffffffffffffff
    R13: 00000000c0481273 R14: 0000000000000000 R15: 0000000000000000
    
    since we can now run these in parallel. Ensure that the exported helpers
    for doing this are grabbing the queue trace mutex.
    
    Reported-by: Steven Rostedt <rostedt@goodmis.org>
    Tested-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e6712234606ce4b155723f71a3c9f52128d9266
Author: Xin Long <lucien.xin@gmail.com>
Date:   Fri Nov 17 14:11:11 2017 +0800

    sctp: set frag_point in sctp_setsockopt_maxseg correctly
    
    commit ecca8f88da5c4260cc2bccfefd2a24976704c366 upstream.
    
    Now in sctp_setsockopt_maxseg user_frag or frag_point can be set with
    val >= 8 and val <= SCTP_MAX_CHUNK_LEN. But both checks are incorrect.
    
    val >= 8 means frag_point can even be less than SCTP_DEFAULT_MINSEGMENT.
    Then in sctp_datamsg_from_user(), when it's value is greater than cookie
    echo len and trying to bundle with cookie echo chunk, the first_len will
    overflow.
    
    The worse case is when it's value is equal as cookie echo len, first_len
    becomes 0, it will go into a dead loop for fragment later on. In Hangbin
    syzkaller testing env, oom was even triggered due to consecutive memory
    allocation in that loop.
    
    Besides, SCTP_MAX_CHUNK_LEN is the max size of the whole chunk, it should
    deduct the data header for frag_point or user_frag check.
    
    This patch does a proper check with SCTP_DEFAULT_MINSEGMENT subtracting
    the sctphdr and datahdr, SCTP_MAX_CHUNK_LEN subtracting datahdr when
    setting frag_point via sockopt. It also improves sctp_setsockopt_maxseg
    codes.
    
    Suggested-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Reported-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85552886b454b27588d4d7a01456ab5e82daaa47
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Mon Nov 27 11:15:16 2017 -0800

    xfrm: check id proto in validate_tmpl()
    
    commit 6a53b7593233ab9e4f96873ebacc0f653a55c3e1 upstream.
    
    syzbot reported a kernel warning in xfrm_state_fini(), which
    indicates that we have entries left in the list
    net->xfrm.state_all whose proto is zero. And
    xfrm_id_proto_match() doesn't consider them as a match with
    IPSEC_PROTO_ANY in this case.
    
    Proto with value 0 is probably not a valid value, at least
    verify_newsa_info() doesn't consider it valid either.
    
    This patch fixes it by checking the proto value in
    validate_tmpl() and rejecting invalid ones, like what iproute2
    does in xfrm_xfrmproto_getbyname().
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46b317167d01130c5cc98ad042b2955c58f14597
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Wed Nov 29 06:53:55 2017 +0100

    xfrm: Fix stack-out-of-bounds read on socket policy lookup.
    
    commit ddc47e4404b58f03e98345398fb12d38fe291512 upstream.
    
    When we do tunnel or beet mode, we pass saddr and daddr from the
    template to xfrm_state_find(), this is ok. On transport mode,
    we pass the addresses from the flowi, assuming that the IP
    addresses (and address family) don't change during transformation.
    This assumption is wrong in the IPv4 mapped IPv6 case, packet
    is IPv4 and template is IPv6.
    
    Fix this by catching address family missmatches of the policy
    and the flow already before we do the lookup.
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 274ee93f0b12ce1865579ea2bbb783642c72c31f
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Mon Dec 18 20:31:41 2017 +0900

    mm,vmscan: Make unregister_shrinker() no-op if register_shrinker() failed.
    
    commit bb422a738f6566f7439cd347d54e321e4fe92a9f upstream.
    
    Syzbot caught an oops at unregister_shrinker() because combination of
    commit 1d3d4437eae1bb29 ("vmscan: per-node deferred work") and fault
    injection made register_shrinker() fail and the caller of
    register_shrinker() did not check for failure.
    
    ----------
    [  554.881422] FAULT_INJECTION: forcing a failure.
    [  554.881422] name failslab, interval 1, probability 0, space 0, times 0
    [  554.881438] CPU: 1 PID: 13231 Comm: syz-executor1 Not tainted 4.14.0-rc8+ #82
    [  554.881443] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    [  554.881445] Call Trace:
    [  554.881459]  dump_stack+0x194/0x257
    [  554.881474]  ? arch_local_irq_restore+0x53/0x53
    [  554.881486]  ? find_held_lock+0x35/0x1d0
    [  554.881507]  should_fail+0x8c0/0xa40
    [  554.881522]  ? fault_create_debugfs_attr+0x1f0/0x1f0
    [  554.881537]  ? check_noncircular+0x20/0x20
    [  554.881546]  ? find_next_zero_bit+0x2c/0x40
    [  554.881560]  ? ida_get_new_above+0x421/0x9d0
    [  554.881577]  ? find_held_lock+0x35/0x1d0
    [  554.881594]  ? __lock_is_held+0xb6/0x140
    [  554.881628]  ? check_same_owner+0x320/0x320
    [  554.881634]  ? lock_downgrade+0x990/0x990
    [  554.881649]  ? find_held_lock+0x35/0x1d0
    [  554.881672]  should_failslab+0xec/0x120
    [  554.881684]  __kmalloc+0x63/0x760
    [  554.881692]  ? lock_downgrade+0x990/0x990
    [  554.881712]  ? register_shrinker+0x10e/0x2d0
    [  554.881721]  ? trace_event_raw_event_module_request+0x320/0x320
    [  554.881737]  register_shrinker+0x10e/0x2d0
    [  554.881747]  ? prepare_kswapd_sleep+0x1f0/0x1f0
    [  554.881755]  ? _down_write_nest_lock+0x120/0x120
    [  554.881765]  ? memcpy+0x45/0x50
    [  554.881785]  sget_userns+0xbcd/0xe20
    (...snipped...)
    [  554.898693] kasan: CONFIG_KASAN_INLINE enabled
    [  554.898724] kasan: GPF could be caused by NULL-ptr deref or user memory access
    [  554.898732] general protection fault: 0000 [#1] SMP KASAN
    [  554.898737] Dumping ftrace buffer:
    [  554.898741]    (ftrace buffer empty)
    [  554.898743] Modules linked in:
    [  554.898752] CPU: 1 PID: 13231 Comm: syz-executor1 Not tainted 4.14.0-rc8+ #82
    [  554.898755] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    [  554.898760] task: ffff8801d1dbe5c0 task.stack: ffff8801c9e38000
    [  554.898772] RIP: 0010:__list_del_entry_valid+0x7e/0x150
    [  554.898775] RSP: 0018:ffff8801c9e3f108 EFLAGS: 00010246
    [  554.898780] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
    [  554.898784] RDX: 0000000000000000 RSI: ffff8801c53c6f98 RDI: ffff8801c53c6fa0
    [  554.898788] RBP: ffff8801c9e3f120 R08: 1ffff100393c7d55 R09: 0000000000000004
    [  554.898791] R10: ffff8801c9e3ef70 R11: 0000000000000000 R12: 0000000000000000
    [  554.898795] R13: dffffc0000000000 R14: 1ffff100393c7e45 R15: ffff8801c53c6f98
    [  554.898800] FS:  0000000000000000(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
    [  554.898804] CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
    [  554.898807] CR2: 00000000dbc23000 CR3: 00000001c7269000 CR4: 00000000001406e0
    [  554.898813] DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000
    [  554.898816] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
    [  554.898818] Call Trace:
    [  554.898828]  unregister_shrinker+0x79/0x300
    [  554.898837]  ? perf_trace_mm_vmscan_writepage+0x750/0x750
    [  554.898844]  ? down_write+0x87/0x120
    [  554.898851]  ? deactivate_super+0x139/0x1b0
    [  554.898857]  ? down_read+0x150/0x150
    [  554.898864]  ? check_same_owner+0x320/0x320
    [  554.898875]  deactivate_locked_super+0x64/0xd0
    [  554.898883]  deactivate_super+0x141/0x1b0
    ----------
    
    Since allowing register_shrinker() callers to call unregister_shrinker()
    when register_shrinker() failed can simplify error recovery path, this
    patch makes unregister_shrinker() no-op when register_shrinker() failed.
    Also, reset shrinker->nr_deferred in case unregister_shrinker() was
    by error called twice.
    
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Aliaksei Karaliou <akaraliou.dev@gmail.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: Glauber Costa <glauber@scylladb.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d89917c5a0fbe2f5fe04bb15c6bcd0b1ebf4d24
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Dec 27 23:25:45 2017 +0100

    xfrm: skip policies marked as dead while rehashing
    
    commit 862591bf4f519d1b8d859af720fafeaebdd0162a upstream.
    
    syzkaller triggered following KASAN splat:
    
    BUG: KASAN: slab-out-of-bounds in xfrm_hash_rebuild+0xdbe/0xf00 net/xfrm/xfrm_policy.c:618
    read of size 2 at addr ffff8801c8e92fe4 by task kworker/1:1/23 [..]
    Workqueue: events xfrm_hash_rebuild [..]
     __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:428
     xfrm_hash_rebuild+0xdbe/0xf00 net/xfrm/xfrm_policy.c:618
     process_one_work+0xbbf/0x1b10 kernel/workqueue.c:2112
     worker_thread+0x223/0x1990 kernel/workqueue.c:2246 [..]
    
    The reproducer triggers:
    1016                 if (error) {
    1017                         list_move_tail(&walk->walk.all, &x->all);
    1018                         goto out;
    1019                 }
    
    in xfrm_policy_walk() via pfkey (it sets tiny rcv space, dump
    callback returns -ENOBUFS).
    
    In this case, *walk is located the pfkey socket struct, so this socket
    becomes visible in the global policy list.
    
    It looks like this is intentional -- phony walker has walk.dead set to 1
    and all other places skip such "policies".
    
    Ccing original authors of the two commits that seem to expose this
    issue (first patch missed ->dead check, second patch adds pfkey
    sockets to policies dumper list).
    
    Fixes: 880a6fab8f6ba5b ("xfrm: configure policy hash table thresholds by netlink")
    Fixes: 12a169e7d8f4b1c ("ipsec: Put dumpers on the dump list")
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Timo Teras <timo.teras@iki.fi>
    Cc: Christophe Gouault <christophe.gouault@6wind.com>
    Reported-by: syzbot <bot+c028095236fcb6f4348811565b75084c754dc729@syzkaller.appspotmail.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 758980347e174abf068ea9c8f20b6a891cffa683
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Jan 15 09:58:27 2018 +0100

    cfg80211: check dev_set_name() return value
    
    commit 59b179b48ce2a6076448a44531242ac2b3f6cef2 upstream.
    
    syzbot reported a warning from rfkill_alloc(), and after a while
    I think that the reason is that it was doing fault injection and
    the dev_set_name() failed, leaving the name NULL, and we didn't
    check the return value and got to rfkill_alloc() with a NULL name.
    Since we really don't want a NULL name, we ought to check the
    return value.
    
    Fixes: fb28ad35906a ("net: struct device - replace bus_id with dev_name(), dev_set_name()")
    Reported-by: syzbot+1ddfb3357e1d7bb5b5d3@syzkaller.appspotmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bb174afca6cdb90499bcd2c46e5d966d9976834
Author: Tom Herbert <tom@quantonium.net>
Date:   Wed Jan 24 12:35:40 2018 -0800

    kcm: Only allow TCP sockets to be attached to a KCM mux
    
    commit 581e7226a5d43f629eb6399a121f85f6a15f81be upstream.
    
    TCP sockets for IPv4 and IPv6 that are not listeners or in closed
    stated are allowed to be attached to a KCM mux.
    
    Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
    Reported-by: syzbot+8865eaff7f9acd593945@syzkaller.appspotmail.com
    Signed-off-by: Tom Herbert <tom@quantonium.net>
    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 085cbbda4b4cc7dd2ba63806346881c2c2e10107
Author: Tom Herbert <tom@quantonium.net>
Date:   Wed Jan 24 12:35:41 2018 -0800

    kcm: Check if sk_user_data already set in kcm_attach
    
    commit e5571240236c5652f3e079b1d5866716a7ad819c upstream.
    
    This is needed to prevent sk_user_data being overwritten.
    The check is done under the callback lock. This should prevent
    a socket from being attached twice to a KCM mux. It also prevents
    a socket from being attached for other use cases of sk_user_data
    as long as the other cases set sk_user_data under the lock.
    Followup work is needed to unify all the use cases of sk_user_data
    to use the same locking.
    
    Reported-by: syzbot+114b15f2be420a8886c3@syzkaller.appspotmail.com
    Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
    Signed-off-by: Tom Herbert <tom@quantonium.net>
    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 bd3ccdc6f922c6b7db4b7075d1b6596ddb986a98
Author: Jason Wang <jasowang@redhat.com>
Date:   Tue Jan 23 17:27:25 2018 +0800

    vhost: use mutex_lock_nested() in vhost_dev_lock_vqs()
    
    commit e9cb4239134c860e5f92c75bf5321bd377bb505b upstream.
    
    We used to call mutex_lock() in vhost_dev_lock_vqs() which tries to
    hold mutexes of all virtqueues. This may confuse lockdep to report a
    possible deadlock because of trying to hold locks belong to same
    class. Switch to use mutex_lock_nested() to avoid false positive.
    
    Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API")
    Reported-by: syzbot+dbb7c1161485e61b0241@syzkaller.appspotmail.com
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
