1. 15 Jan, 2015 40 commits
    • Rabin Vincent's avatar
      crypto: af_alg - fix backlog handling · b6f7daea
      Rabin Vincent authored
      commit 7e77bdeb upstream.
      
      If a request is backlogged, it's complete() handler will get called
      twice: once with -EINPROGRESS, and once with the final error code.
      
      af_alg's complete handler, unlike other users, does not handle the
      -EINPROGRESS but instead always completes the completion that recvmsg()
      is waiting on.  This can lead to a return to user space while the
      request is still pending in the driver.  If userspace closes the sockets
      before the requests are handled by the driver, this will lead to
      use-after-frees (and potential crashes) in the kernel due to the tfm
      having been freed.
      
      The crashes can be easily reproduced (for example) by reducing the max
      queue length in cryptod.c and running the following (from
      http://www.chronox.de/libkcapi.html) on AES-NI capable hardware:
      
       $ while true; do kcapi -x 1 -e -c '__ecb-aes-aesni' \
          -k 00000000000000000000000000000000 \
          -p 00000000000000000000000000000000 >/dev/null & done
      Signed-off-by: default avatarRabin Vincent <rabin.vincent@axis.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b6f7daea
    • Jan Kara's avatar
      isofs: Fix unchecked printing of ER records · 4948220a
      Jan Kara authored
      commit 4e202462 upstream.
      
      We didn't check length of rock ridge ER records before printing them.
      Thus corrupted isofs image can cause us to access and print some memory
      behind the buffer with obvious consequences.
      Reported-and-tested-by: default avatarCarl Henrik Lunde <chlunde@ping.uio.no>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4948220a
    • Johannes Berg's avatar
      iwlwifi: make U-APSD default configurable at compile time · 657b8717
      Johannes Berg authored
      commit d6ca18de upstream.
      
      With a significant number of deployed APs, enabling uAPSD leads to the
      AP never using aggregation sessions (likely due to the complexities
      involved in handling uAPSD in those.) This obviously results in a large
      drop in throughput with such APs.
      
      On the other hand, uAPSD can result in some power consumption benefits,
      but for now just disable it to get performance with affected APs back
      up.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      657b8717
    • Jason Baron's avatar
      powercap / RAPL: add support for CPU model 0x3f · 932d760f
      Jason Baron authored
      commit 64c7569c upstream.
      
      I've confirmed that monitoring the package power usage as well as setting power
      limits appear to be working as expected. Supports the package and dram domains.
      
      Tested aginst cpu:
      
      Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
      Signed-off-by: default avatarJason Baron <jbaron@akamai.com>
      Acked-by: default avatarJacob Pan <jacob.jun.pan@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Pali Rohár <pali.rohar@gmail.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      932d760f
    • Liu Bo's avatar
      Btrfs: fix loop writing of async reclaim · f41320c4
      Liu Bo authored
      commit 25ce459c upstream.
      
      One of my tests shows that when we really don't have space to reclaim via
      flush_space and also run out of space, this async reclaim work loops on adding
      itself into the workqueue and keeps writing something to disk according to
      iostat's results, and these writes mainly comes from commit_transaction which
      writes super_block.  This's unacceptable as it can be bad to disks, especially
      memeory storages.
      
      This adds a check to avoid the above situation.
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Cc: Alexander E. Patrakov <patrakov@gmail.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f41320c4
    • Paolo Bonzini's avatar
      kvm: x86: drop severity of "generation wraparound" message · 76b04f0e
      Paolo Bonzini authored
      commit a629df7e upstream.
      
      Since most virtual machines raise this message once, it is a bit annoying.
      Make it KERN_DEBUG severity.
      
      Fixes: 7a2e8aafSigned-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      76b04f0e
    • John David Anglin's avatar
      parisc: fix out-of-register compiler error in ldcw inline assembler function · 047a3b12
      John David Anglin authored
      commit 45db0738 upstream.
      
      The __ldcw macro has a problem when its argument needs to be reloaded from
      memory. The output memory operand and the input register operand both need to
      be reloaded using a register in class R1_REGS when generating 64-bit code.
      This fails because there's only a single register in the class. Instead, use a
      memory clobber. This also makes the __ldcw macro a compiler memory barrier.
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      047a3b12
    • Richard Guy Briggs's avatar
      audit: restore AUDIT_LOGINUID unset ABI · e147a5d3
      Richard Guy Briggs authored
      commit 041d7b98 upstream.
      
      A regression was caused by commit 780a7654:
      	 audit: Make testing for a valid loginuid explicit.
      (which in turn attempted to fix a regression caused by e1760bd5)
      
      When audit_krule_to_data() fills in the rules to get a listing, there was a
      missing clause to convert back from AUDIT_LOGINUID_SET to AUDIT_LOGINUID.
      
      This broke userspace by not returning the same information that was sent and
      expected.
      
      The rule:
      	auditctl -a exit,never -F auid=-1
      gives:
      	auditctl -l
      		LIST_RULES: exit,never f24=0 syscall=all
      when it should give:
      		LIST_RULES: exit,never auid=-1 (0xffffffff) syscall=all
      
      Tag it so that it is reported the same way it was set.  Create a new
      private flags audit_krule field (pflags) to store it that won't interact with
      the public one from the API.
      Signed-off-by: default avatarRichard Guy Briggs <rgb@redhat.com>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e147a5d3
    • Lorenzo Pieralisi's avatar
      arm64: kernel: fix __cpu_suspend mm switch on warm-boot · b3ce059c
      Lorenzo Pieralisi authored
      commit f43c2718 upstream.
      
      On arm64 the TTBR0_EL1 register is set to either the reserved TTBR0
      page tables on boot or to the active_mm mappings belonging to user space
      processes, it must never be set to swapper_pg_dir page tables mappings.
      
      When a CPU is booted its active_mm is set to init_mm even though its
      TTBR0_EL1 points at the reserved TTBR0 page mappings. This implies
      that when __cpu_suspend is triggered the active_mm can point at
      init_mm even if the current TTBR0_EL1 register contains the reserved
      TTBR0_EL1 mappings.
      
      Therefore, the mm save and restore executed in __cpu_suspend might
      turn out to be erroneous in that, if the current->active_mm corresponds
      to init_mm, on resume from low power it ends up restoring in the
      TTBR0_EL1 the init_mm mappings that are global and can cause speculation
      of TLB entries which end up being propagated to user space.
      
      This patch fixes the issue by checking the active_mm pointer before
      restoring the TTBR0 mappings. If the current active_mm == &init_mm,
      the code sets the TTBR0_EL1 to the reserved TTBR0 mapping instead of
      switching back to the active_mm, which is the expected behaviour
      corresponding to the TTBR0_EL1 settings when __cpu_suspend was entered.
      
      Fixes: 95322526 ("arm64: kernel: cpu_{suspend/resume} implementation")
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b3ce059c
    • Laura Abbott's avatar
      arm64: Move cpu_resume into the text section · 109b9186
      Laura Abbott authored
      commit c3684fbb upstream.
      
      The function cpu_resume currently lives in the .data section.
      There's no reason for it to be there since we can use relative
      instructions without a problem. Move a few cpu_resume data
      structures out of the assembly file so the .data annotation
      can be dropped completely and cpu_resume ends up in the read
      only text section.
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Tested-by: default avatarMark Rutland <mark.rutland@arm.com>
      Tested-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Tested-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarLaura Abbott <lauraa@codeaurora.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      [ luis: 3.16-stable prereq for
        f43c2718 "arm64: kernel: fix __cpu_suspend mm switch on warm-boot" ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      109b9186
    • Lorenzo Pieralisi's avatar
      arm64: kernel: refactor the CPU suspend API for retention states · 0fb957f3
      Lorenzo Pieralisi authored
      commit 714f5992 upstream.
      
      CPU suspend is the standard kernel interface to be used to enter
      low-power states on ARM64 systems. Current cpu_suspend implementation
      by default assumes that all low power states are losing the CPU context,
      so the CPU registers must be saved and cleaned to DRAM upon state
      entry. Furthermore, the current cpu_suspend() implementation assumes
      that if the CPU suspend back-end method returns when called, this has
      to be considered an error regardless of the return code (which can be
      successful) since the CPU was not expected to return from a code path that
      is different from cpu_resume code path - eg returning from the reset vector.
      
      All in all this means that the current API does not cope well with low-power
      states that preserve the CPU context when entered (ie retention states),
      since first of all the context is saved for nothing on state entry for
      those states and a successful state entry can return as a normal function
      return, which is considered an error by the current CPU suspend
      implementation.
      
      This patch refactors the cpu_suspend() API so that it can be split in
      two separate functionalities. The arm64 cpu_suspend API just provides
      a wrapper around CPU suspend operation hook. A new function is
      introduced (for architecture code use only) for states that require
      context saving upon entry:
      
      __cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
      
      __cpu_suspend() saves the context on function entry and calls the
      so called suspend finisher (ie fn) to complete the suspend operation.
      The finisher is not expected to return, unless it fails in which case
      the error is propagated back to the __cpu_suspend caller.
      
      The API refactoring results in the following pseudo code call sequence for a
      suspending CPU, when triggered from a kernel subsystem:
      
      /*
       * int cpu_suspend(unsigned long idx)
       * @idx: idle state index
       */
      {
      -> cpu_suspend(idx)
      	|---> CPU operations suspend hook called, if present
      		|--> if (retention_state)
      			|--> direct suspend back-end call (eg PSCI suspend)
      		     else
      			|--> __cpu_suspend(idx, &back_end_finisher);
      }
      
      By refactoring the cpu_suspend API this way, the CPU operations back-end
      has a chance to detect whether idle states require state saving or not
      and can call the required suspend operations accordingly either through
      simple function call or indirectly through __cpu_suspend() which carries out
      state saving and suspend finisher dispatching to complete idle state entry.
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      [ luis: 3.16-stable prereq for
        f43c2718 "arm64: kernel: fix __cpu_suspend mm switch on warm-boot" ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0fb957f3
    • Lorenzo Pieralisi's avatar
      arm64: kernel: add missing __init section marker to cpu_suspend_init · 6b4a586a
      Lorenzo Pieralisi authored
      commit 18ab7db6 upstream.
      
      Suspend init function must be marked as __init, since it is not needed
      after the kernel has booted. This patch moves the cpu_suspend_init()
      function to the __init section.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      [ luis: 3.16-stable prereq for
        f43c2718 "arm64: kernel: fix __cpu_suspend mm switch on warm-boot" ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6b4a586a
    • Richard Guy Briggs's avatar
      audit: use supplied gfp_mask from audit_buffer in kauditd_send_multicast_skb · 5755059f
      Richard Guy Briggs authored
      commit 54dc77d9 upstream.
      
      Eric Paris explains: Since kauditd_send_multicast_skb() gets called in
      audit_log_end(), which can come from any context (aka even a sleeping context)
      GFP_KERNEL can't be used.  Since the audit_buffer knows what context it should
      use, pass that down and use that.
      
      See: https://lkml.org/lkml/2014/12/16/542
      
      BUG: sleeping function called from invalid context at mm/slab.c:2849
      in_atomic(): 1, irqs_disabled(): 0, pid: 885, name: sulogin
      2 locks held by sulogin/885:
        #0:  (&sig->cred_guard_mutex){+.+.+.}, at: [<ffffffff91152e30>] prepare_bprm_creds+0x28/0x8b
        #1:  (tty_files_lock){+.+.+.}, at: [<ffffffff9123e787>] selinux_bprm_committing_creds+0x55/0x22b
      CPU: 1 PID: 885 Comm: sulogin Not tainted 3.18.0-next-20141216 #30
      Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A15 06/20/2014
        ffff880223744f10 ffff88022410f9b8 ffffffff916ba529 0000000000000375
        ffff880223744f10 ffff88022410f9e8 ffffffff91063185 0000000000000006
        0000000000000000 0000000000000000 0000000000000000 ffff88022410fa38
      Call Trace:
        [<ffffffff916ba529>] dump_stack+0x50/0xa8
        [<ffffffff91063185>] ___might_sleep+0x1b6/0x1be
        [<ffffffff910632a6>] __might_sleep+0x119/0x128
        [<ffffffff91140720>] cache_alloc_debugcheck_before.isra.45+0x1d/0x1f
        [<ffffffff91141d81>] kmem_cache_alloc+0x43/0x1c9
        [<ffffffff914e148d>] __alloc_skb+0x42/0x1a3
        [<ffffffff914e2b62>] skb_copy+0x3e/0xa3
        [<ffffffff910c263e>] audit_log_end+0x83/0x100
        [<ffffffff9123b8d3>] ? avc_audit_pre_callback+0x103/0x103
        [<ffffffff91252a73>] common_lsm_audit+0x441/0x450
        [<ffffffff9123c163>] slow_avc_audit+0x63/0x67
        [<ffffffff9123c42c>] avc_has_perm+0xca/0xe3
        [<ffffffff9123dc2d>] inode_has_perm+0x5a/0x65
        [<ffffffff9123e7ca>] selinux_bprm_committing_creds+0x98/0x22b
        [<ffffffff91239e64>] security_bprm_committing_creds+0xe/0x10
        [<ffffffff911515e6>] install_exec_creds+0xe/0x79
        [<ffffffff911974cf>] load_elf_binary+0xe36/0x10d7
        [<ffffffff9115198e>] search_binary_handler+0x81/0x18c
        [<ffffffff91153376>] do_execveat_common.isra.31+0x4e3/0x7b7
        [<ffffffff91153669>] do_execve+0x1f/0x21
        [<ffffffff91153967>] SyS_execve+0x25/0x29
        [<ffffffff916c61a9>] stub_execve+0x69/0xa0
      Reported-by: default avatarValdis Kletnieks <Valdis.Kletnieks@vt.edu>
      Signed-off-by: default avatarRichard Guy Briggs <rgb@redhat.com>
      Tested-by: default avatarValdis Kletnieks <Valdis.Kletnieks@vt.edu>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5755059f
    • Paul Moore's avatar
      audit: don't attempt to lookup PIDs when changing PID filtering audit rules · 1d668182
      Paul Moore authored
      commit 3640dcfa upstream.
      
      Commit f1dc4867 ("audit: anchor all pid references in the initial pid
      namespace") introduced a find_vpid() call when adding/removing audit
      rules with PID/PPID filters; unfortunately this is problematic as
      find_vpid() only works if there is a task with the associated PID
      alive on the system.  The following commands demonstrate a simple
      reproducer.
      
      	# auditctl -D
      	# auditctl -l
      	# autrace /bin/true
      	# auditctl -l
      
      This patch resolves the problem by simply using the PID provided by
      the user without any additional validation, e.g. no calls to check to
      see if the task/PID exists.
      
      Cc: Richard Guy Briggs <rgb@redhat.com>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Acked-by: default avatarEric Paris <eparis@redhat.com>
      Reviewed-by: default avatarRichard Guy Briggs <rgb@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1d668182
    • Thomas Gleixner's avatar
      tick/powerclamp: Remove tick_nohz_idle abuse · 8254b3a6
      Thomas Gleixner authored
      commit a5fd9733 upstream.
      
      commit 4dbd2771 "tick: export nohz tick idle symbols for module
      use" was merged via the thermal tree without an explicit ack from the
      relevant maintainers.
      
      The exports are abused by the intel powerclamp driver which implements
      a fake idle state from a sched FIFO task. This causes all kinds of
      wreckage in the NOHZ core code which rightfully assumes that
      tick_nohz_idle_enter/exit() are only called from the idle task itself.
      
      Recent changes in the NOHZ core lead to a failure of the powerclamp
      driver and now people try to hack completely broken and backwards
      workarounds into the NOHZ core code. This is completely unacceptable
      and just papers over the real problem. There are way more subtle
      issues lurking around the corner.
      
      The real solution is to fix the powerclamp driver by rewriting it with
      a sane concept, but that's beyond the scope of this.
      
      So the only solution for now is to remove the calls into the core NOHZ
      code from the powerclamp trainwreck along with the exports.
      
      Fixes: d6d71ee4 "PM: Introduce Intel PowerClamp Driver"
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Frederic Weisbecker <frederic@kernel.org>
      Cc: Pan Jacob jun <jacob.jun.pan@intel.com>
      Cc: LKP <lkp@01.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Zhang Rui <rui.zhang@intel.com>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1412181110110.17382@nanosSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8254b3a6
    • Jiri Jaburek's avatar
      ALSA: usb-audio: extend KEF X300A FU 10 tweak to Arcam rPAC · eb2f2690
      Jiri Jaburek authored
      commit d70a1b98 upstream.
      
      The Arcam rPAC seems to have the same problem - whenever anything
      (alsamixer, udevd, 3.9+ kernel from 60af3d03, ..) attempts to
      access mixer / control interface of the card, the firmware "locks up"
      the entire device, resulting in
        SNDRV_PCM_IOCTL_HW_PARAMS failed (-5): Input/output error
      from alsa-lib.
      
      Other operating systems can somehow read the mixer (there seems to be
      playback volume/mute), but any manipulation is ignored by the device
      (which has hardware volume controls).
      Signed-off-by: default avatarJiri Jaburek <jjaburek@redhat.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      eb2f2690
    • Andy Lutomirski's avatar
      x86/tls: Don't validate lm in set_thread_area() after all · 5862abdd
      Andy Lutomirski authored
      commit 3fb2f423 upstream.
      
      It turns out that there's a lurking ABI issue.  GCC, when
      compiling this in a 32-bit program:
      
      struct user_desc desc = {
      	.entry_number    = idx,
      	.base_addr       = base,
      	.limit           = 0xfffff,
      	.seg_32bit       = 1,
      	.contents        = 0, /* Data, grow-up */
      	.read_exec_only  = 0,
      	.limit_in_pages  = 1,
      	.seg_not_present = 0,
      	.useable         = 0,
      };
      
      will leave .lm uninitialized.  This means that anything in the
      kernel that reads user_desc.lm for 32-bit tasks is unreliable.
      
      Revert the .lm check in set_thread_area().  The value never did
      anything in the first place.
      
      Fixes: 0e58af4e ("x86/tls: Disallow unusual TLS segments")
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/d7875b60e28c512f6a6fc0baf5714d58e7eaadbb.1418856405.git.luto@amacapital.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5862abdd
    • Thomas Petazzoni's avatar
      i2c: mv64xxx: rework offload support to fix several problems · c0f60cba
      Thomas Petazzoni authored
      commit 00d8689b upstream.
      
      Originally, the I2C controller supported by the i2c-mv64xxx driver
      requires a lot of software support: an interrupt is generated at each
      step of an I2C transaction (after the start bit, after sending the
      address, etc.) and the driver is in charge of re-programming the I2C
      controller to do the next step of the I2C transaction. This explains
      the fairly complex state machine that the driver has.
      
      On Marvell Armada XP and later processors (Armada 375, 38x, etc.), the
      I2C controller was extended with a part called the "I2C Bridge", which
      allows to offload the I2C transaction completely to the
      hardware. Initial support for this mechanism was added in commit
      930ab3d4 ("i2c: mv64xxx: Add I2C Transaction Generator support").
      
      However, the implementation done in this commit has two related
      issues, which this commit fixes by completely changing how the offload
      implementation is done:
      
       * SMBus read transfers, where there is one write to select the
         register immediately followed in the same transaction by one read,
         were making the processor hang. This was easier visible on the
         Marvell Armada XP WRT1900AC platform using a driver for an I2C LED
         controller, or on other Armada XP platforms by using a simple
         'i2cget' command to read an I2C EEPROM.
      
       * The implementation was based on the fact that the offload engine
         was re-programmed to transfer each message of an I2C xfer: this
         meant that each message sent with the offload engine was starting
         with a normal I2C start sequence. However, the I2C subsystem
         assumes that all messages belonging to the same xfer will use the
         so-called "repeated start" so that the entire I2C xfer is seen as
         one transfer by the I2C devices and cannot be interrupt by other
         I2C masters on the same bus.
      
      In fact, the "I2C Bridge" allows to offload three types of xfer:
      
       - xfer of one write message
       - xfer of one read message
       - xfer of one write message followed by one read message
      
      For all other situations, we have to fallback to not using the "I2C
      Bridge" in order to get proper I2C semantics.
      
      Therefore, this commit reworks the offload implementation to put it
      not at the message level, but at the xfer level: in the
      mv64xxx_i2c_xfer() function, we decide if the transaction can be
      offloaded (in which case it is handled by the
      mv64xxx_i2c_offload_xfer() function), or otherwise it is handled by
      the slow path (implemented in the existing mv64xxx_i2c_execute_msg()).
      
      This allows to simplify the state machine, which no longer needs to
      have any state related to the offload implementation: the offload
      implementation is now completely separated from the slow path (with
      the exception of the interrupt handler, of course).
      
      In summary:
      
       - mv64xxx_i2c_can_offload() will analyze an I2C xfer and decided of
         the "I2C Bridge" can be used to offload it or not.
      
       - mv64xxx_i2c_offload_xfer() will actually program the "I2C Bridge"
         to offload one xfer (of either one or two messages), and block
         using mv64xxx_i2c_wait_for_completion() until the xfer completes.
      
       - The interrupt handler mv64xxx_i2c_intr() is modified to push the
         offload related code to a separate function,
         mv64xxx_i2c_intr_offload(). It will take care of reading the
         received data if needed.
      
      This commit was tested on:
      
       - Armada XP OpenBlocks AX3-4 (EEPROM on I2C and RTC on I2C)
       - Armada XP WRT1900AC (LED controller on I2C)
       - Armada XP GP (EEPROM on I2C)
      
      Fixes: 930ab3d4 ("i2c: mv64xxx: Add I2C Transaction Generator support")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      [wsa: fixed checkpatch warnings]
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c0f60cba
    • Thomas Petazzoni's avatar
    • zhendong chen's avatar
      dm: fix missed error code if .end_io isn't implemented by target_type · 09e20944
      zhendong chen authored
      commit 5164bece upstream.
      
      In bio-based DM's clone_endio(), when target_type doesn't implement
      .end_io (e.g. linear) r will be always be initialized 0.  So if a
      WRITE SAME bio fails WRITE SAME will not be disabled as intended.
      
      Fix this by initializing r to error, rather than 0, in clone_endio().
      Signed-off-by: default avatarAlex Chen <alex.chen@huawei.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Fixes: 7eee4ae2 ("dm: disable WRITE SAME if it fails")
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      09e20944
    • Joe Thornber's avatar
      dm thin: fix missing out-of-data-space to write mode transition if blocks are released · e6051f0a
      Joe Thornber authored
      commit 2c43fd26 upstream.
      
      Discard bios and thin device deletion have the potential to release data
      blocks.  If the thin-pool is in out-of-data-space mode, and blocks were
      released, transition the thin-pool back to full write mode.
      
      The correct time to do this is just after the thin-pool metadata commit.
      It cannot be done before the commit because the space maps will not
      allow immediate reuse of the data blocks in case there's a rollback
      following power failure.
      Signed-off-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e6051f0a
    • Joe Thornber's avatar
      dm thin: fix inability to discard blocks when in out-of-data-space mode · 3ac19d4f
      Joe Thornber authored
      commit 45ec9bd0 upstream.
      
      When the pool was in PM_OUT_OF_SPACE mode its process_prepared_discard
      function pointer was incorrectly being set to
      process_prepared_discard_passdown rather than process_prepared_discard.
      
      This incorrect function pointer meant the discard was being passed down,
      but not effecting the mapping.  As such any discard that was issued, in
      an attempt to reclaim blocks, would not successfully free data space.
      Reported-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3ac19d4f
    • Kailang Yang's avatar
      ALSA: hda/realtek - Add new Dell desktop for ALC3234 headset mode · 3a3090ca
      Kailang Yang authored
      commit 8b72415d upstream.
      
      New Dell desktop needs to support headset mode for ALC3234.
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3a3090ca
    • Chris Wilson's avatar
      drm/i915: Force the CS stall for invalidate flushes · cf0b2ec0
      Chris Wilson authored
      commit add284a3 upstream.
      
      In order to act as a full command barrier by itself, we need to tell the
      pipecontrol to actually stall the command streamer while the flush runs.
      We require the full command barrier before operations like
      MI_SET_CONTEXT, which currently rely on a prior invalidate flush.
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=83677
      Cc: Simon Farnsworth <simon@farnz.org.uk>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      cf0b2ec0
    • Chris Wilson's avatar
      drm/i915: Invalidate media caches on gen7 · faa6cf14
      Chris Wilson authored
      commit 148b83d0 upstream.
      
      In the gen7 pipe control there is an extra bit to flush the media
      caches, so let's set it during cache invalidation flushes.
      
      v2: Rename to MEDIA_STATE_CLEAR to be more inline with spec.
      
      Cc: Simon Farnsworth <simon@farnz.org.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      faa6cf14
    • Nicholas Bellinger's avatar
      iscsi-target: Fail connection on short sendmsg writes · ba957dfe
      Nicholas Bellinger authored
      commit 6bf6ca75 upstream.
      
      This patch changes iscsit_do_tx_data() to fail on short writes
      when kernel_sendmsg() returns a value different than requested
      transfer length, returning -EPIPE and thus causing a connection
      reset to occur.
      
      This avoids a potential bug in the original code where a short
      write would result in kernel_sendmsg() being called again with
      the original iovec base + length.
      
      In practice this has not been an issue because iscsit_do_tx_data()
      is only used for transferring 48 byte headers + 4 byte digests,
      along with seldom used control payloads from NOPIN + TEXT_RSP +
      REJECT with less than 32k of data.
      
      So following Al's audit of iovec consumers, go ahead and fail
      the connection on short writes for now, and remove the bogus
      logic ahead of his proper upstream fix.
      Reported-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ba957dfe
    • Long Li's avatar
      storvsc: ring buffer failures may result in I/O freeze · 63a60036
      Long Li authored
      commit e86fb5e8 upstream.
      
      When ring buffer returns an error indicating retry, storvsc may not
      return a proper error code to SCSI when bounce buffer is not used.
      This has introduced I/O freeze on RAID running atop storvsc devices.
      This patch fixes it by always returning a proper error code.
      Signed-off-by: default avatarLong Li <longli@microsoft.com>
      Reviewed-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      63a60036
    • Martin K. Petersen's avatar
      scsi: blacklist RSOC for Microsoft iSCSI target devices · e144f664
      Martin K. Petersen authored
      commit 198a956a upstream.
      
      The Microsoft iSCSI target does not support REPORT SUPPORTED OPERATION
      CODES. Blacklist these devices so we don't attempt to send the command.
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Tested-by: default avatarMike Christie <michaelc@cs.wisc.edu>
      Reported-by: jazz@deti74.ru
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e144f664
    • Paul Mackerras's avatar
      powerpc/powernv: Switch off MMU before entering nap/sleep/rvwinkle mode · e7c25b93
      Paul Mackerras authored
      commit 8117ac6a upstream.
      
      Currently, when going idle, we set the flag indicating that we are in
      nap mode (paca->kvm_hstate.hwthread_state) and then execute the nap
      (or sleep or rvwinkle) instruction, all with the MMU on.  This is bad
      for two reasons: (a) the architecture specifies that those instructions
      must be executed with the MMU off, and in fact with only the SF, HV, ME
      and possibly RI bits set, and (b) this introduces a race, because as
      soon as we set the flag, another thread can switch the MMU to a guest
      context.  If the race is lost, this thread will typically start looping
      on relocation-on ISIs at 0xc...4400.
      
      This fixes it by setting the MSR as required by the architecture before
      setting the flag or executing the nap/sleep/rvwinkle instruction.
      
      [ shreyas@linux.vnet.ibm.com: Edited to handle LE ]
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarShreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e7c25b93
    • Thomas Gleixner's avatar
      genirq: Prevent proc race against freeing of irq descriptors · 5e95fa4f
      Thomas Gleixner authored
      commit c291ee62 upstream.
      
      Since the rework of the sparse interrupt code to actually free the
      unused interrupt descriptors there exists a race between the /proc
      interfaces to the irq subsystem and the code which frees the interrupt
      descriptor.
      
      CPU0				CPU1
      				show_interrupts()
      				  desc = irq_to_desc(X);
      free_desc(desc)
        remove_from_radix_tree();
        kfree(desc);
      				  raw_spinlock_irq(&desc->lock);
      
      /proc/interrupts is the only interface which can actively corrupt
      kernel memory via the lock access. /proc/stat can only read from freed
      memory. Extremly hard to trigger, but possible.
      
      The interfaces in /proc/irq/N/ are not affected by this because the
      removal of the proc file is serialized in procfs against concurrent
      readers/writers. The removal happens before the descriptor is freed.
      
      For architectures which have CONFIG_SPARSE_IRQ=n this is a non issue
      as the descriptor is never freed. It's merely cleared out with the irq
      descriptor lock held. So any concurrent proc access will either see
      the old correct value or the cleared out ones.
      
      Protect the lookup and access to the irq descriptor in
      show_interrupts() with the sparse_irq_lock.
      
      Provide kstat_irqs_usr() which is protecting the lookup and access
      with sparse_irq_lock and switch /proc/stat to use it.
      
      Document the existing kstat_irqs interfaces so it's clear that the
      caller needs to take care about protection. The users of these
      interfaces are either not affected due to SPARSE_IRQ=n or already
      protected against removal.
      
      Fixes: 1f5a5b87 "genirq: Implement a sane sparse_irq allocator"
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5e95fa4f
    • Sagi Grimberg's avatar
      iscsi,iser-target: Expose supported protection ops according to t10_pi · 0f990013
      Sagi Grimberg authored
      commit 23a548ee upstream.
      
      iSER will report supported protection operations based on
      the tpg attribute t10_pi settings and HCA PI offload capabilities.
      If the HCA does not support PI offload or tpg attribute t10_pi is
      not set, we fall to SW PI mode.
      
      In order to do that, we move iscsit_get_sup_prot_ops after connection
      tpg assignment.
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0f990013
    • Sagi Grimberg's avatar
      iser-target: Fix NULL dereference in SW mode DIF · c52c1599
      Sagi Grimberg authored
      commit 302cc7c3 upstream.
      
      Fallback to software mode DIF if HCA does not support
      PI (without crashing obviously). It is still possible to
      run with backend protection and an unprotected frontend,
      so looking at the command prot_op is not enough. Check
      device PI capability on a per-IO basis (isert_prot_cmd
      inline static) to determine if we need to handle protection
      information.
      
      Trace:
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
      IP: [<ffffffffa037f8b1>] isert_reg_sig_mr+0x351/0x3b0 [ib_isert]
      Call Trace:
       [<ffffffff812b003a>] ? swiotlb_map_sg_attrs+0x7a/0x130
       [<ffffffffa038184d>] isert_reg_rdma+0x2fd/0x370 [ib_isert]
       [<ffffffff8108f2ec>] ? idle_balance+0x6c/0x2c0
       [<ffffffffa0382b68>] isert_put_datain+0x68/0x210 [ib_isert]
       [<ffffffffa02acf5b>] lio_queue_data_in+0x2b/0x30 [iscsi_target_mod]
       [<ffffffffa02306eb>] target_complete_ok_work+0x21b/0x310 [target_core_mod]
       [<ffffffff8106ece2>] process_one_work+0x182/0x3b0
       [<ffffffff8106fda0>] worker_thread+0x120/0x3c0
       [<ffffffff8106fc80>] ? maybe_create_worker+0x190/0x190
       [<ffffffff8107594e>] kthread+0xce/0xf0
       [<ffffffff81075880>] ? kthread_freezable_should_stop+0x70/0x70
       [<ffffffff8159a22c>] ret_from_fork+0x7c/0xb0
       [<ffffffff81075880>] ? kthread_freezable_should_stop+0x70/0x70
      Reported-by: default avatarSlava Shwartsman <valyushash@gmail.com>
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c52c1599
    • Sagi Grimberg's avatar
      iser-target: Allocate PI contexts dynamically · 2a9a256d
      Sagi Grimberg authored
      commit 570db170 upstream.
      
      This patch converts to allocate PI contexts dynamically in order
      avoid a potentially bogus np->tpg_np and associated NULL pointer
      dereference in isert_connect_request() during iser-target endpoint
      shutdown with multiple network portals.
      
      Also, there is really no need to allocate these at connection
      establishment since it is not guaranteed that all the IOs on
      that connection will be to a PI formatted device.
      
      We can do it in a lazy fashion so the initial burst will have a
      transient slow down, but very fast all IOs will allocate a PI
      context.
      
      Squashed:
      
      iser-target: Centralize PI context handling code
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2a9a256d
    • Sagi Grimberg's avatar
      iser-target: Fix implicit termination of connections · 63dff7ee
      Sagi Grimberg authored
      commit b02efbfc upstream.
      
      In situations such as bond failover, The new session establishment
      implicitly invokes the termination of the old connection.
      
      So, we don't want to wait for the old connection wait_conn to completely
      terminate before we accept the new connection and post a login response.
      
      The solution is to deffer the comp_wait completion and the conn_put to
      a work so wait_conn will effectively be non-blocking (flush errors are
      assumed to come very fast).
      
      We allocate isert_release_wq with WQ_UNBOUND and WQ_UNBOUND_MAX_ACTIVE
      to spread the concurrency of release works.
      Reported-by: default avatarSlava Shwartsman <valyushash@gmail.com>
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      63dff7ee
    • Sagi Grimberg's avatar
      iser-target: Handle ADDR_CHANGE event for listener cm_id · 868d84f1
      Sagi Grimberg authored
      commit ca6c1d82 upstream.
      
      The np listener cm_id will also get ADDR_CHANGE event
      upcall (in case it is bound to a specific IP). Handle
      it correctly by creating a new cm_id and implicitly
      destroy the old one.
      
      Since this is the second event a listener np cm_id may
      encounter, we move the np cm_id event handling to a
      routine.
      
      Squashed:
      
      iser-target: Move cma_id setup to a function
      Reported-by: default avatarSlava Shwartsman <valyushash@gmail.com>
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      868d84f1
    • Sagi Grimberg's avatar
      iser-target: Fix connected_handler + teardown flow race · d1bfea1a
      Sagi Grimberg authored
      commit 19e2090f upstream.
      
      Take isert_conn pointer from cm_id->qp->qp_context. This
      will allow us to know that the cm_id context is always
      the network portal. This will make the cm_id event check
      (connection or network portal) more reliable.
      
      In order to avoid a NULL dereference in cma_id->qp->qp_context
      we destroy the qp after we destroy the cm_id (and make the
      dereference safe). session stablishment/teardown sequences
      can happen in parallel, we should take into account that
      connected_handler might race with connection teardown flow.
      
      Also, protect isert_conn->conn_device->active_qps decrement
      within the error patch during QP creation failure and the
      normal teardown path in isert_connect_release().
      
      Squashed:
      
      iser-target: Decrement completion context active_qps in error flow
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d1bfea1a
    • Sagi Grimberg's avatar
      iser-target: Parallelize CM connection establishment · 611bb15b
      Sagi Grimberg authored
      commit 2371e5da upstream.
      
      There is no point in accepting a new CM request only
      when we are completely done with the last iscsi login.
      Instead we accept immediately, this will also cause the
      CM connection to reach connected state and the initiator
      is allowed to send the first login. We mark that we got
      the initial login and let iscsi layer pick it up when it
      gets there.
      
      This reduces the parallel login sequence by a factor of
      more then 4 (and more for multi-login) and also prevents
      the initiator (who does all logins in parallel) from
      giving up on login timeout expiration.
      
      In order to support multiple login requests sequence (CHAP)
      we call isert_rx_login_req from isert_rx_completion insead
      of letting isert_get_login_rx call it.
      
      Squashed:
      
      iser-target: Use kref_get_unless_zero in connected_handler
      iser-target: Acquire conn_mutex when changing connection state
      iser-target: Reject connect request in failure path
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      611bb15b
    • Sagi Grimberg's avatar
      iser-target: Fix flush + disconnect completion handling · 170b761c
      Sagi Grimberg authored
      commit 128e9cc8 upstream.
      
      ISER_CONN_UP state is not sufficient to know if
      we should wait for completion of flush errors and
      disconnected_handler event.
      
      Instead, split it to 2 states:
      - ISER_CONN_UP: Got to CM connected phase, This state
      indicates that we need to wait for a CM disconnect
      event before going to teardown.
      
      - ISER_CONN_FULL_FEATURE: Got to full feature phase
      after we posted login response, This state indicates
      that we posted recv buffers and we need to wait for
      flush completions before going to teardown.
      
      Also avoid deffering disconnected handler to a work,
      and handle it within disconnected handler.
      More work here is needed to handle DEVICE_REMOVAL event
      correctly (cleanup all resources).
      
      Squashed:
      
      iser-target: Don't deffer disconnected handler to a work
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      170b761c
    • Sagi Grimberg's avatar
      iscsi,iser-target: Initiate termination only once · 96b50563
      Sagi Grimberg authored
      commit 954f2372 upstream.
      
      Since commit 0fc4ea70 ("Target/iser: Don't put isert_conn inside
      disconnected handler") we put the conn kref in isert_wait_conn, so we
      need .wait_conn to be invoked also in the error path.
      
      Introduce call to isert_conn_terminate (called under lock)
      which transitions the connection state to TERMINATING and calls
      rdma_disconnect. If the state is already teminating, just bail
      out back (temination started).
      
      Also, make sure to destroy the connection when getting a connect
      error event if didn't get to connected (state UP). Same for the
      handling of REJECTED and UNREACHABLE cma events.
      
      Squashed:
      
      iscsi-target: Add call to wait_conn in establishment error flow
      Reported-by: default avatarSlava Shwartsman <valyushash@gmail.com>
      Signed-off-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      96b50563
    • Imre Deak's avatar
      drm/i915: vlv: fix IRQ masking when uninstalling interrupts · 1eadc8e9
      Imre Deak authored
      commit c352d1ba upstream.
      
      irq_mask should include all IRQ bits that we want to mask, but atm we
      set it incorrectly to the inverse of this. If the mask is used
      subsequently to enable/disable some IRQ bits, we may unintentionally
      unmask unrelated IRQs. I can't see any way that this can lead to a real
      problem in the current -nightly code, since the first place the mask
      will be used next (after a suspend/resume cycle) is in
      valleyview_irq_postinstall(), but the mask is reset there to its proper
      value.
      
      This causes a problem in the upstream kernel though, where - due to another
      issue - the mask is used in the above way to disable only the display IRQs.
      This other issue is fixed by:
      
      commit 950eabaf
      Author: Imre Deak <imre.deak@intel.com>
      Date:   Mon Sep 8 15:21:09 2014 +0300
      
          drm/i915: vlv: fix display IRQ enable/disable
      
      Interestingly, even with the above two bugs, we shouldn't in theory have
      any real problems (arguably a famous last sentence:). That's because
      even if we unmask something unintentionally via the VLV_IMR/VLV_IER
      register the master IRQ masking bit in VLV_MASTER_IER is still set and
      should prevent all i915 interrupts. According to my testing on an ASUS
      T100 with DSI output this isn't the case at least with the
      MIPIA_INTERRUPT. Leaving this one unmasked in IMR/IER, while having
      VLV_MASTER_IER set to 0 may lead to a lockup during system suspend as
      shown in the bugzilla ticket below. This fix should get rid of the
      problem reported there in upstream and older kernels.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85920Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1eadc8e9