1. 25 12月, 2016 1 次提交
  2. 17 11月, 2016 1 次提交
  3. 22 9月, 2016 1 次提交
  4. 15 8月, 2016 1 次提交
  5. 03 5月, 2016 1 次提交
  6. 11 9月, 2015 1 次提交
    • W
      proc: change proc_subdir_lock to a rwlock · ecf1a3df
      Waiman Long 提交于
      The proc_subdir_lock spinlock is used to allow only one task to make
      change to the proc directory structure as well as looking up information
      in it.  However, the information lookup part can actually be entered by
      more than one task as the pde_get() and pde_put() reference count update
      calls in the critical sections are atomic increment and decrement
      respectively and so are safe with concurrent updates.
      
      The x86 architecture has already used qrwlock which is fair and other
      architectures like ARM are in the process of switching to qrwlock.  So
      unfairness shouldn't be a concern in that conversion.
      
      This patch changed the proc_subdir_lock to a rwlock in order to enable
      concurrent lookup. The following functions were modified to take a
      write lock:
       - proc_register()
       - remove_proc_entry()
       - remove_proc_subtree()
      
      The following functions were modified to take a read lock:
       - xlate_proc_name()
       - proc_lookup_de()
       - proc_readdir_de()
      
      A parallel /proc filesystem search with the "find" command (1000 threads)
      was run on a 4-socket Haswell-EX box (144 threads).  Before the patch, the
      parallel search took about 39s.  After the patch, the parallel find took
      only 25s, a saving of about 14s.
      
      The micro-benchmark that I used was artificial, but it was used to
      reproduce an exit hanging problem that I saw in real application.  In
      fact, only allow one task to do a lookup seems too limiting to me.
      Signed-off-by: NWaiman Long <Waiman.Long@hp.com>
      Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Scott J Norton <scott.norton@hp.com>
      Cc: Douglas Hatch <doug.hatch@hp.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ecf1a3df
  7. 01 7月, 2015 1 次提交
  8. 16 4月, 2015 1 次提交
  9. 23 2月, 2015 1 次提交
  10. 13 2月, 2015 1 次提交
  11. 26 1月, 2015 1 次提交
  12. 11 12月, 2014 3 次提交
  13. 09 8月, 2014 2 次提交
  14. 24 1月, 2014 1 次提交
  15. 16 11月, 2013 1 次提交
  16. 20 8月, 2013 1 次提交
    • L
      proc: more readdir conversion bug-fixes · fd3930f7
      Linus Torvalds 提交于
      In the previous commit, Richard Genoud fixed proc_root_readdir(), which
      had lost the check for whether all of the non-process /proc entries had
      been returned or not.
      
      But that in turn exposed _another_ bug, namely that the original readdir
      conversion patch had yet another problem: it had lost the return value
      of proc_readdir_de(), so now checking whether it had completed
      successfully or not didn't actually work right anyway.
      
      This reinstates the non-zero return for the "end of base entries" that
      had also gotten lost in commit f0c3b509 ("[readdir] convert
      procfs").  So now you get all the base entries *and* you get all the
      process entries, regardless of getdents buffer size.
      
      (Side note: the Linux "getdents" manual page actually has a nice example
      application for testing getdents, which can be easily modified to use
      different buffers.  Who knew? Man-pages can be useful)
      Reported-by: NEmmanuel Benisty <benisty.e@gmail.com>
      Reported-by: NMarc Dionne <marc.c.dionne@gmail.com>
      Cc: Richard Genoud <richard.genoud@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fd3930f7
  17. 29 6月, 2013 1 次提交
  18. 02 5月, 2013 5 次提交
  19. 30 4月, 2013 1 次提交
  20. 10 4月, 2013 7 次提交
  21. 28 2月, 2013 1 次提交
  22. 26 2月, 2013 1 次提交
  23. 23 2月, 2013 1 次提交
  24. 26 12月, 2012 1 次提交
    • E
      proc: Allow proc_free_inum to be called from any context · dfb2ea45
      Eric W. Biederman 提交于
      While testing the pid namespace code I hit this nasty warning.
      
      [  176.262617] ------------[ cut here ]------------
      [  176.263388] WARNING: at /home/eric/projects/linux/linux-userns-devel/kernel/softirq.c:160 local_bh_enable_ip+0x7a/0xa0()
      [  176.265145] Hardware name: Bochs
      [  176.265677] Modules linked in:
      [  176.266341] Pid: 742, comm: bash Not tainted 3.7.0userns+ #18
      [  176.266564] Call Trace:
      [  176.266564]  [<ffffffff810a539f>] warn_slowpath_common+0x7f/0xc0
      [  176.266564]  [<ffffffff810a53fa>] warn_slowpath_null+0x1a/0x20
      [  176.266564]  [<ffffffff810ad9ea>] local_bh_enable_ip+0x7a/0xa0
      [  176.266564]  [<ffffffff819308c9>] _raw_spin_unlock_bh+0x19/0x20
      [  176.266564]  [<ffffffff8123dbda>] proc_free_inum+0x3a/0x50
      [  176.266564]  [<ffffffff8111d0dc>] free_pid_ns+0x1c/0x80
      [  176.266564]  [<ffffffff8111d195>] put_pid_ns+0x35/0x50
      [  176.266564]  [<ffffffff810c608a>] put_pid+0x4a/0x60
      [  176.266564]  [<ffffffff8146b177>] tty_ioctl+0x717/0xc10
      [  176.266564]  [<ffffffff810aa4d5>] ? wait_consider_task+0x855/0xb90
      [  176.266564]  [<ffffffff81086bf9>] ? default_spin_lock_flags+0x9/0x10
      [  176.266564]  [<ffffffff810cab0a>] ? remove_wait_queue+0x5a/0x70
      [  176.266564]  [<ffffffff811e37e8>] do_vfs_ioctl+0x98/0x550
      [  176.266564]  [<ffffffff810b8a0f>] ? recalc_sigpending+0x1f/0x60
      [  176.266564]  [<ffffffff810b9127>] ? __set_task_blocked+0x37/0x80
      [  176.266564]  [<ffffffff810ab95b>] ? sys_wait4+0xab/0xf0
      [  176.266564]  [<ffffffff811e3d31>] sys_ioctl+0x91/0xb0
      [  176.266564]  [<ffffffff810a95f0>] ? task_stopped_code+0x50/0x50
      [  176.266564]  [<ffffffff81939199>] system_call_fastpath+0x16/0x1b
      [  176.266564] ---[ end trace 387af88219ad6143 ]---
      
      It turns out that spin_unlock_bh(proc_inum_lock) is not safe when
      put_pid is called with another spinlock held and irqs disabled.
      
      For now take the easy path and use spin_lock_irqsave(proc_inum_lock)
      in proc_free_inum and spin_loc_irq in proc_alloc_inum(proc_inum_lock).
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      dfb2ea45
  25. 21 12月, 2012 2 次提交
    • X
      proc: fix inconsistent lock state · ee297209
      Xiaotian Feng 提交于
      Lockdep found an inconsistent lock state when rcu is processing delayed
      work in softirq.  Currently, kernel is using spin_lock/spin_unlock to
      protect proc_inum_ida, but proc_free_inum is called by rcu in softirq
      context.
      
      Use spin_lock_bh/spin_unlock_bh fix following lockdep warning.
      
        =================================
        [ INFO: inconsistent lock state ]
        3.7.0 #36 Not tainted
        ---------------------------------
        inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
        swapper/1/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
         (proc_inum_lock){+.?...}, at: proc_free_inum+0x1c/0x50
        {SOFTIRQ-ON-W} state was registered at:
           __lock_acquire+0x8ae/0xca0
           lock_acquire+0x199/0x200
           _raw_spin_lock+0x41/0x50
           proc_alloc_inum+0x4c/0xd0
           alloc_mnt_ns+0x49/0xc0
           create_mnt_ns+0x25/0x70
           mnt_init+0x161/0x1c7
           vfs_caches_init+0x107/0x11a
           start_kernel+0x348/0x38c
           x86_64_start_reservations+0x131/0x136
           x86_64_start_kernel+0x103/0x112
        irq event stamp: 2993422
        hardirqs last  enabled at (2993422):  _raw_spin_unlock_irqrestore+0x55/0x80
        hardirqs last disabled at (2993421):  _raw_spin_lock_irqsave+0x29/0x70
        softirqs last  enabled at (2993394):  _local_bh_enable+0x13/0x20
        softirqs last disabled at (2993395):  call_softirq+0x1c/0x30
      
        other info that might help us debug this:
         Possible unsafe locking scenario:
      
               CPU0
               ----
          lock(proc_inum_lock);
          <Interrupt>
            lock(proc_inum_lock);
      
         *** DEADLOCK ***
      
        no locks held by swapper/1/0.
      
        stack backtrace:
        Pid: 0, comm: swapper/1 Not tainted 3.7.0 #36
        Call Trace:
         <IRQ>  [<ffffffff810a40f1>] ? vprintk_emit+0x471/0x510
          print_usage_bug+0x2a5/0x2c0
          mark_lock+0x33b/0x5e0
          __lock_acquire+0x813/0xca0
          lock_acquire+0x199/0x200
          _raw_spin_lock+0x41/0x50
          proc_free_inum+0x1c/0x50
          free_pid_ns+0x1c/0x50
          put_pid_ns+0x2e/0x50
          put_pid+0x4a/0x60
          delayed_put_pid+0x12/0x20
          rcu_process_callbacks+0x462/0x790
          __do_softirq+0x1b4/0x3b0
          call_softirq+0x1c/0x30
          do_softirq+0x59/0xd0
          irq_exit+0x54/0xd0
          smp_apic_timer_interrupt+0x95/0xa3
          apic_timer_interrupt+0x72/0x80
          cpuidle_enter_tk+0x10/0x20
          cpuidle_enter_state+0x17/0x50
          cpuidle_idle_call+0x287/0x520
          cpu_idle+0xba/0x130
          start_secondary+0x2b3/0x2bc
      Signed-off-by: NXiaotian Feng <dannyfeng@tencent.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ee297209
    • M
      procfs: drop vmtruncate · 46f69557
      Marco Stornelli 提交于
      Removed vmtruncate
      Signed-off-by: NMarco Stornelli <marco.stornelli@gmail.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      46f69557
  26. 20 11月, 2012 1 次提交