1. 11 4月, 2016 1 次提交
  2. 09 2月, 2016 3 次提交
    • J
      udf: Use separate buffer for copying split names · 066b9cde
      Jan Kara 提交于
      Code in udf_find_entry() and udf_readdir() used the same buffer for
      storing filename that was split among blocks and for the resulting
      filename in utf8. This worked because udf_get_filename() first
      internally copied the name into a different buffer and only then
      performed a conversion into the destination buffer. However we want to
      get rid of intermediate buffers so use separate buffer for converted
      name and name split between blocks so that we don't have the same source
      and destination buffer when converting split names.
      Signed-off-by: NJan Kara <jack@suse.cz>
      066b9cde
    • A
      udf: Adjust UDF_NAME_LEN to better reflect actual restrictions · 9fba7056
      Andrew Gabbasov 提交于
      Actual name length restriction is 254 bytes, this is used in 'ustr'
      structure, and this is what fits into UDF File Ident structures.
      And in most cases the constant is used as UDF_NAME_LEN-2.
      So, it's better to just modify the constant to make it closer
      to reality.
      
      Also, in some cases it's useful to have a separate constant for
      the maximum length of file name field in CS0 encoding in UDF File
      Ident structures.
      
      Also, remove the unused UDF_PATH_LEN constant.
      Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      9fba7056
    • A
      udf: Parameterize output length in udf_put_filename · 525e2c56
      Andrew Gabbasov 提交于
      Make the desired output length a parameter rather than have it
      hard-coded to UDF_NAME_LEN. Although all call sites still have
      this length the same, this parameterization will make the function
      more universal and also consistent with udf_get_filename.
      Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      525e2c56
  3. 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
  4. 07 12月, 2015 1 次提交
  5. 18 5月, 2015 3 次提交
  6. 16 4月, 2015 1 次提交
  7. 01 4月, 2015 1 次提交
  8. 14 3月, 2015 1 次提交
  9. 22 12月, 2014 1 次提交
  10. 19 12月, 2014 1 次提交
  11. 05 9月, 2014 4 次提交
  12. 20 8月, 2014 1 次提交
  13. 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
  14. 29 6月, 2013 1 次提交
  15. 26 2月, 2013 1 次提交
  16. 14 7月, 2012 2 次提交
  17. 13 7月, 2012 1 次提交
  18. 30 5月, 2012 1 次提交
  19. 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
  20. 21 3月, 2012 1 次提交
  21. 04 1月, 2012 3 次提交
  22. 02 11月, 2011 2 次提交
  23. 11 10月, 2011 1 次提交
  24. 28 5月, 2011 1 次提交
  25. 26 5月, 2011 2 次提交
  26. 14 3月, 2011 1 次提交
  27. 03 3月, 2011 1 次提交
  28. 07 1月, 2011 1 次提交
    • J
      UDF: Close small mem leak in udf_find_entry() · a4264b3f
      Jesper Juhl 提交于
      Hi,
      
      There's a small memory leak in fs/udf/namei.c::udf_find_entry().
      
      We dynamically allocate memory for 'fname' with kmalloc() and in most
      situations we free it before we leave the function, but there is one
      situation where we do not (but should). This patch closes the leak by
      jumping to the 'out_ok' label which does the correct cleanup rather than
      doing half the cleanup and returning directly.
      Signed-off-by: NJesper Juhl <jj@chaosbits.net>
      Signed-off-by: NJan Kara <jack@suse.cz>
      a4264b3f