1. 09 12月, 2015 1 次提交
    • A
      don't put symlink bodies in pagecache into highmem · 21fc61c7
      Al Viro 提交于
      kmap() in page_follow_link_light() needed to go - allowing to hold
      an arbitrary number of kmaps for long is a great way to deadlocking
      the system.
      
      new helper (inode_nohighmem(inode)) needs to be used for pagecache
      symlinks inodes; done for all in-tree cases.  page_follow_link_light()
      instrumented to yell about anything missed.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      21fc61c7
  2. 07 12月, 2015 1 次提交
  3. 18 5月, 2015 3 次提交
  4. 16 4月, 2015 1 次提交
  5. 01 4月, 2015 1 次提交
  6. 14 3月, 2015 1 次提交
  7. 22 12月, 2014 1 次提交
  8. 19 12月, 2014 1 次提交
  9. 05 9月, 2014 4 次提交
  10. 20 8月, 2014 1 次提交
  11. 24 12月, 2013 1 次提交
    • J
      udf: Fix lockdep warning from udf_symlink() · 4ea7772f
      Jan Kara 提交于
      Lockdep is complaining about UDF:
      =============================================
      [ INFO: possible recursive locking detected ]
      3.12.0+ #16 Not tainted
      ---------------------------------------------
      ln/7386 is trying to acquire lock:
       (&ei->i_data_sem){+.+...}, at: [<ffffffff8142f06d>] udf_get_block+0x8d/0x130
      
      but task is already holding lock:
       (&ei->i_data_sem){+.+...}, at: [<ffffffff81431a8d>] udf_symlink+0x8d/0x690
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&ei->i_data_sem);
        lock(&ei->i_data_sem);
      
       *** DEADLOCK ***
      
      This is because we hold i_data_sem of the symlink inode while calling
      udf_add_entry() for the directory. I don't think this can ever lead to
      deadlocks since we never hold i_data_sem for two inodes in any other
      place.
      
      The fix is simple - move unlock of i_data_sem for symlink inode up. We
      don't need it for anything when linking symlink inode to directory.
      Reported-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NJan Kara <jack@suse.cz>
      4ea7772f
  12. 29 6月, 2013 1 次提交
  13. 26 2月, 2013 1 次提交
  14. 14 7月, 2012 2 次提交
  15. 13 7月, 2012 1 次提交
  16. 30 5月, 2012 1 次提交
  17. 11 5月, 2012 1 次提交
    • L
      vfs: make it possible to access the dentry hash/len as one 64-bit entry · 26fe5750
      Linus Torvalds 提交于
      This allows comparing hash and len in one operation on 64-bit
      architectures.  Right now only __d_lookup_rcu() takes advantage of this,
      since that is the case we care most about.
      
      The use of anonymous struct/unions hides the alternate 64-bit approach
      from most users, the exception being a few cases where we initialize a
      'struct qstr' with a static initializer.  This makes the problematic
      cases use a new QSTR_INIT() helper function for that (but initializing
      just the name pointer with a "{ .name = xyzzy }" initializer remains
      valid, as does just copying another qstr structure).
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26fe5750
  18. 21 3月, 2012 1 次提交
  19. 04 1月, 2012 3 次提交
  20. 02 11月, 2011 2 次提交
  21. 11 10月, 2011 1 次提交
  22. 28 5月, 2011 1 次提交
  23. 26 5月, 2011 2 次提交
  24. 14 3月, 2011 1 次提交
  25. 03 3月, 2011 1 次提交
  26. 07 1月, 2011 5 次提交
新手
引导
客服 返回
顶部