1. 01 May, 2016 1 commit
  2. 30 Apr, 2016 1 commit
    • Chris Wilson's avatar
      kernfs: Move faulting copy_user operations outside of the mutex · e4234a1f
      Chris Wilson authored
      A fault in a user provided buffer may lead anywhere, and lockdep warns
      that we have a potential deadlock between the mm->mmap_sem and the
      kernfs file mutex:
      
      [   82.811702] ======================================================
      [   82.811705] [ INFO: possible circular locking dependency detected ]
      [   82.811709] 4.5.0-rc4-gfxbench+ #1 Not tainted
      [   82.811711] -------------------------------------------------------
      [   82.811714] kms_setmode/5859 is trying to acquire lock:
      [   82.811717]  (&dev->struct_mutex){+.+.+.}, at: [<ffffffff8150d9c1>] drm_gem_mmap+0x1a1/0x270
      [   82.811731]
      but task is already holding lock:
      [   82.811734]  (&mm->mmap_sem){++++++}, at: [<ffffffff8117b364>] vm_mmap_pgoff+0x44/0xa0
      [   82.811745]
      which lock already depends on the new lock.
      
      [   82.811749]
      the existing dependency chain (in reverse order) is:
      [   82.811752]
      -> #3 (&mm->mmap_sem){++++++}:
      [   82.811761]        [<ffffffff810cc883>] lock_acquire+0xc3/0x1d0
      [   82.811766]        [<ffffffff8118bc65>] __might_fault+0x75/0xa0
      [   82.811771]        [<ffffffff8124da4a>] kernfs_fop_write+0x8a/0x180
      [   82.811787]        [<ffffffff811d1023>] __vfs_write+0x23/0xe0
      [   82.811792]        [<ffffffff811d1d74>] vfs_write+0xa4/0x190
      [   82.811797]        [<ffffffff811d2c14>] SyS_write+0x44/0xb0
      [   82.811801]        [<ffffffff817bb81b>] entry_SYSCALL_64_fastpath+0x16/0x73
      [   82.811807]
      -> #2 (s_active#6){++++.+}:
      [   82.811814]        [<ffffffff810cc883>] lock_acquire+0xc3/0x1d0
      [   82.811819]        [<ffffffff8124c070>] __kernfs_remove+0x210/0x2f0
      [   82.811823]        [<ffffffff8124d040>] kernfs_remove_by_name_ns+0x40/0xa0
      [   82.811828]        [<ffffffff8124e9e0>] sysfs_remove_file_ns+0x10/0x20
      [   82.811832]        [<ffffffff815318d4>] device_del+0x124/0x250
      [   82.811837]        [<ffffffff81531a19>] device_unregister+0x19/0x60
      [   82.811841]        [<ffffffff8153c051>] cpu_cache_sysfs_exit+0x51/0xb0
      [   82.811846]        [<ffffffff8153c628>] cacheinfo_cpu_callback+0x38/0x70
      [   82.811851]        [<ffffffff8109ae89>] notifier_call_chain+0x39/0xa0
      [   82.811856]        [<ffffffff8109aef9>] __raw_notifier_call_chain+0x9/0x10
      [   82.811860]        [<ffffffff810786de>] cpu_notify+0x1e/0x40
      [   82.811865]        [<ffffffff81078779>] cpu_notify_nofail+0x9/0x20
      [   82.811869]        [<ffffffff81078ac3>] _cpu_down+0x233/0x340
      [   82.811874]        [<ffffffff81079019>] disable_nonboot_cpus+0xc9/0x350
      [   82.811878]        [<ffffffff810d2e11>] suspend_devices_and_enter+0x5a1/0xb50
      [   82.811883]        [<ffffffff810d3903>] pm_suspend+0x543/0x8d0
      [   82.811888]        [<ffffffff810d1b77>] state_store+0x77/0xe0
      [   82.811892]        [<ffffffff813fa68f>] kobj_attr_store+0xf/0x20
      [   82.811897]        [<ffffffff8124e740>] sysfs_kf_write+0x40/0x50
      [   82.811902]        [<ffffffff8124dafc>] kernfs_fop_write+0x13c/0x180
      [   82.811906]        [<ffffffff811d1023>] __vfs_write+0x23/0xe0
      [   82.811910]        [<ffffffff811d1d74>] vfs_write+0xa4/0x190
      [   82.811914]        [<ffffffff811d2c14>] SyS_write+0x44/0xb0
      [   82.811918]        [<ffffffff817bb81b>] entry_SYSCALL_64_fastpath+0x16/0x73
      [   82.811923]
      -> #1 (cpu_hotplug.lock){+.+.+.}:
      [   82.811929]        [<ffffffff810cc883>] lock_acquire+0xc3/0x1d0
      [   82.811933]        [<ffffffff817b6f72>] mutex_lock_nested+0x62/0x3b0
      [   82.811940]        [<ffffffff810784c1>] get_online_cpus+0x61/0x80
      [   82.811944]        [<ffffffff811170eb>] stop_machine+0x1b/0xe0
      [   82.811949]        [<ffffffffa0178edd>] gen8_ggtt_insert_entries__BKL+0x2d/0x30 [i915]
      [   82.812009]        [<ffffffffa017d3a6>] ggtt_bind_vma+0x46/0x70 [i915]
      [   82.812045]        [<ffffffffa017eb70>] i915_vma_bind+0x140/0x290 [i915]
      [   82.812081]        [<ffffffffa01862b9>] i915_gem_object_do_pin+0x899/0xb00 [i915]
      [   82.812117]        [<ffffffffa0186555>] i915_gem_object_pin+0x35/0x40 [i915]
      [   82.812154]        [<ffffffffa019a23e>] intel_init_pipe_control+0xbe/0x210 [i915]
      [   82.812192]        [<ffffffffa0197312>] intel_logical_rings_init+0xe2/0xde0 [i915]
      [   82.812232]        [<ffffffffa0186fe3>] i915_gem_init+0xf3/0x130 [i915]
      [   82.812278]        [<ffffffffa02097ed>] i915_driver_load+0xf2d/0x1770 [i915]
      [   82.812318]        [<ffffffff81512474>] drm_dev_register+0xa4/0xb0
      [   82.812323]        [<ffffffff8151467e>] drm_get_pci_dev+0xce/0x1e0
      [   82.812328]        [<ffffffffa01472cf>] i915_pci_probe+0x2f/0x50 [i915]
      [   82.812360]        [<ffffffff8143f907>] pci_device_probe+0x87/0xf0
      [   82.812366]        [<ffffffff81535f89>] driver_probe_device+0x229/0x450
      [   82.812371]        [<ffffffff81536233>] __driver_attach+0x83/0x90
      [   82.812375]        [<ffffffff81533c61>] bus_for_each_dev+0x61/0xa0
      [   82.812380]        [<ffffffff81535879>] driver_attach+0x19/0x20
      [   82.812384]        [<ffffffff8153535f>] bus_add_driver+0x1ef/0x290
      [   82.812388]        [<ffffffff81536e9b>] driver_register+0x5b/0xe0
      [   82.812393]        [<ffffffff8143e83b>] __pci_register_driver+0x5b/0x60
      [   82.812398]        [<ffffffff81514866>] drm_pci_init+0xd6/0x100
      [   82.812402]        [<ffffffffa027c094>] 0xffffffffa027c094
      [   82.812406]        [<ffffffff810003de>] do_one_initcall+0xae/0x1d0
      [   82.812412]        [<ffffffff811595a0>] do_init_module+0x5b/0x1cb
      [   82.812417]        [<ffffffff81106160>] load_module+0x1c20/0x2480
      [   82.812422]        [<ffffffff81106bae>] SyS_finit_module+0x7e/0xa0
      [   82.812428]        [<ffffffff817bb81b>] entry_SYSCALL_64_fastpath+0x16/0x73
      [   82.812433]
      -> #0 (&dev->struct_mutex){+.+.+.}:
      [   82.812439]        [<ffffffff810cbe59>] __lock_acquire+0x1fc9/0x20f0
      [   82.812443]        [<ffffffff810cc883>] lock_acquire+0xc3/0x1d0
      [   82.812456]        [<ffffffff8150d9e7>] drm_gem_mmap+0x1c7/0x270
      [   82.812460]        [<ffffffff81196a14>] mmap_region+0x334/0x580
      [   82.812466]        [<ffffffff81196fc4>] do_mmap+0x364/0x410
      [   82.812470]        [<ffffffff8117b38d>] vm_mmap_pgoff+0x6d/0xa0
      [   82.812474]        [<ffffffff811950f4>] SyS_mmap_pgoff+0x184/0x220
      [   82.812479]        [<ffffffff8100a0fd>] SyS_mmap+0x1d/0x20
      [   82.812484]        [<ffffffff817bb81b>] entry_SYSCALL_64_fastpath+0x16/0x73
      [   82.812489]
      other info that might help us debug this:
      
      [   82.812493] Chain exists of:
        &dev->struct_mutex --> s_active#6 --> &mm->mmap_sem
      
      [   82.812502]  Possible unsafe locking scenario:
      
      [   82.812506]        CPU0                    CPU1
      [   82.812508]        ----                    ----
      [   82.812510]   lock(&mm->mmap_sem);
      [   82.812514]                                lock(s_active#6);
      [   82.812519]                                lock(&mm->mmap_sem);
      [   82.812522]   lock(&dev->struct_mutex);
      [   82.812526]
       *** DEADLOCK ***
      
      [   82.812531] 1 lock held by kms_setmode/5859:
      [   82.812533]  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff8117b364>] vm_mmap_pgoff+0x44/0xa0
      [   82.812541]
      stack backtrace:
      [   82.812547] CPU: 0 PID: 5859 Comm: kms_setmode Not tainted 4.5.0-rc4-gfxbench+ #1
      [   82.812550] Hardware name:                  /NUC5CPYB, BIOS PYBSWCEL.86A.0040.2015.0814.1353 08/14/2015
      [   82.812553]  0000000000000000 ffff880079407bf0 ffffffff813f8505 ffffffff825fb270
      [   82.812560]  ffffffff825c4190 ffff880079407c30 ffffffff810c84ac ffff880079407c90
      [   82.812566]  ffff8800797ed328 ffff8800797ecb00 0000000000000001 ffff8800797ed350
      [   82.812573] Call Trace:
      [   82.812578]  [<ffffffff813f8505>] dump_stack+0x67/0x92
      [   82.812582]  [<ffffffff810c84ac>] print_circular_bug+0x1fc/0x310
      [   82.812586]  [<ffffffff810cbe59>] __lock_acquire+0x1fc9/0x20f0
      [   82.812590]  [<ffffffff810cc883>] lock_acquire+0xc3/0x1d0
      [   82.812594]  [<ffffffff8150d9c1>] ? drm_gem_mmap+0x1a1/0x270
      [   82.812599]  [<ffffffff8150d9e7>] drm_gem_mmap+0x1c7/0x270
      [   82.812603]  [<ffffffff8150d9c1>] ? drm_gem_mmap+0x1a1/0x270
      [   82.812608]  [<ffffffff81196a14>] mmap_region+0x334/0x580
      [   82.812612]  [<ffffffff81196fc4>] do_mmap+0x364/0x410
      [   82.812616]  [<ffffffff8117b38d>] vm_mmap_pgoff+0x6d/0xa0
      [   82.812629]  [<ffffffff811950f4>] SyS_mmap_pgoff+0x184/0x220
      [   82.812633]  [<ffffffff8100a0fd>] SyS_mmap+0x1d/0x20
      [   82.812637]  [<ffffffff817bb81b>] entry_SYSCALL_64_fastpath+0x16/0x73
      
      Highly unlikely though this scenario is, we can avoid the issue entirely
      by moving the copy operation from out under the kernfs_get_active()
      tracking by assigning the preallocated buffer its own mutex. The
      temporary buffer allocation doesn't require mutex locking as it is
      entirely local.
      
      The locked section was extended by the addition of the preallocated buf
      to speed up md user operations in
      
      commit 2b75869b
      Author: NeilBrown <neilb@suse.de>
      Date:   Mon Oct 13 16:41:28 2014 +1100
      
          sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
      Reported-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94350Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: NeilBrown <neilb@suse.de>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4234a1f
  3. 18 Apr, 2016 2 commits
  4. 17 Apr, 2016 5 commits
  5. 16 Apr, 2016 7 commits
  6. 15 Apr, 2016 18 commits
  7. 14 Apr, 2016 6 commits
    • Mike Snitzer's avatar
      dm cache metadata: fix READ_LOCK macros and cleanup WRITE_LOCK macros · 9567366f
      Mike Snitzer authored
      The READ_LOCK macro was incorrectly returning -EINVAL if
      dm_bm_is_read_only() was true -- it will always be true once the cache
      metadata transitions to read-only by dm_cache_metadata_set_read_only().
      
      Wrap READ_LOCK and WRITE_LOCK multi-statement macros in do {} while(0).
      Also, all accesses of the 'cmd' argument passed to these related macros
      are now encapsulated in parenthesis.
      
      A follow-up patch can be developed to eliminate the use of macros in
      favor of pure C code.  Avoiding that now given that this needs to apply
      to stable@.
      Reported-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Fixes: d14fcf3d ("dm cache: make sure every metadata function checks fail_io")
      Cc: stable@vger.kernel.org
      9567366f
    • Keith Busch's avatar
      NVMe: Always use MSI/MSI-x interrupts · a5229050
      Keith Busch authored
      Multiple users have reported device initialization failure due the driver
      not receiving legacy PCI interrupts. This is not unique to any particular
      controller, but has been observed on multiple platforms.
      
      There have been no issues reported or observed when with message signaled
      interrupts, so this patch attempts to use MSI-x during initialization,
      falling back to MSI. If that fails, legacy would become the default.
      
      The setup_io_queues error handling had to change as a result: the admin
      queue's msix_entry used to be initialized to the legacy IRQ. The case
      where nr_io_queues is 0 would fail request_irq when setting up the admin
      queue's interrupt since re-enabling MSI-x fails with 0 vectors, leaving
      the admin queue's msix_entry invalid. Instead, return success immediately.
      Reported-by: default avatarTim Muhlemmer <muhlemmer@gmail.com>
      Reported-by: default avatarJon Derrick <jonathan.derrick@intel.com>
      Signed-off-by: default avatarKeith Busch <keith.busch@intel.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      a5229050
    • Linus Torvalds's avatar
      /proc/iomem: only expose physical resource addresses to privileged users · 51d7b120
      Linus Torvalds authored
      In commit c4004b02 ("x86: remove the kernel code/data/bss resources
      from /proc/iomem") I was hoping to remove the phyiscal kernel address
      data from /proc/iomem entirely, but that had to be reverted because some
      system programs actually use it.
      
      This limits all the detailed resource information to properly
      credentialed users instead.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      51d7b120
    • Linus Torvalds's avatar
      pci-sysfs: use proper file capability helper function · ab0fa82b
      Linus Torvalds authored
      The PCI config access checked the file capabilities correctly, but used
      the itnernal security capability check rather than the helper function
      that is actually meant for that.
      
      The security_capable() has unusual return values and is not meant to be
      used elsewhere (the only other use is in the capability checking
      functions that we actually intend people to use, and this odd PCI usage
      really stood out when looking around the capability code.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ab0fa82b
    • Linus Torvalds's avatar
      Make file credentials available to the seqfile interfaces · 34dbbcdb
      Linus Torvalds authored
      A lot of seqfile users seem to be using things like %pK that uses the
      credentials of the current process, but that is actually completely
      wrong for filesystem interfaces.
      
      The unix semantics for permission checking files is to check permissions
      at _open_ time, not at read or write time, and that is not just a small
      detail: passing off stdin/stdout/stderr to a suid application and making
      the actual IO happen in privileged context is a classic exploit
      technique.
      
      So if we want to be able to look at permissions at read time, we need to
      use the file open credentials, not the current ones.  Normal file
      accesses can just use "f_cred" (or any of the helper functions that do
      that, like file_ns_capable()), but the seqfile interfaces do not have
      any such options.
      
      It turns out that seq_file _does_ save away the user_ns information of
      the file, though.  Since user_ns is just part of the full credential
      information, replace that special case with saving off the cred pointer
      instead, and suddenly seq_file has all the permission information it
      needs.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      34dbbcdb
    • Linus Torvalds's avatar
      Revert "x86: remove the kernel code/data/bss resources from /proc/iomem" · 4046d6e8
      Linus Torvalds authored
      This reverts commit c4004b02.
      
      Sadly, my hope that nobody would actually use the special kernel entries
      in /proc/iomem were dashed by kexec.  Which reads /proc/iomem explicitly
      to find the kernel base address.  Nasty.
      
      Anyway, that means we can't do the sane and simple thing and just remove
      the entries, and we'll instead have to mask them out based on permissions.
      Reported-by: default avatarZhengyu Zhang <zhezhang@redhat.com>
      Reported-by: default avatarDave Young <dyoung@redhat.com>
      Reported-by: default avatarFreeman Zhang <freeman.zhang1992@gmail.com>
      Reported-by: default avatarEmrah Demir <ed@abdsec.com>
      Reported-by: default avatarBaoquan He <bhe@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4046d6e8