1. 27 Apr, 2017 1 commit
    • David Howells's avatar
      KEYS: Disallow keyrings beginning with '.' to be joined as session keyrings · 4cbbfd6a
      David Howells authored
      commit ee8f844e upstream.
      
      This fixes CVE-2016-9604.
      
      Keyrings whose name begin with a '.' are special internal keyrings and so
      userspace isn't allowed to create keyrings by this name to prevent
      shadowing.  However, the patch that added the guard didn't fix
      KEYCTL_JOIN_SESSION_KEYRING.  Not only can that create dot-named keyrings,
      it can also subscribe to them as a session keyring if they grant SEARCH
      permission to the user.
      
      This, for example, allows a root process to set .builtin_trusted_keys as
      its session keyring, at which point it has full access because now the
      possessor permissions are added.  This permits root to add extra public
      keys, thereby bypassing module verification.
      
      This also affects kexec and IMA.
      
      This can be tested by (as root):
      
      	keyctl session .builtin_trusted_keys
      	keyctl add user a a @s
      	keyctl list @s
      
      which on my test box gives me:
      
      	2 keys in keyring:
      	180010936: ---lswrv     0     0 asymmetric: Build time autogenerated kernel key: ae3d4a31b82daa8e1a75b49dc2bba949fd992a05
      	801382539: --alswrv     0     0 user: a
      
      
      Fix this by rejecting names beginning with a '.' in the keyctl.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      cc: linux-ima-devel@lists.sourceforge.net
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4cbbfd6a
  2. 21 Apr, 2017 39 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.10.12 · 055c0a94
      Greg Kroah-Hartman authored
      055c0a94
    • Omar Sandoval's avatar
      virtio-console: avoid DMA from stack · e5349c13
      Omar Sandoval authored
      commit c4baad50 upstream.
      
      put_chars() stuffs the buffer it gets into an sg, but that buffer may be
      on the stack. This breaks with CONFIG_VMAP_STACK=y (for me, it
      manifested as printks getting turned into NUL bytes).
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: default avatarAmit Shah <amit.shah@redhat.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Brad Spengler <spender@grsecurity.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e5349c13
    • Stefan Brüns's avatar
      cxusb: Use a dma capable buffer also for reading · e0116f4d
      Stefan Brüns authored
      commit 3f190e3a upstream.
      
      Commit 17ce039b ("[media] cxusb: don't do DMA on stack")
      added a kmalloc'ed bounce buffer for writes, but missed to do the same
      for reads. As the read only happens after the write is finished, we can
      reuse the same buffer.
      
      As dvb_usb_generic_rw handles a read length of 0 by itself, avoid calling
      it using the dvb_usb_generic_read wrapper function.
      Signed-off-by: default avatarStefan Brüns <stefan.bruens@rwth-aachen.de>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Brad Spengler <spender@grsecurity.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e0116f4d
    • Kees Cook's avatar
      mm: Tighten x86 /dev/mem with zeroing reads · b1bfb508
      Kees Cook authored
      commit a4866aa8 upstream.
      
      Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
      disallowed. However, on x86, the first 1MB was always allowed for BIOS
      and similar things, regardless of it actually being System RAM. It was
      possible for heap to end up getting allocated in low 1MB RAM, and then
      read by things like x86info or dd, which would trip hardened usercopy:
      
      usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes)
      
      This changes the x86 exception for the low 1MB by reading back zeros for
      System RAM areas instead of blindly allowing them. More work is needed to
      extend this to mmap, but currently mmap doesn't go through usercopy, so
      hardened usercopy won't Oops the kernel.
      Reported-by: default avatarTommi Rantala <tommi.t.rantala@nokia.com>
      Tested-by: default avatarTommi Rantala <tommi.t.rantala@nokia.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Brad Spengler <spender@grsecurity.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1bfb508
    • Thierry Reding's avatar
      rtc: tegra: Implement clock handling · 2c4d8f20
      Thierry Reding authored
      commit 5fa40869 upstream.
      
      Accessing the registers of the RTC block on Tegra requires the module
      clock to be enabled. This only works because the RTC module clock will
      be enabled by default during early boot. However, because the clock is
      unused, the CCF will disable it at late_init time. This causes the RTC
      to become unusable afterwards. This can easily be reproduced by trying
      to use the RTC:
      
      	$ hwclock --rtc /dev/rtc1
      
      This will hang the system. I ran into this by following up on a report
      by Martin Michlmayr that reboot wasn't working on Tegra210 systems. It
      turns out that the rtc-tegra driver's ->shutdown() implementation will
      hang the CPU, because of the disabled clock, before the system can be
      rebooted.
      
      What confused me for a while is that the same driver is used on prior
      Tegra generations where the hang can not be observed. However, as Peter
      De Schrijver pointed out, this is because on 32-bit Tegra chips the RTC
      clock is enabled by the tegra20_timer.c clocksource driver, which uses
      the RTC to provide a persistent clock. This code is never enabled on
      64-bit Tegra because the persistent clock infrastructure does not exist
      on 64-bit ARM.
      
      The proper fix for this is to add proper clock handling to the RTC
      driver in order to ensure that the clock is enabled when the driver
      requires it. All device trees contain the clock already, therefore
      no additional changes are required.
      Reported-by: default avatarMartin Michlmayr <tbm@cyrius.com>
      Acked-By Peter De Schrijver <pdeschrijver@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      [bwh: Backported to 4.9: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2c4d8f20
    • Lv Zheng's avatar
      ACPI / EC: Use busy polling mode when GPE is not enabled · a16534a3
      Lv Zheng authored
      commit c3a696b6 upstream.
      
      When GPE is not enabled, it is not efficient to use the wait polling mode
      as it introduces an unexpected scheduler delay.
      So before the GPE handler is installed, this patch uses busy polling mode
      for all EC(s) and the logic can be applied to non boot EC(s) during the
      suspend/resume process.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=191561Tested-by: default avatarJakobus Schurz <jakobus.schurz@gmail.com>
      Tested-by: default avatarChen Yu <yu.c.chen@intel.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a16534a3
    • Mohit Gambhir's avatar
      x86/xen: Fix APIC id mismatch warning on Intel · 8a73a223
      Mohit Gambhir authored
      commit cc272163 upstream.
      
      This patch fixes the following warning message seen when booting the
      kernel as Dom0 with Xen on Intel machines.
      
      [0.003000] [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 0 APIC: 1]
      
      The code generating the warning in validate_apic_and_package_id() matches
      cpu_data(cpu).apicid (initialized in init_intel()->
      detect_extended_topology() using cpuid) against the apicid returned from
      xen_apic_read(). Now, xen_apic_read() makes a hypercall to retrieve apicid
      for the boot  cpu but returns 0 otherwise. Hence the warning gets thrown
      for all but the boot cpu.
      
      The idea behind xen_apic_read() returning 0 for apicid is that the
      guests (even Dom0) should not need to know what physical processor their
      vcpus are running on. This is because we currently  do not have topology
      information in Xen and also because xen allows more vcpus than physical
      processors. However, boot cpu's apicid is required for loading
      xen-acpi-processor driver on AMD machines. Look at following patch for
      details:
      
      commit 558daa28 ("xen/apic: Return the APIC ID (and version) for CPU
      0.")
      
      So to get rid of the warning, this patch modifies
      xen_cpu_present_to_apicid() to return cpu_data(cpu).apicid instead of
      calling xen_apic_read().
      
      The warning is not seen on AMD machines because init_amd() populates
      cpu_data(cpu).apicid by calling hard_smp_processor_id()->xen_apic_read()
      as opposed to using apicid from cpuid as is done on Intel machines.
      Signed-off-by: default avatarMohit Gambhir <mohit.gambhir@oracle.com>
      Reviewed-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8a73a223
    • Lee, Chun-Yi's avatar
      platform/x86: acer-wmi: setup accelerometer when machine has appropriate notify event · e765ef79
      Lee, Chun-Yi authored
      commit 98d610c3 upstream.
      
      The accelerometer event relies on the ACERWMID_EVENT_GUID notify.
      So, this patch changes the codes to setup accelerometer input device
      when detected ACERWMID_EVENT_GUID. It avoids that the accel input
      device created on every Acer machines.
      
      In addition, patch adds a clearly parsing logic of accelerometer hid
      to acer_wmi_get_handle_cb callback function. It is positive matching
      the "SENR" name with "BST0001" device to avoid non-supported hardware.
      Reported-by: default avatarBjørn Mork <bjorn@mork.no>
      Cc: Darren Hart <dvhart@infradead.org>
      Signed-off-by: default avatarLee, Chun-Yi <jlee@suse.com>
      [andy: slightly massage commit message]
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e765ef79
    • Andy Shevchenko's avatar
      ASoC: Intel: select DW_DMAC_CORE since it's mandatory · 35549ee0
      Andy Shevchenko authored
      commit ebf79091 upstream.
      
      Select DW_DMAC_CORE like the rest of glue drivers do, e.g.
      drivers/dma/dw/Kconfig.
      
      While here group selectors under SND_SOC_INTEL_HASWELL and
      SND_SOC_INTEL_BAYTRAIL.
      
      Make platforms, which are using a common SST firmware driver, to be
      dependent on DMADEVICES.
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: default avatarLiam Girdwood <liam.r.girdwood@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      35549ee0
    • Arnd Bergmann's avatar
      dvb-usb-v2: avoid use-after-free · 765c74b9
      Arnd Bergmann authored
      commit 00514537 upstream.
      
      I ran into a stack frame size warning because of the on-stack copy of
      the USB device structure:
      
      drivers/media/usb/dvb-usb-v2/dvb_usb_core.c: In function 'dvb_usbv2_disconnect':
      drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:1029:1: error: the frame size of 1104 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
      
      Copying a device structure like this is wrong for a number of other reasons
      too aside from the possible stack overflow. One of them is that the
      dev_info() call will print the name of the device later, but AFAICT
      we have only copied a pointer to the name earlier and the actual name
      has been freed by the time it gets printed.
      
      This removes the on-stack copy of the device and instead copies the
      device name using kstrdup(). I'm ignoring the possible failure here
      as both printk() and kfree() are able to deal with NULL pointers.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      765c74b9
    • Helge Deller's avatar
      parisc: Fix get_user() for 64-bit value on 32-bit kernel · ce5fe5a5
      Helge Deller authored
      commit 3f795cef upstream.
      
      This fixes a bug in which the upper 32-bits of a 64-bit value which is
      read by get_user() was lost on a 32-bit kernel.
      While touching this code, split out pre-loading of %sr2 space register
      and clean up code indent.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce5fe5a5
    • Herbert Xu's avatar
      crypto: lrw - Fix use-after-free on EINPROGRESS · aa7ca04f
      Herbert Xu authored
      commit 4702bbee upstream.
      
      When we get an EINPROGRESS completion in lrw, we will end up marking
      the request as done and freeing it.  This then blows up when the
      request is really completed as we've already freed the memory.
      
      Fixes: 700cb3f5 ("crypto: lrw - Convert to skcipher")
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aa7ca04f
    • Herbert Xu's avatar
      crypto: ahash - Fix EINPROGRESS notification callback · cb0567fc
      Herbert Xu authored
      commit ef0579b6 upstream.
      
      The ahash API modifies the request's callback function in order
      to clean up after itself in some corner cases (unaligned final
      and missing finup).
      
      When the request is complete ahash will restore the original
      callback and everything is fine.  However, when the request gets
      an EBUSY on a full queue, an EINPROGRESS callback is made while
      the request is still ongoing.
      
      In this case the ahash API will incorrectly call its own callback.
      
      This patch fixes the problem by creating a temporary request
      object on the stack which is used to relay EINPROGRESS back to
      the original completion function.
      
      This patch also adds code to preserve the original flags value.
      
      Fixes: ab6bf4e5 ("crypto: hash - Fix the pointer voodoo in...")
      Reported-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Tested-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cb0567fc
    • Herbert Xu's avatar
      crypto: xts - Fix use-after-free on EINPROGRESS · 102da3a7
      Herbert Xu authored
      commit aa4a829b upstream.
      
      When we get an EINPROGRESS completion in xts, we will end up marking
      the request as done and freeing it.  This then blows up when the
      request is really completed as we've already freed the memory.
      
      Fixes: f1c131b4 ("crypto: xts - Convert to skcipher")
      Reported-by: default avatarNathan Royce <nroycea+kernel@gmail.com>
      Reported-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Tested-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      102da3a7
    • Herbert Xu's avatar
      crypto: algif_aead - Fix bogus request dereference in completion function · 25308983
      Herbert Xu authored
      commit e6534aeb upstream.
      
      The algif_aead completion function tries to deduce the aead_request
      from the crypto_async_request argument.  This is broken because
      the API does not guarantee that the same request will be pased to
      the completion function.  Only the value of req->data can be used
      in the completion function.
      
      This patch fixes it by storing a pointer to sk in areq and using
      that instead of passing in sk through req->data.
      
      Fixes: 83094e5e ("crypto: af_alg - add async support to...")
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      25308983
    • Namhyung Kim's avatar
      ftrace: Fix function pid filter on instances · a0a1e90f
      Namhyung Kim authored
      commit d879d0b8 upstream.
      
      When function tracer has a pid filter, it adds a probe to sched_switch
      to track if current task can be ignored.  The probe checks the
      ftrace_ignore_pid from current tr to filter tasks.  But it misses to
      delete the probe when removing an instance so that it can cause a crash
      due to the invalid tr pointer (use-after-free).
      
      This is easily reproducible with the following:
      
        # cd /sys/kernel/debug/tracing
        # mkdir instances/buggy
        # echo $$ > instances/buggy/set_ftrace_pid
        # rmdir instances/buggy
      
        ============================================================================
        BUG: KASAN: use-after-free in ftrace_filter_pid_sched_switch_probe+0x3d/0x90
        Read of size 8 by task kworker/0:1/17
        CPU: 0 PID: 17 Comm: kworker/0:1 Tainted: G    B           4.11.0-rc3  #198
        Call Trace:
         dump_stack+0x68/0x9f
         kasan_object_err+0x21/0x70
         kasan_report.part.1+0x22b/0x500
         ? ftrace_filter_pid_sched_switch_probe+0x3d/0x90
         kasan_report+0x25/0x30
         __asan_load8+0x5e/0x70
         ftrace_filter_pid_sched_switch_probe+0x3d/0x90
         ? fpid_start+0x130/0x130
         __schedule+0x571/0xce0
         ...
      
      To fix it, use ftrace_clear_pids() to unregister the probe.  As
      instance_rmdir() already updated ftrace codes, it can just free the
      filter safely.
      
      Link: http://lkml.kernel.org/r/20170417024430.21194-2-namhyung@kernel.org
      
      Fixes: 0c8916c3 ("tracing: Add rmdir to remove multibuffer instances")
      Cc: Ingo Molnar <mingo@kernel.org>
      Reviewed-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a0a1e90f
    • Minchan Kim's avatar
      zram: do not use copy_page with non-page aligned address · 58bc856c
      Minchan Kim authored
      commit d72e9a7a upstream.
      
      The copy_page is optimized memcpy for page-alinged address.  If it is
      used with non-page aligned address, it can corrupt memory which means
      system corruption.  With zram, it can happen with
      
      1. 64K architecture
      2. partial IO
      3. slub debug
      
      Partial IO need to allocate a page and zram allocates it via kmalloc.
      With slub debug, kmalloc(PAGE_SIZE) doesn't return page-size aligned
      address.  And finally, copy_page(mem, cmem) corrupts memory.
      
      So, this patch changes it to memcpy.
      
      Actuaully, we don't need to change zram_bvec_write part because zsmalloc
      returns page-aligned address in case of PAGE_SIZE class but it's not
      good to rely on the internal of zsmalloc.
      
      Note:
       When this patch is merged to stable, clear_page should be fixed, too.
       Unfortunately, recent zram removes it by "same page merge" feature so
       it's hard to backport this patch to -stable tree.
      
      I will handle it when I receive the mail from stable tree maintainer to
      merge this patch to backport.
      
      Fixes: 42e99bd9 ("zram: optimize memory operations with clear_page()/copy_page()")
      Link: http://lkml.kernel.org/r/1492042622-12074-2-git-send-email-minchan@kernel.orgSigned-off-by: default avatarMinchan Kim <minchan@kernel.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      58bc856c
    • Greg Kroah-Hartman's avatar
      Revert "MIPS: Lantiq: Fix cascaded IRQ setup" · 9bf69094
      Greg Kroah-Hartman authored
      This reverts commit b576c583 which is
      commit 6c356eda upstream.
      
      It shouldn't have been included in a stable release.
      Reported-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Cc: Felix Fietkau <nbd@nbd.name>
      Cc: John Crispin <john@phrozen.org>
      Cc: James Hogan <james.hogan@imgtec.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9bf69094
    • Max Bires's avatar
      char: lack of bool string made CONFIG_DEVPORT always on · 1cb293ab
      Max Bires authored
      commit f2cfa58b upstream.
      
      Without a bool string present, using "# CONFIG_DEVPORT is not set" in
      defconfig files would not actually unset devport. This esnured that
      /dev/port was always on, but there are reasons a user may wish to
      disable it (smaller kernel, attack surface reduction) if it's not being
      used. Adding a message here in order to make this user visible.
      Signed-off-by: default avatarMax Bires <jbires@google.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1cb293ab
    • Min He's avatar
      drm/i915/gvt: set the correct default value of CTX STATUS PTR · ebe4deab
      Min He authored
      commit a34f8363 upstream.
      
      Fix wrong initial csb read pointer value. This fixes the random
      engine timeout issue in guest when guest boots up.
      
      Fixes: 8453d674 ("drm/i915/gvt: vGPU execlist virtualization")
      Signed-off-by: default avatarMin He <min.he@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ebe4deab
    • Steven Rostedt (VMware)'s avatar
      ftrace: Fix removing of second function probe · 4bf7df7b
      Steven Rostedt (VMware) authored
      commit 82cc4fc2 upstream.
      
      When two function probes are added to set_ftrace_filter, and then one of
      them is removed, the update to the function locations is not performed, and
      the record keeping of the function states are corrupted, and causes an
      ftrace_bug() to occur.
      
      This is easily reproducable by adding two probes, removing one, and then
      adding it back again.
      
       # cd /sys/kernel/debug/tracing
       # echo schedule:traceoff > set_ftrace_filter
       # echo do_IRQ:traceoff > set_ftrace_filter
       # echo \!do_IRQ:traceoff > /debug/tracing/set_ftrace_filter
       # echo do_IRQ:traceoff > set_ftrace_filter
      
      Causes:
       ------------[ cut here ]------------
       WARNING: CPU: 2 PID: 1098 at kernel/trace/ftrace.c:2369 ftrace_get_addr_curr+0x143/0x220
       Modules linked in: [...]
       CPU: 2 PID: 1098 Comm: bash Not tainted 4.10.0-test+ #405
       Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
       Call Trace:
        dump_stack+0x68/0x9f
        __warn+0x111/0x130
        ? trace_irq_work_interrupt+0xa0/0xa0
        warn_slowpath_null+0x1d/0x20
        ftrace_get_addr_curr+0x143/0x220
        ? __fentry__+0x10/0x10
        ftrace_replace_code+0xe3/0x4f0
        ? ftrace_int3_handler+0x90/0x90
        ? printk+0x99/0xb5
        ? 0xffffffff81000000
        ftrace_modify_all_code+0x97/0x110
        arch_ftrace_update_code+0x10/0x20
        ftrace_run_update_code+0x1c/0x60
        ftrace_run_modify_code.isra.48.constprop.62+0x8e/0xd0
        register_ftrace_function_probe+0x4b6/0x590
        ? ftrace_startup+0x310/0x310
        ? debug_lockdep_rcu_enabled.part.4+0x1a/0x30
        ? update_stack_state+0x88/0x110
        ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320
        ? preempt_count_sub+0x18/0xd0
        ? mutex_lock_nested+0x104/0x800
        ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320
        ? __unwind_start+0x1c0/0x1c0
        ? _mutex_lock_nest_lock+0x800/0x800
        ftrace_trace_probe_callback.isra.3+0xc0/0x130
        ? func_set_flag+0xe0/0xe0
        ? __lock_acquire+0x642/0x1790
        ? __might_fault+0x1e/0x20
        ? trace_get_user+0x398/0x470
        ? strcmp+0x35/0x60
        ftrace_trace_onoff_callback+0x48/0x70
        ftrace_regex_write.isra.43.part.44+0x251/0x320
        ? match_records+0x420/0x420
        ftrace_filter_write+0x2b/0x30
        __vfs_write+0xd7/0x330
        ? do_loop_readv_writev+0x120/0x120
        ? locks_remove_posix+0x90/0x2f0
        ? do_lock_file_wait+0x160/0x160
        ? __lock_is_held+0x93/0x100
        ? rcu_read_lock_sched_held+0x5c/0xb0
        ? preempt_count_sub+0x18/0xd0
        ? __sb_start_write+0x10a/0x230
        ? vfs_write+0x222/0x240
        vfs_write+0xef/0x240
        SyS_write+0xab/0x130
        ? SyS_read+0x130/0x130
        ? trace_hardirqs_on_caller+0x182/0x280
        ? trace_hardirqs_on_thunk+0x1a/0x1c
        entry_SYSCALL_64_fastpath+0x18/0xad
       RIP: 0033:0x7fe61c157c30
       RSP: 002b:00007ffe87890258 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
       RAX: ffffffffffffffda RBX: ffffffff8114a410 RCX: 00007fe61c157c30
       RDX: 0000000000000010 RSI: 000055814798f5e0 RDI: 0000000000000001
       RBP: ffff8800c9027f98 R08: 00007fe61c422740 R09: 00007fe61ca53700
       R10: 0000000000000073 R11: 0000000000000246 R12: 0000558147a36400
       R13: 00007ffe8788f160 R14: 0000000000000024 R15: 00007ffe8788f15c
        ? trace_hardirqs_off_caller+0xc0/0x110
       ---[ end trace 99fa09b3d9869c2c ]---
       Bad trampoline accounting at: ffffffff81cc3b00 (do_IRQ+0x0/0x150)
      
      Fixes: 59df055f ("ftrace: trace different functions with a different tracer")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4bf7df7b
    • Tyler Baker's avatar
      irqchip/irq-imx-gpcv2: Fix spinlock initialization · 9b35ab51
      Tyler Baker authored
      commit 75eb5e1e upstream.
      
      The raw_spinlock in the IMX GPCV2 interupt chip is not initialized before
      usage. That results in a lockdep splat:
      
        INFO: trying to register non-static key.
        the code is fine but needs lockdep annotation.
        turning off the locking correctness validator.
      
      Add the missing raw_spin_lock_init() to the setup code.
      
      Fixes: e324c4dc ("irqchip/imx-gpcv2: IMX GPCv2 driver for wakeup sources")
      Signed-off-by: default avatarTyler Baker <tyler.baker@linaro.org>
      Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      Cc: jason@lakedaemon.net
      Cc: marc.zyngier@arm.com
      Cc: shawnguo@kernel.org
      Cc: andrew.smirnov@gmail.com
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/20170413222731.5917-1-tyler.baker@linaro.orgSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b35ab51
    • Chen Yu's avatar
      cpufreq: Bring CPUs up even if cpufreq_online() failed · b6486790
      Chen Yu authored
      commit c4a3fa26 upstream.
      
      There is a report that after commit 27622b06 ("cpufreq: Convert
      to hotplug state machine"), the normal CPU offline/online cycle
      fails on some platforms.
      
      According to the ftrace result, this problem was triggered on
      platforms using acpi-cpufreq as the default cpufreq driver,
      and due to the lack of some ACPI freq method (eg. _PCT),
      cpufreq_online() failed and returned a negative value, so the CPU
      hotplug state machine rolled back the CPU online process.  Actually,
      from the user's perspective, the failure of cpufreq_online() should
      not prevent that CPU from being brought up, although cpufreq might
      not work on that CPU.
      
      BTW, during system startup cpufreq_online() is not invoked via CPU
      online but by the cpufreq device creation process, so the APs can be
      brought up even though cpufreq_online() fails in that stage.
      
      This patch ignores the return value of cpufreq_online/offline() and
      lets the cpufreq framework deal with the failure.  cpufreq_online()
      itself will do a proper rollback in that case and if _PCT is missing,
      the ACPI cpufreq driver will print a warning if the corresponding
      debug options have been enabled.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=194581
      Fixes: 27622b06 ("cpufreq: Convert to hotplug state machine")
      Reported-and-tested-by: default avatarTomasz Maciej Nowak <tmn505@gmail.com>
      Signed-off-by: default avatarChen Yu <yu.c.chen@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b6486790
    • David Wu's avatar
      pwm: rockchip: State of PWM clock should synchronize with PWM enabled state · 26052e29
      David Wu authored
      commit a900152b upstream.
      
      If the PWM was not enabled at U-Boot loader, PWM could not work for
      clock always disabled at PWM driver. The PWM clock is enabled at
      beginning of pwm_apply(), but disabled at end of pwm_apply().
      
      If the PWM was enabled at U-Boot loader, PWM clock is always enabled
      unless closed by ATF. The pwm-backlight might turn off the power at
      early suspend, should disable PWM clock for saving power consume.
      
      It is important to provide opportunity to enable/disable clock at PWM
      driver, the PWM consumer should ensure correct order to call PWM enable
      and disable, and PWM driver ensure state of PWM clock synchronized with
      PWM enabled state.
      
      Fixes: 2bf1c98a ("pwm: rockchip: Add support for atomic update")
      Signed-off-by: default avatarDavid Wu <david.wu@rock-chips.com>
      Reviewed-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarThierry Reding <thierry.reding@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      26052e29
    • Markus Marb's avatar
      can: ifi: use correct register to read rx status · 96b121b5
      Markus Marb authored
      commit 57c1d4c3 upstream.
      
      The incorrect offset was used when trying to read the RXSTCMD register.
      Signed-off-by: default avatarMarkus Marb <markus@marb.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96b121b5
    • Dan Williams's avatar
      libnvdimm: band aid btt vs clear poison locking · 5b750d3c
      Dan Williams authored
      commit 4aa5615e upstream.
      
      The following warning results from holding a lane spinlock,
      preempt_disable(), or the btt map spinlock and then trying to take the
      reconfig_mutex to walk the poison list and potentially add new entries.
      
       BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747
       in_atomic(): 1, irqs_disabled(): 0, pid: 17159, name: dd
       [..]
       Call Trace:
        dump_stack+0x85/0xc8
        ___might_sleep+0x184/0x250
        __might_sleep+0x4a/0x90
        __mutex_lock+0x58/0x9b0
        ? nvdimm_bus_lock+0x21/0x30 [libnvdimm]
        ? __nvdimm_bus_badblocks_clear+0x2f/0x60 [libnvdimm]
        ? acpi_nfit_forget_poison+0x79/0x80 [nfit]
        ? _raw_spin_unlock+0x27/0x40
        mutex_lock_nested+0x1b/0x20
        nvdimm_bus_lock+0x21/0x30 [libnvdimm]
        nvdimm_forget_poison+0x25/0x50 [libnvdimm]
        nvdimm_clear_poison+0x106/0x140 [libnvdimm]
        nsio_rw_bytes+0x164/0x270 [libnvdimm]
        btt_write_pg+0x1de/0x3e0 [nd_btt]
        ? blk_queue_enter+0x30/0x290
        btt_make_request+0x11a/0x310 [nd_btt]
        ? blk_queue_enter+0xb7/0x290
        ? blk_queue_enter+0x30/0x290
        generic_make_request+0x118/0x3b0
      
      As a minimal fix, disable error clearing when the BTT is enabled for the
      namespace. For the final fix a larger rework of the poison list locking
      is needed.
      
      Note that this is not a problem in the blk case since that path never
      calls nvdimm_clear_poison().
      
      Fixes: 82bf1037 ("libnvdimm: check and clear poison before writing to pmem")
      Cc: Dave Jiang <dave.jiang@intel.com>
      [jeff: dynamically disable error clearing in the btt case]
      Suggested-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Reviewed-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Reported-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5b750d3c
    • Dan Williams's avatar
      libnvdimm: fix reconfig_mutex, mmap_sem, and jbd2_handle lockdep splat · f0f30671
      Dan Williams authored
      commit 0beb2012 upstream.
      
      Holding the reconfig_mutex over a potential userspace fault sets up a
      lockdep dependency chain between filesystem-DAX and the libnvdimm ioctl
      path. Move the user access outside of the lock.
      
           [ INFO: possible circular locking dependency detected ]
           4.11.0-rc3+ #13 Tainted: G        W  O
           -------------------------------------------------------
           fallocate/16656 is trying to acquire lock:
            (&nvdimm_bus->reconfig_mutex){+.+.+.}, at: [<ffffffffa00080b1>] nvdimm_bus_lock+0x21/0x30 [libnvdimm]
           but task is already holding lock:
            (jbd2_handle){++++..}, at: [<ffffffff813b4944>] start_this_handle+0x104/0x460
      
          which lock already depends on the new lock.
      
          the existing dependency chain (in reverse order) is:
      
          -> #2 (jbd2_handle){++++..}:
                  lock_acquire+0xbd/0x200
                  start_this_handle+0x16a/0x460
                  jbd2__journal_start+0xe9/0x2d0
                  __ext4_journal_start_sb+0x89/0x1c0
                  ext4_dirty_inode+0x32/0x70
                  __mark_inode_dirty+0x235/0x670
                  generic_update_time+0x87/0xd0
                  touch_atime+0xa9/0xd0
                  ext4_file_mmap+0x90/0xb0
                  mmap_region+0x370/0x5b0
                  do_mmap+0x415/0x4f0
                  vm_mmap_pgoff+0xd7/0x120
                  SyS_mmap_pgoff+0x1c5/0x290
                  SyS_mmap+0x22/0x30
                  entry_SYSCALL_64_fastpath+0x1f/0xc2
      
          -> #1 (&mm->mmap_sem){++++++}:
                  lock_acquire+0xbd/0x200
                  __might_fault+0x70/0xa0
                  __nd_ioctl+0x683/0x720 [libnvdimm]
                  nvdimm_ioctl+0x8b/0xe0 [libnvdimm]
                  do_vfs_ioctl+0xa8/0x740
                  SyS_ioctl+0x79/0x90
                  do_syscall_64+0x6c/0x200
                  return_from_SYSCALL_64+0x0/0x7a
      
          -> #0 (&nvdimm_bus->reconfig_mutex){+.+.+.}:
                  __lock_acquire+0x16b6/0x1730
                  lock_acquire+0xbd/0x200
                  __mutex_lock+0x88/0x9b0
                  mutex_lock_nested+0x1b/0x20
                  nvdimm_bus_lock+0x21/0x30 [libnvdimm]
                  nvdimm_forget_poison+0x25/0x50 [libnvdimm]
                  nvdimm_clear_poison+0x106/0x140 [libnvdimm]
                  pmem_do_bvec+0x1c2/0x2b0 [nd_pmem]
                  pmem_make_request+0xf9/0x270 [nd_pmem]
                  generic_make_request+0x118/0x3b0
                  submit_bio+0x75/0x150
      
      Fixes: 62232e45 ("libnvdimm: control (ioctl) messages for nvdimm_bus and nvdimm devices")
      Cc: Dave Jiang <dave.jiang@intel.com>
      Reported-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0f30671
    • Dan Williams's avatar
      libnvdimm: fix blk free space accounting · e0d47228
      Dan Williams authored
      commit fe514739 upstream.
      
      Commit a1f3e4d6 "libnvdimm, region: update nd_region_available_dpa()
      for multi-pmem support" reworked blk dpa (DIMM Physical Address)
      accounting to comprehend multiple pmem namespace allocations aliasing
      with a given blk-dpa range.
      
      The following call trace is a result of failing to account for allocated
      blk capacity.
      
       WARNING: CPU: 1 PID: 2433 at tools/testing/nvdimm/../../../drivers/nvdimm/names
      4 size_store+0x6f3/0x930 [libnvdimm]
       nd_region region5: allocation underrun: 0x0 of 0x1000000 bytes
       [..]
       Call Trace:
        dump_stack+0x86/0xc3
        __warn+0xcb/0xf0
        warn_slowpath_fmt+0x5f/0x80
        size_store+0x6f3/0x930 [libnvdimm]
        dev_attr_store+0x18/0x30
      
      If a given blk-dpa allocation does not alias with any pmem ranges then
      the full allocation should be accounted as busy space, not the size of
      the current pmem contribution to the region.
      
      The thinkos that led to this confusion was not realizing that the struct
      resource management is already guaranteeing no collisions between pmem
      allocations and blk allocations on the same dimm. Also, we do not try to
      support blk allocations in aliased pmem holes.
      
      This patch also fixes a case where the available blk goes negative.
      
      Fixes: a1f3e4d6 ("libnvdimm, region: update nd_region_available_dpa() for multi-pmem support").
      Reported-by: default avatarDariusz Dokupil <dariusz.dokupil@intel.com>
      Reported-by: default avatarDave Jiang <dave.jiang@intel.com>
      Reported-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Tested-by: default avatarDave Jiang <dave.jiang@intel.com>
      Tested-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e0d47228
    • Al Viro's avatar
      make skb_copy_datagram_msg() et.al. preserve ->msg_iter on error · 66481ca0
      Al Viro authored
      commit 32786821 upstream.
      
      Fixes the mess observed in e.g. rsync over a noisy link we'd been
      seeing since last Summer.  What happens is that we copy part of
      a datagram before noticing a checksum mismatch.  Datagram will be
      resent, all right, but we want the next try go into the same place,
      not after it...
      
      All this family of primitives (copy/checksum and copy a datagram
      into destination) is "all or nothing" sort of interface - either
      we get 0 (meaning that copy had been successful) or we get an
      error (and no way to tell how much had been copied before we ran
      into whatever error it had been).  Make all of them leave iterator
      unadvanced in case of errors - all callers must be able to cope
      with that (an error might've been caught before the iterator had
      been advanced), it costs very little to arrange, it's safer for
      callers and actually fixes at least one bug in said callers.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      66481ca0
    • Al Viro's avatar
      new privimitive: iov_iter_revert() · a99a9ff2
      Al Viro authored
      commit 27c0e374 upstream.
      
      opposite to iov_iter_advance(); the caller is responsible for never
      using it to move back past the initial position.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a99a9ff2
    • Juergen Gross's avatar
      xen, fbfront: fix connecting to backend · 939707c5
      Juergen Gross authored
      commit 9121b15b upstream.
      
      Connecting to the backend isn't working reliably in xen-fbfront: in
      case XenbusStateInitWait of the backend has been missed the backend
      transition to XenbusStateConnected will trigger the connected state
      only without doing the actions required when the backend has
      connected.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      939707c5
    • Nicholas Bellinger's avatar
      target: Avoid mappedlun symlink creation during lun shutdown · 22113847
      Nicholas Bellinger authored
      commit 49cb77e2 upstream.
      
      This patch closes a race between se_lun deletion during configfs
      unlink in target_fabric_port_unlink() -> core_dev_del_lun()
      -> core_tpg_remove_lun(), when transport_clear_lun_ref() blocks
      waiting for percpu_ref RCU grace period to finish, but a new
      NodeACL mappedlun is added before the RCU grace period has
      completed.
      
      This can happen in target_fabric_mappedlun_link() because it
      only checks for se_lun->lun_se_dev, which is not cleared until
      after transport_clear_lun_ref() percpu_ref RCU grace period
      finishes.
      
      This bug originally manifested as NULL pointer dereference
      OOPsen in target_stat_scsi_att_intr_port_show_attr_dev() on
      v4.1.y code, because it dereferences lun->lun_se_dev without
      a explicit NULL pointer check.
      
      In post v4.1 code with target-core RCU conversion, the code
      in target_stat_scsi_att_intr_port_show_attr_dev() no longer
      uses se_lun->lun_se_dev, but the same race still exists.
      
      To address the bug, go ahead and set se_lun>lun_shutdown as
      early as possible in core_tpg_remove_lun(), and ensure new
      NodeACL mappedlun creation in target_fabric_mappedlun_link()
      fails during se_lun shutdown.
      Reported-by: default avatarJames Shen <jcs@datera.io>
      Cc: James Shen <jcs@datera.io>
      Tested-by: default avatarJames Shen <jcs@datera.io>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22113847
    • Martin K. Petersen's avatar
      scsi: sd: Fix capacity calculation with 32-bit sector_t · 53204334
      Martin K. Petersen authored
      commit 7c856152 upstream.
      
      We previously made sure that the reported disk capacity was less than
      0xffffffff blocks when the kernel was not compiled with large sector_t
      support (CONFIG_LBDAF). However, this check assumed that the capacity
      was reported in units of 512 bytes.
      
      Add a sanity check function to ensure that we only enable disks if the
      entire reported capacity can be expressed in terms of sector_t.
      Reported-by: default avatarSteve Magnani <steve.magnani@digidescorp.com>
      Cc: Bart Van Assche <Bart.VanAssche@sandisk.com>
      Reviewed-by: default avatarBart Van Assche <Bart.VanAssche@sandisk.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      53204334
    • Sawan Chandak's avatar
      scsi: qla2xxx: Add fix to read correct register value for ISP82xx. · 24c01b36
      Sawan Chandak authored
      commit bf6061b1 upstream.
      
      Add fix to read correct register value for ISP82xx, during check for
      register disconnect.ISP82xx has different base register.
      
      Fixes: a465537a ("qla2xxx: Disable the adapter and skip error recovery in case of register disconnect")
      Signed-off-by: default avatarSawan Chandak <sawan.chandak@cavium.com>
      Signed-off-by: default avatarHimanshu Madhani <himanshu.madhani@cavium.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24c01b36
    • Fam Zheng's avatar
      scsi: sd: Consider max_xfer_blocks if opt_xfer_blocks is unusable · 8b30ed56
      Fam Zheng authored
      commit 67804145 upstream.
      
      If device reports a small max_xfer_blocks and a zero opt_xfer_blocks, we
      end up using BLK_DEF_MAX_SECTORS, which is wrong and r/w of that size
      may get error.
      
      [mkp: tweaked to avoid setting rw_max twice and added typecast]
      
      Fixes: ca369d51 ("block/sd: Fix device-imposed transfer length limits")
      Signed-off-by: default avatarFam Zheng <famz@redhat.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b30ed56
    • Martin K. Petersen's avatar
      scsi: sr: Sanity check returned mode data · 01fb9440
      Martin K. Petersen authored
      commit a00a7862 upstream.
      
      Kefeng Wang discovered that old versions of the QEMU CD driver would
      return mangled mode data causing us to walk off the end of the buffer in
      an attempt to parse it. Sanity check the returned mode sense data.
      Reported-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Tested-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      01fb9440
    • Nicholas Bellinger's avatar
      iscsi-target: Drop work-around for legacy GlobalSAN initiator · c8270f29
      Nicholas Bellinger authored
      commit 1c99de98 upstream.
      
      Once upon a time back in 2009, a work-around was added to support
      the GlobalSAN iSCSI initiator v3.3 for MacOSX, which during login
      did not propose nor respond to MaxBurstLength, FirstBurstLength,
      DefaultTime2Wait and DefaultTime2Retain keys.
      
      The work-around in iscsi_check_proposer_for_optional_reply()
      allowed the missing keys to be proposed, but did not require
      waiting for a response before moving to full feature phase
      operation.  This allowed GlobalSAN v3.3 to work out-of-the
      box, and for many years we didn't run into login interopt
      issues with any other initiators..
      
      Until recently, when Martin tried a QLogic 57840S iSCSI Offload
      HBA on Windows 2016 which completed login, but subsequently
      failed with:
      
          Got unknown iSCSI OpCode: 0x43
      
      The issue was QLogic MSFT side did not propose DefaultTime2Wait +
      DefaultTime2Retain, so LIO proposes them itself, and immediately
      transitions to full feature phase because of the GlobalSAN hack.
      However, the QLogic MSFT side still attempts to respond to
      DefaultTime2Retain + DefaultTime2Wait, even though LIO has set
      ISCSI_FLAG_LOGIN_NEXT_STAGE3 + ISCSI_FLAG_LOGIN_TRANSIT
      in last login response.
      
      So while the QLogic MSFT side should have been proposing these
      two keys to start, it was doing the correct thing per RFC-3720
      attempting to respond to proposed keys before transitioning to
      full feature phase.
      
      All that said, recent versions of GlobalSAN iSCSI (v5.3.0.541)
      does correctly propose the four keys during login, making the
      original work-around moot.
      
      So in order to allow QLogic MSFT to run unmodified as-is, go
      ahead and drop this long standing work-around.
      Reported-by: default avatarMartin Svec <martin.svec@zoner.cz>
      Cc: Martin Svec <martin.svec@zoner.cz>
      Cc: Himanshu Madhani <Himanshu.Madhani@cavium.com>
      Cc: Arun Easi <arun.easi@cavium.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8270f29
    • Nicholas Bellinger's avatar
      iscsi-target: Fix TMR reference leak during session shutdown · 51015220
      Nicholas Bellinger authored
      commit efb2ea77 upstream.
      
      This patch fixes a iscsi-target specific TMR reference leak
      during session shutdown, that could occur when a TMR was
      quiesced before the hand-off back to iscsi-target code
      via transport_cmd_check_stop_to_fabric().
      
      The reference leak happens because iscsit_free_cmd() was
      incorrectly skipping the final target_put_sess_cmd() for
      TMRs when transport_generic_free_cmd() returned zero because
      the se_cmd->cmd_kref did not reach zero, due to the missing
      se_cmd assignment in original code.
      
      The result was iscsi_cmd and it's associated se_cmd memory
      would be freed once se_sess->sess_cmd_map where released,
      but the associated se_tmr_req was leaked and remained part
      of se_device->dev_tmr_list.
      
      This bug would manfiest itself as kernel paging request
      OOPsen in core_tmr_lun_reset(), when a left-over se_tmr_req
      attempted to dereference it's se_cmd pointer that had
      already been released during normal session shutdown.
      
      To address this bug, go ahead and treat ISCSI_OP_SCSI_CMD
      and ISCSI_OP_SCSI_TMFUNC the same when there is an extra
      se_cmd->cmd_kref to drop in iscsit_free_cmd(), and use
      op_scsi to signal __iscsit_free_cmd() when the former
      needs to clear any further iscsi related I/O state.
      Reported-by: default avatarRob Millner <rlm@daterainc.com>
      Cc: Rob Millner <rlm@daterainc.com>
      Reported-by: default avatarChu Yuan Lin <cyl@datera.io>
      Cc: Chu Yuan Lin <cyl@datera.io>
      Tested-by: default avatarChu Yuan Lin <cyl@datera.io>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      51015220
    • Ard Biesheuvel's avatar
      efi/fb: Avoid reconfiguration of BAR that covers the framebuffer · c100de41
      Ard Biesheuvel authored
      commit 55d728a4 upstream.
      
      On UEFI systems, the PCI subsystem is enumerated by the firmware,
      and if a graphical framebuffer is exposed via a PCI device, its base
      address and size are exposed to the OS via the Graphics Output
      Protocol (GOP).
      
      On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
      scratch at boot. This may result in the GOP framebuffer address to
      become stale, if the BAR covering the framebuffer is modified. This
      will cause the framebuffer to become unresponsive, and may in some
      cases result in unpredictable behavior if the range is reassigned to
      another device.
      
      So add a non-x86 quirk to the EFI fb driver to find the BAR associated
      with the GOP base address, and claim the BAR resource so that the PCI
      core will not move it.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: leif.lindholm@linaro.org
      Cc: linux-efi@vger.kernel.org
      Cc: lorenzo.pieralisi@arm.com
      Fixes: 9822504c ("efifb: Enable the efi-framebuffer platform driver ...")
      Link: http://lkml.kernel.org/r/20170404152744.26687-3-ard.biesheuvel@linaro.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c100de41