1. 07 Jul, 2015 3 commits
    • Thomas Gleixner's avatar
      x86/irq: Retrieve irq data after locking irq_desc · 09cf92b7
      Thomas Gleixner authored
      irq_data is protected by irq_desc->lock, so retrieving the irq chip
      from irq_data outside the lock is racy vs. an concurrent update. Move
      it into the lock held region.
      
      While at it add a comment why the vector walk does not require
      vector_lock.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: xiao jin <jin.xiao@intel.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>
      Link: http://lkml.kernel.org/r/20150705171102.331320612@linutronix.de
      09cf92b7
    • Thomas Gleixner's avatar
      x86/irq: Use proper locking in check_irq_vectors_for_cpu_disable() · cbb24dc7
      Thomas Gleixner authored
      It's unsafe to examine fields in the irq descriptor w/o holding the
      descriptor lock. Add proper locking.
      
      While at it add a comment why the vector check can run lock less
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: xiao jin <jin.xiao@intel.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>
      Link: http://lkml.kernel.org/r/20150705171102.236544164@linutronix.de
      cbb24dc7
    • Thomas Gleixner's avatar
      x86/irq: Plug irq vector hotplug race · 5a3f75e3
      Thomas Gleixner authored
      Jin debugged a nasty cpu hotplug race which results in leaking a irq
      vector on the newly hotplugged cpu.
      
      cpu N				cpu M
      native_cpu_up                   device_shutdown
        do_boot_cpu			  free_msi_irqs
        start_secondary                   arch_teardown_msi_irqs
          smp_callin                        default_teardown_msi_irqs
             setup_vector_irq                  arch_teardown_msi_irq
              __setup_vector_irq		   native_teardown_msi_irq
                lock(vector_lock)		     destroy_irq 
                install vectors
                unlock(vector_lock)
      					       lock(vector_lock)
      --->                                  	       __clear_irq_vector
                                          	       unlock(vector_lock)
          lock(vector_lock)
          set_cpu_online
          unlock(vector_lock)
      
      This leaves the irq vector(s) which are torn down on CPU M stale in
      the vector array of CPU N, because CPU M does not see CPU N online
      yet. There is a similar issue with concurrent newly setup interrupts.
      
      The alloc/free protection of irq descriptors does not prevent the
      above race, because it merily prevents interrupt descriptors from
      going away or changing concurrently.
      
      Prevent this by moving the call to setup_vector_irq() into the
      vector_lock held region which protects set_cpu_online():
      
      cpu N				cpu M
      native_cpu_up                   device_shutdown
        do_boot_cpu			  free_msi_irqs
        start_secondary                   arch_teardown_msi_irqs
          smp_callin                        default_teardown_msi_irqs
             lock(vector_lock)                arch_teardown_msi_irq
             setup_vector_irq()
              __setup_vector_irq		   native_teardown_msi_irq
                install vectors		     destroy_irq 
             set_cpu_online
             unlock(vector_lock)
      					       lock(vector_lock)
                                        	       __clear_irq_vector
                                          	       unlock(vector_lock)
      
      So cpu M either sees the cpu N online before clearing the vector or
      cpu N installs the vectors after cpu M has cleared it.
      Reported-by: default avatarxiao jin <jin.xiao@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>
      Link: http://lkml.kernel.org/r/20150705171102.141898931@linutronix.de
      5a3f75e3
  2. 06 Jul, 2015 10 commits
  3. 05 Jul, 2015 4 commits
    • Linus Torvalds's avatar
      Linux 4.2-rc1 · d770e558
      Linus Torvalds authored
      d770e558
    • Linus Torvalds's avatar
      Merge tag 'platform-drivers-x86-v4.2-2' of... · a585d2b7
      Linus Torvalds authored
      Merge tag 'platform-drivers-x86-v4.2-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
      
      Pull late x86 platform driver updates from Darren Hart:
       "The following came in a bit later and I wanted them to bake in next a
        few more days before submitting, thus the second pull.
      
        A new intel_pmc_ipc driver, a symmetrical allocation and free fix in
        dell-laptop, a couple minor fixes, and some updated documentation in
        the dell-laptop comments.
      
        intel_pmc_ipc:
         - Add Intel Apollo Lake PMC IPC driver
      
        tc1100-wmi:
         - Delete an unnecessary check before the function call "kfree"
      
        dell-laptop:
         - Fix allocating & freeing SMI buffer page
         - Show info about WiGig and UWB in debugfs
         - Update information about wireless control"
      
      * tag 'platform-drivers-x86-v4.2-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86:
        intel_pmc_ipc: Add Intel Apollo Lake PMC IPC driver
        tc1100-wmi: Delete an unnecessary check before the function call "kfree"
        dell-laptop: Fix allocating & freeing SMI buffer page
        dell-laptop: Show info about WiGig and UWB in debugfs
        dell-laptop: Update information about wireless control
      a585d2b7
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · 1dc51b82
      Linus Torvalds authored
      Pull more vfs updates from Al Viro:
       "Assorted VFS fixes and related cleanups (IMO the most interesting in
        that part are f_path-related things and Eric's descriptor-related
        stuff).  UFS regression fixes (it got broken last cycle).  9P fixes.
        fs-cache series, DAX patches, Jan's file_remove_suid() work"
      
      [ I'd say this is much more than "fixes and related cleanups".  The
        file_table locking rule change by Eric Dumazet is a rather big and
        fundamental update even if the patch isn't huge.   - Linus ]
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (49 commits)
        9p: cope with bogus responses from server in p9_client_{read,write}
        p9_client_write(): avoid double p9_free_req()
        9p: forgetting to cancel request on interrupted zero-copy RPC
        dax: bdev_direct_access() may sleep
        block: Add support for DAX reads/writes to block devices
        dax: Use copy_from_iter_nocache
        dax: Add block size note to documentation
        fs/file.c: __fget() and dup2() atomicity rules
        fs/file.c: don't acquire files->file_lock in fd_install()
        fs:super:get_anon_bdev: fix race condition could cause dev exceed its upper limitation
        vfs: avoid creation of inode number 0 in get_next_ino
        namei: make set_root_rcu() return void
        make simple_positive() public
        ufs: use dir_pages instead of ufs_dir_pages()
        pagemap.h: move dir_pages() over there
        remove the pointless include of lglock.h
        fs: cleanup slight list_entry abuse
        xfs: Correctly lock inode when removing suid and file capabilities
        fs: Call security_ops->inode_killpriv on truncate
        fs: Provide function telling whether file_remove_privs() will do anything
        ...
      1dc51b82
    • Linus Torvalds's avatar
      bluetooth: fix list handling · 9b284cbd
      Linus Torvalds authored
      Commit 835a6a2f ("Bluetooth: Stop sabotaging list poisoning")
      thought that the code was sabotaging the list poisoning when NULL'ing
      out the list pointers and removed it.
      
      But what was going on was that the bluetooth code was using NULL
      pointers for the list as a way to mark it empty, and that commit just
      broke it (and replaced the test with NULL with a "list_empty()" test on
      a uninitialized list instead, breaking things even further).
      
      So fix it all up to use the regular and real list_empty() handling
      (which does not use NULL, but a pointer to itself), also making sure to
      initialize the list properly (the previous NULL case was initialized
      implicitly by the session being allocated with kzalloc())
      
      This is a combination of patches by Marcel Holtmann and Tedd Ho-Jeong
      An.
      
      [ I would normally expect to get this through the bt tree, but I'm going
        to release -rc1, so I'm just committing this directly   - Linus ]
      Reported-and-tested-by: default avatarJörg Otte <jrg.otte@gmail.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Original-by: default avatarTedd Ho-Jeong An <tedd.an@intel.com>
      Original-by: Marcel Holtmann <marcel@holtmann.org>:
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9b284cbd
  4. 04 Jul, 2015 23 commits