1. 18 Jun, 2016 1 commit
  2. 17 Jun, 2016 9 commits
    • Linus Torvalds's avatar
      Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux · 9cbbef4e
      Linus Torvalds authored
      Pull arm64 fixes from Will Deacon:
       "The main things are getting kgdb up and running with upstream GDB
        after a protocol change was reverted and fixing our spin_unlock_wait
        and spin_is_locked implementations after doing some similar work with
        PeterZ on the qspinlock code last week.  Whilst we haven't seen any
        failures in practice, it's still worth getting this fixed.
      
        Summary:
      
         - Plug the ongoing spin_unlock_wait/spin_is_locked mess
         - KGDB protocol fix to sync w/ GDB
         - Fix MIDR-based PMU probing for old 32-bit SMP systems
           (OMAP4/Realview)
         - Minor tweaks to the fault handling path"
      
      * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
        arm64: kgdb: Match pstate size with gdbserver protocol
        arm64: spinlock: Ensure forward-progress in spin_unlock_wait
        arm64: spinlock: fix spin_unlock_wait for LSE atomics
        arm64: spinlock: order spin_{is_locked,unlock_wait} against local locks
        arm: pmu: Fix non-devicetree probing
        arm64: mm: mark fault_info table const
        arm64: fix dump_instr when PAN and UAO are in use
      9cbbef4e
    • Linus Torvalds's avatar
      Merge tag 'iommu-fixes-v4.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu · 8c256155
      Linus Torvalds authored
      Pull IOMMU fixes from Joerg Roedel:
       "Three patches queued up:
      
         - Fix for ARM-SMMU to add a missing iommu-ops callback which is
           required by common iommu code
      
         - Fix for the rockchip iommu where the wrong MMUs got the commands
      
         - A regression fix for the Intel VT-d driver.  The regression only
           showed up on X58 chipsets with more than one iommu.  These chipsets
           seem to require that QI is enabled on all IOMMUs before it can be
           used"
      
      * tag 'iommu-fixes-v4.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
        iommu/vt-d: Enable QI on all IOMMUs before setting root entry
        iommu/rockchip: Fix zap cache during device attach
        iommu/arm-smmu: Wire up map_sg for arm-smmu-v3
      8c256155
    • Linus Torvalds's avatar
      Merge tag 'for-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds · 7af9a170
      Linus Torvalds authored
      Pull LED fixes from Jacek Anaszewski:
      
       - Fix brightness setting upon hardware blinking enabled
      
       - Handle suspend/resume in heartbeat trigger
      
      * tag 'for-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds:
        leds: handle suspend/resume in heartbeat trigger
        leds: core: Fix brightness setting upon hardware blinking enabled
      7af9a170
    • Joerg Roedel's avatar
      iommu/vt-d: Enable QI on all IOMMUs before setting root entry · a4c34ff1
      Joerg Roedel authored
      This seems to be required on some X58 chipsets on systems
      with more than one IOMMU. QI does not work until it is
      enabled on all IOMMUs in the system.
      Reported-by: default avatarDheeraj CVR <cvr.dheeraj@gmail.com>
      Tested-by: default avatarDheeraj CVR <cvr.dheeraj@gmail.com>
      Fixes: 5f0a7f76 ('iommu/vt-d: Make root entry visible for hardware right after allocation')
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      a4c34ff1
    • Linus Torvalds's avatar
      Merge tag 'pwm/for-4.7-rc4' of... · bb967271
      Linus Torvalds authored
      Merge tag 'pwm/for-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
      
      Pull pwm fixes from Thierry Reding:
       "These changes fix a bit of fallout from the introduction of the atomic
        API"
      
      * tag 'pwm/for-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
        pwm: atmel-hlcdc: Fix default PWM polarity
        pwm: sysfs: Get return value from pwm_apply_state()
        pwm: Improve args checking in pwm_apply_state()
      bb967271
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 2668bc77
      Linus Torvalds authored
      Pull KVM fixes from Paolo Bonzini:
      
       - miscellaneous fixes for MIPS and s390
      
       - one new kvm_stat for s390
      
       - correctly disable VT-d posted interrupts with the rest of posted
         interrupts
      
       - "make randconfig" fix for x86 AMD
      
       - off-by-one in irq route check (the "good" kind that errors out a bit
         too early!)
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        kvm: vmx: check apicv is active before using VT-d posted interrupt
        kvm: Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES
        kvm: svm: Do not support AVIC if not CONFIG_X86_LOCAL_APIC
        kvm: svm: Fix implicit declaration for __default_cpu_present_to_apicid()
        MIPS: KVM: Fix CACHE triggered exception emulation
        MIPS: KVM: Don't unwind PC when emulating CACHE
        MIPS: KVM: Include bit 31 in segment matches
        MIPS: KVM: Fix modular KVM under QEMU
        KVM: s390: Add stats for PEI events
        KVM: s390: ignore IBC if zero
      2668bc77
    • Linus Torvalds's avatar
      Merge tag 'nfsd-4.7-1' of git://linux-nfs.org/~bfields/linux · 41ef7218
      Linus Torvalds authored
      Pull nfsd bugfixes from Bruce Fields:
       "Oleg Drokin found and fixed races in the nfsd4 state code that go back
        to the big nfs4_lock_state removal around 3.17 (but that were also
        probably hard to reproduce before client changes in 3.20 allowed the
        client to perform parallel opens).
      
        Also fix a 4.1 backchannel crash due to rpc multipath changes in 4.6.
        Trond acked the client-side rpc fixes going through my tree"
      
      * tag 'nfsd-4.7-1' of git://linux-nfs.org/~bfields/linux:
        nfsd: Make init_open_stateid() a bit more whole
        nfsd: Extend the mutex holding region around in nfsd4_process_open2()
        nfsd: Always lock state exclusively.
        rpc: share one xps between all backchannels
        nfsd4/rpc: move backchannel create logic into rpc code
        SUNRPC: fix xprt leak on xps allocation failure
        nfsd: Fix NFSD_MDS_PR_KEY on 32-bit by adding ULL postfix
      41ef7218
    • Linus Torvalds's avatar
      Merge branch 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs · 9c514bed
      Linus Torvalds authored
      Pull overlayfs fixes from Miklos Szeredi:
       "This contains two regression fixes: one for the xattr API update and
        one for using the mounter's creds in file creation in overlayfs.
      
        There's also a fix for a bug in handling hard linked AF_UNIX sockets
        that's been there from day one.  This fix is overlayfs only despite
        the fact that it touches code outside the overlay filesystem: d_real()
        is an identity function for all except overlay dentries"
      
      * 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs:
        ovl: fix uid/gid when creating over whiteout
        ovl: xattr filter fix
        af_unix: fix hard linked sockets on overlay
        vfs: add d_real_inode() helper
      9c514bed
    • Dan Carpenter's avatar
      KEYS: potential uninitialized variable · 38327424
      Dan Carpenter authored
      If __key_link_begin() failed then "edit" would be uninitialized.  I've
      added a check to fix that.
      
      This allows a random user to crash the kernel, though it's quite
      difficult to achieve.  There are three ways it can be done as the user
      would have to cause an error to occur in __key_link():
      
       (1) Cause the kernel to run out of memory.  In practice, this is difficult
           to achieve without ENOMEM cropping up elsewhere and aborting the
           attempt.
      
       (2) Revoke the destination keyring between the keyring ID being looked up
           and it being tested for revocation.  In practice, this is difficult to
           time correctly because the KEYCTL_REJECT function can only be used
           from the request-key upcall process.  Further, users can only make use
           of what's in /sbin/request-key.conf, though this does including a
           rejection debugging test - which means that the destination keyring
           has to be the caller's session keyring in practice.
      
       (3) Have just enough key quota available to create a key, a new session
           keyring for the upcall and a link in the session keyring, but not then
           sufficient quota to create a link in the nominated destination keyring
           so that it fails with EDQUOT.
      
      The bug can be triggered using option (3) above using something like the
      following:
      
      	echo 80 >/proc/sys/kernel/keys/root_maxbytes
      	keyctl request2 user debug:fred negate @t
      
      The above sets the quota to something much lower (80) to make the bug
      easier to trigger, but this is dependent on the system.  Note also that
      the name of the keyring created contains a random number that may be
      between 1 and 10 characters in size, so may throw the test off by
      changing the amount of quota used.
      
      Assuming the failure occurs, something like the following will be seen:
      
      	kfree_debugcheck: out of range ptr 6b6b6b6b6b6b6b68h
      	------------[ cut here ]------------
      	kernel BUG at ../mm/slab.c:2821!
      	...
      	RIP: 0010:[<ffffffff811600f9>] kfree_debugcheck+0x20/0x25
      	RSP: 0018:ffff8804014a7de8  EFLAGS: 00010092
      	RAX: 0000000000000034 RBX: 6b6b6b6b6b6b6b68 RCX: 0000000000000000
      	RDX: 0000000000040001 RSI: 00000000000000f6 RDI: 0000000000000300
      	RBP: ffff8804014a7df0 R08: 0000000000000001 R09: 0000000000000000
      	R10: ffff8804014a7e68 R11: 0000000000000054 R12: 0000000000000202
      	R13: ffffffff81318a66 R14: 0000000000000000 R15: 0000000000000001
      	...
      	Call Trace:
      	  kfree+0xde/0x1bc
      	  assoc_array_cancel_edit+0x1f/0x36
      	  __key_link_end+0x55/0x63
      	  key_reject_and_link+0x124/0x155
      	  keyctl_reject_key+0xb6/0xe0
      	  keyctl_negate_key+0x10/0x12
      	  SyS_keyctl+0x9f/0xe7
      	  do_syscall_64+0x63/0x13a
      	  entry_SYSCALL64_slow_path+0x25/0x25
      
      Fixes: f70e2e06 ('KEYS: Do preallocation for __key_link()')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      38327424
  3. 16 Jun, 2016 14 commits
  4. 15 Jun, 2016 16 commits
    • Suravee Suthikulpanit's avatar
      kvm: svm: Do not support AVIC if not CONFIG_X86_LOCAL_APIC · 5b8abf1f
      Suravee Suthikulpanit authored
      Add logic to disable AVIC #ifndef CONFIG_X86_LOCAL_APIC.
      Suggested-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSuravee Suthikulpanit <suravee.suthikulpanit@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      5b8abf1f
    • Suravee Suthikulpanit's avatar
      kvm: svm: Fix implicit declaration for __default_cpu_present_to_apicid() · 7d669f50
      Suravee Suthikulpanit authored
      The commit 8221c137 ("svm: Manage vcpu load/unload when enable AVIC")
      introduces a build error due to implicit function declaration
      when #ifdef CONFIG_X86_32 and #ifndef CONFIG_X86_LOCAL_APIC
      (as reported by Kbuild test robot i386-randconfig-x0-06121009).
      
      So, this patch introduces kvm_cpu_get_apicid() wrapper
      around __default_cpu_present_to_apicid() with additional
      handling if CONFIG_X86_LOCAL_APIC is not defined.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Fixes: commit 8221c137 ("svm: Manage vcpu load/unload when enable AVIC")
      Signed-off-by: default avatarSuravee Suthikulpanit <suravee.suthikulpanit@amd.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      7d669f50
    • Dave Airlie's avatar
      Merge branch 'drm-etnaviv-fixes' of git://git.pengutronix.de/git/lst/linux into drm-fixes · d9724d3b
      Dave Airlie authored
      just a single fix for a regression introduced by IOMMU API changes in
      v4.7.
      
      * 'drm-etnaviv-fixes' of git://git.pengutronix.de/git/lst/linux:
        drm/etnaviv: initialize iommu domain page size
      d9724d3b
    • J. Bruce Fields's avatar
      rpc: share one xps between all backchannels · 39a9beab
      J. Bruce Fields authored
      The spec allows backchannels for multiple clients to share the same tcp
      connection.  When that happens, we need to use the same xprt for all of
      them.  Similarly, we need the same xps.
      
      This fixes list corruption introduced by the multipath code.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Acked-by: default avatarTrond Myklebust <trondmy@primarydata.com>
      39a9beab
    • J. Bruce Fields's avatar
      nfsd4/rpc: move backchannel create logic into rpc code · d50039ea
      J. Bruce Fields authored
      Also simplify the logic a bit.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Acked-by: default avatarTrond Myklebust <trondmy@primarydata.com>
      d50039ea
    • J. Bruce Fields's avatar
      SUNRPC: fix xprt leak on xps allocation failure · 1208fd56
      J. Bruce Fields authored
      Callers of rpc_create_xprt expect it to put the xprt on success and
      failure.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Acked-by: default avatarTrond Myklebust <trondmy@primarydata.com>
      1208fd56
    • Miklos Szeredi's avatar
      ovl: fix uid/gid when creating over whiteout · d0e13f5b
      Miklos Szeredi authored
      Fix a regression when creating a file over a whiteout.  The new
      file/directory needs to use the current fsuid/fsgid, not the ones from the
      mounter's credentials.
      
      The refcounting is a bit tricky: prepare_creds() sets an original refcount,
      override_creds() gets one more, which revert_cred() drops.  So
      
        1) we need to expicitly put the mounter's credentials when overriding
           with the updated one
      
        2) we need to put the original ref to the updated creds (and this can
           safely be done before revert_creds(), since we'll still have the ref
           from override_creds()).
      Reported-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Fixes: 3fe6e52f ("ovl: override creds with the ones from the superblock mounter")
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      d0e13f5b
    • Will Deacon's avatar
      arm64: spinlock: Ensure forward-progress in spin_unlock_wait · c56bdcac
      Will Deacon authored
      Rather than wait until we observe the lock being free (which might never
      happen), we can also return from spin_unlock_wait if we observe that the
      lock is now held by somebody else, which implies that it was unlocked
      but we just missed seeing it in that state.
      
      Furthermore, in such a scenario there is no longer a need to write back
      the value that we loaded, since we know that there has been a lock
      hand-off, which is sufficient to publish any stores prior to the
      unlock_wait because the ARm architecture ensures that a Store-Release
      instruction is multi-copy atomic when observed by a Load-Acquire
      instruction.
      
      The litmus test is something like:
      
      AArch64
      {
      0:X1=x; 0:X3=y;
      1:X1=y;
      2:X1=y; 2:X3=x;
      }
       P0          | P1           | P2           ;
       MOV W0,#1   | MOV W0,#1    | LDAR W0,[X1] ;
       STR W0,[X1] | STLR W0,[X1] | LDR W2,[X3]  ;
       DMB SY      |              |              ;
       LDR W2,[X3] |              |              ;
      exists
      (0:X2=0 /\ 2:X0=1 /\ 2:X2=0)
      
      where P0 is doing spin_unlock_wait, P1 is doing spin_unlock and P2 is
      doing spin_lock.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      c56bdcac
    • John Keeping's avatar
      iommu/rockchip: Fix zap cache during device attach · ae8a7910
      John Keeping authored
      rk_iommu_command() takes a struct rk_iommu and iterates over the slave
      MMUs, so this is doubly wrong in that we're passing in the wrong pointer
      and talking to MMUs that we shouldn't be.
      
      Fixes: cd6438c5 ("iommu/rockchip: Reconstruct to support multi slaves")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohn Keeping <john@metanate.com>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Reviewed-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      ae8a7910
    • Lucas Stach's avatar
      drm/etnaviv: initialize iommu domain page size · 13c34fe5
      Lucas Stach authored
      Since d16e0faa (iommu: Allow selecting page sizes per domain) the
      iommu core demands the page size to be set per domain, otherwise any
      mapping attempts will be dropped. Make sure to set a valid page size
      for the etnaviv iommu.
      Signed-off-by: default avatarLucas Stach <l.stach@pengutronix.de>
      13c34fe5
    • Will Deacon's avatar
      arm64: spinlock: fix spin_unlock_wait for LSE atomics · 3a5facd0
      Will Deacon authored
      Commit d86b8da0 ("arm64: spinlock: serialise spin_unlock_wait against
      concurrent lockers") fixed spin_unlock_wait for LL/SC-based atomics under
      the premise that the LSE atomics (in particular, the LDADDA instruction)
      are indivisible.
      
      Unfortunately, these instructions are only indivisible when used with the
      -AL (full ordering) suffix and, consequently, the same issue can
      theoretically be observed with LSE atomics, where a later (in program
      order) load can be speculated before the write portion of the atomic
      operation.
      
      This patch fixes the issue by performing a CAS of the lock once we've
      established that it's unlocked, in much the same way as the LL/SC code.
      
      Fixes: d86b8da0 ("arm64: spinlock: serialise spin_unlock_wait against concurrent lockers")
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      3a5facd0
    • Will Deacon's avatar
      arm64: spinlock: order spin_{is_locked,unlock_wait} against local locks · 38b850a7
      Will Deacon authored
      spin_is_locked has grown two very different use-cases:
      
      (1) [The sane case] API functions may require a certain lock to be held
          by the caller and can therefore use spin_is_locked as part of an
          assert statement in order to verify that the lock is indeed held.
          For example, usage of assert_spin_locked.
      
      (2) [The insane case] There are two locks, where a CPU takes one of the
          locks and then checks whether or not the other one is held before
          accessing some shared state. For example, the "optimized locking" in
          ipc/sem.c.
      
      In the latter case, the sequence looks like:
      
        spin_lock(&sem->lock);
        if (!spin_is_locked(&sma->sem_perm.lock))
          /* Access shared state */
      
      and requires that the spin_is_locked check is ordered after taking the
      sem->lock. Unfortunately, since our spinlocks are implemented using a
      LDAXR/STXR sequence, the read of &sma->sem_perm.lock can be speculated
      before the STXR and consequently return a stale value.
      
      Whilst this hasn't been seen to cause issues in practice, PowerPC fixed
      the same issue in 51d7d520 ("powerpc: Add smp_mb() to
      arch_spin_is_locked()") and, although we did something similar for
      spin_unlock_wait in d86b8da0 ("arm64: spinlock: serialise
      spin_unlock_wait against concurrent lockers") that doesn't actually take
      care of ordering against local acquisition of a different lock.
      
      This patch adds an smp_mb() to the start of our arch_spin_is_locked and
      arch_spin_unlock_wait routines to ensure that the lock value is always
      loaded after any other locks have been taken by the current CPU.
      Reported-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      38b850a7
    • Mark Salter's avatar
      arm: pmu: Fix non-devicetree probing · f7a6c149
      Mark Salter authored
      There is a problem in the non-devicetree PMU probing where some
      probe functions may get the number of supported events through
      smp_call_function_any() using the arm_pmu supported_cpus mask.
      But at the time the probe function is called, the supported_cpus
      mask is empty so the call fails. This patch makes sure the mask
      is set before calling the init function rather than after.
      Signed-off-by: default avatarMark Salter <msalter@redhat.com>
      Signed-off-by: default avatarJeremy Linton <jeremy.linton@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      f7a6c149
    • Dave Airlie's avatar
      Merge branch 'linux-4.7' of git://github.com/skeggsb/linux into drm-fixes · e43fc946
      Dave Airlie authored
      * 'linux-4.7' of git://github.com/skeggsb/linux:
        drm/nouveau/iccsense: fix memory leak
        drm/nouveau/Revert "drm/nouveau/device/pci: set as non-CPU-coherent on ARM64"
      e43fc946
    • Ben Skeggs's avatar
      drm/nouveau/iccsense: fix memory leak · 6aa85f11
      Ben Skeggs authored
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      6aa85f11
    • Robin Murphy's avatar
      drm/nouveau/Revert "drm/nouveau/device/pci: set as non-CPU-coherent on ARM64" · 539aae6e
      Robin Murphy authored
      This reverts commit 1733a2ad.
      
      There is apparently something amiss with the way the TTM code handles
      DMA buffers, which the above commit was attempting to work around for
      arm64 systems with non-coherent PCI. Unfortunately, this completely
      breaks systems *with* coherent PCI (which appear to be the majority).
      
      Booting a plain arm64 defconfig + CONFIG_DRM + CONFIG_DRM_NOUVEAU on
      a machine with a PCI GPU having coherent dma_map_ops (in this case a
      7600GT card plugged into an ARM Juno board) results in a fatal crash:
      
      [    2.803438] nouveau 0000:06:00.0: DRM: allocated 1024x768 fb: 0x9000, bo ffffffc976141c00
      [    2.897662] Unable to handle kernel NULL pointer dereference at virtual address 000001ac
      [    2.897666] pgd = ffffff8008e00000
      [    2.897675] [000001ac] *pgd=00000009ffffe003, *pud=00000009ffffe003, *pmd=0000000000000000
      [    2.897680] Internal error: Oops: 96000045 [#1] PREEMPT SMP
      [    2.897685] Modules linked in:
      [    2.897692] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc5+ #543
      [    2.897694] Hardware name: ARM Juno development board (r1) (DT)
      [    2.897699] task: ffffffc9768a0000 ti: ffffffc9768a8000 task.ti: ffffffc9768a8000
      [    2.897711] PC is at __memcpy+0x7c/0x180
      [    2.897719] LR is at OUT_RINGp+0x34/0x70
      [    2.897724] pc : [<ffffff80083465fc>] lr : [<ffffff800854248c>] pstate: 80000045
      [    2.897726] sp : ffffffc9768ab360
      [    2.897732] x29: ffffffc9768ab360 x28: 0000000000000001
      [    2.897738] x27: ffffffc97624c000 x26: 0000000000000000
      [    2.897744] x25: 0000000000000080 x24: 0000000000006c00
      [    2.897749] x23: 0000000000000005 x22: ffffffc97624c010
      [    2.897755] x21: 0000000000000004 x20: 0000000000000004
      [    2.897761] x19: ffffffc9763da000 x18: ffffffc976b2491c
      [    2.897766] x17: 0000000000000007 x16: 0000000000000006
      [    2.897771] x15: 0000000000000001 x14: 0000000000000001
      [    2.897777] x13: 0000000000e31b70 x12: ffffffc9768a0080
      [    2.897783] x11: 0000000000000000 x10: fffffffffffffb00
      [    2.897788] x9 : 0000000000000000 x8 : 0000000000000000
      [    2.897793] x7 : 0000000000000000 x6 : 00000000000001ac
      [    2.897799] x5 : 00000000ffffffff x4 : 0000000000000000
      [    2.897804] x3 : 0000000000000010 x2 : 0000000000000010
      [    2.897810] x1 : ffffffc97624c010 x0 : 00000000000001ac
      ...
      [    2.898494] Call trace:
      [    2.898499] Exception stack(0xffffffc9768ab1a0 to 0xffffffc9768ab2c0)
      [    2.898506] b1a0: ffffffc9763da000 0000000000000004 ffffffc9768ab360 ffffff80083465fc
      [    2.898513] b1c0: ffffffc976801e00 ffffffc9762b8000 ffffffc9768ab1f0 ffffff80080ec158
      [    2.898520] b1e0: ffffffc9768ab230 ffffff8008496d04 ffffffc975ce6d80 ffffffc9768ab36e
      [    2.898527] b200: ffffffc9768ab36f ffffffc9768ab29d ffffffc9768ab29e ffffffc9768a0000
      [    2.898533] b220: ffffffc9768ab250 ffffff80080e70c0 ffffffc9768ab270 ffffff8008496e44
      [    2.898540] b240: 00000000000001ac ffffffc97624c010 0000000000000010 0000000000000010
      [    2.898546] b260: 0000000000000000 00000000ffffffff 00000000000001ac 0000000000000000
      [    2.898552] b280: 0000000000000000 0000000000000000 fffffffffffffb00 0000000000000000
      [    2.898558] b2a0: ffffffc9768a0080 0000000000e31b70 0000000000000001 0000000000000001
      [    2.898566] [<ffffff80083465fc>] __memcpy+0x7c/0x180
      [    2.898574] [<ffffff800853e164>] nv04_fbcon_imageblit+0x1d4/0x2e8
      [    2.898582] [<ffffff800853d6d0>] nouveau_fbcon_imageblit+0xd8/0xe0
      [    2.898591] [<ffffff80083c4db4>] soft_cursor+0x154/0x1d8
      [    2.898598] [<ffffff80083c47b4>] bit_cursor+0x4fc/0x538
      [    2.898605] [<ffffff80083c0cfc>] fbcon_cursor+0x134/0x1a8
      [    2.898613] [<ffffff800841c280>] hide_cursor+0x38/0xa0
      [    2.898620] [<ffffff800841d420>] redraw_screen+0x120/0x228
      [    2.898628] [<ffffff80083bf268>] fbcon_prepare_logo+0x370/0x3f8
      [    2.898635] [<ffffff80083bf640>] fbcon_init+0x350/0x560
      [    2.898641] [<ffffff800841c634>] visual_init+0xac/0x108
      [    2.898648] [<ffffff800841df14>] do_bind_con_driver+0x1c4/0x3a8
      [    2.898655] [<ffffff800841e4f4>] do_take_over_console+0x174/0x1e8
      [    2.898662] [<ffffff80083bf8c4>] do_fbcon_takeover+0x74/0x100
      [    2.898669] [<ffffff80083c3e44>] fbcon_event_notify+0x8cc/0x920
      [    2.898680] [<ffffff80080d7e38>] notifier_call_chain+0x50/0x90
      [    2.898685] [<ffffff80080d8214>] __blocking_notifier_call_chain+0x4c/0x90
      [    2.898691] [<ffffff80080d826c>] blocking_notifier_call_chain+0x14/0x20
      [    2.898696] [<ffffff80083c5e1c>] fb_notifier_call_chain+0x1c/0x28
      [    2.898703] [<ffffff80083c81ac>] register_framebuffer+0x1cc/0x2e0
      [    2.898712] [<ffffff800845da80>] drm_fb_helper_initial_config+0x288/0x3e8
      [    2.898719] [<ffffff800853da20>] nouveau_fbcon_init+0xe0/0x118
      [    2.898727] [<ffffff800852d2f8>] nouveau_drm_load+0x268/0x890
      [    2.898734] [<ffffff8008466e24>] drm_dev_register+0xbc/0xc8
      [    2.898740] [<ffffff8008468a88>] drm_get_pci_dev+0xa0/0x180
      [    2.898747] [<ffffff800852cb28>] nouveau_drm_probe+0x1a0/0x1e0
      [    2.898755] [<ffffff80083a32e0>] pci_device_probe+0x98/0x110
      [    2.898763] [<ffffff800858e434>] driver_probe_device+0x204/0x2b0
      [    2.898770] [<ffffff800858e58c>] __driver_attach+0xac/0xb0
      [    2.898777] [<ffffff800858c3e0>] bus_for_each_dev+0x60/0xa0
      [    2.898783] [<ffffff800858dbc0>] driver_attach+0x20/0x28
      [    2.898789] [<ffffff800858d7b0>] bus_add_driver+0x1d0/0x238
      [    2.898796] [<ffffff800858ed50>] driver_register+0x60/0xf8
      [    2.898802] [<ffffff80083a20dc>] __pci_register_driver+0x3c/0x48
      [    2.898809] [<ffffff8008468eb4>] drm_pci_init+0xf4/0x120
      [    2.898818] [<ffffff8008c56fc0>] nouveau_drm_init+0x21c/0x230
      [    2.898825] [<ffffff80080829d4>] do_one_initcall+0x8c/0x190
      [    2.898832] [<ffffff8008c31af4>] kernel_init_freeable+0x14c/0x1f0
      [    2.898839] [<ffffff80088a0c20>] kernel_init+0x10/0x100
      [    2.898845] [<ffffff8008085e10>] ret_from_fork+0x10/0x40
      [    2.898853] Code: a88120c7 a8c12027 a88120c7 a8c12027 (a88120c7)
      [    2.898871] ---[ end trace d5713dcad023ee04 ]---
      [    2.898888] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      
      In a toss-up between the GPU seeing stale data artefacts on some systems
      vs. catastrophic kernel crashes on other systems, the latter would seem
      to take precedence, so revert this change until the real underlying
      problem can be fixed.
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Acked-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      [acourbot@nvidia.com: port to Nouveau tree, remove bits in lib/]
      Signed-off-by: default avatarAlexandre Courbot <acourbot@nvidia.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Cc: stable@vger.kernel.org
      539aae6e