1. 08 Jan, 2015 1 commit
  2. 09 Oct, 2014 1 commit
    • Jan Kara's avatar
      udf: Avoid infinite loop when processing indirect ICBs · 07d209bd
      Jan Kara authored
      commit c03aa9f6e1f938618e6db2e23afef0574efeeb65 upstream.
      
      We did not implement any bound on number of indirect ICBs we follow when
      loading inode. Thus corrupted medium could cause kernel to go into an
      infinite loop, possibly causing a stack overflow.
      
      Fix the possible stack overflow by removing recursion from
      __udf_read_inode() and limit number of indirect ICBs we follow to avoid
      infinite loops.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Cc: Chuck Ebbert <cebbert.lkml@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07d209bd
  3. 01 Oct, 2013 2 commits
    • Jan Kara's avatar
      udf: Refuse RW mount of the filesystem instead of making it RO · 39b79aa3
      Jan Kara authored
      commit e729eac6f65e11c5f03b09adcc84bd5bcb230467 upstream.
      
      Refuse RW mount of udf filesystem. So far we just silently changed it
      to RO mount but when the media is writeable, block layer won't notice
      this change and thus will think device is used RW and will block eject
      button of the drive. That is unexpected by users because for
      non-writeable media eject button works just fine.
      
      Userspace mount(8) command handles this just fine and retries mounting
      with MS_RDONLY set so userspace shouldn't see any regression.  Plus any
      tool mounting udf is likely confronted with the case of read-only
      media where block layer already refuses to mount the filesystem without
      MS_RDONLY set so our behavior shouldn't be anything new for it.
      Reported-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      39b79aa3
    • Jan Kara's avatar
      udf: Standardize return values in mount sequence · 66ccf961
      Jan Kara authored
      commit d759bfa4e7919b89357de50a2e23817079889195 upstream.
      
      Change all function used in filesystem discovery during mount to user
      standard kernel return values - -errno on error, 0 on success instead
      of 1 on failure and 0 on success. This allows us to pass error number
      (not just failure / success) so we can abort device scanning earlier
      in case of errors like EIO or ENOMEM . Also we will be able to return
      EROFS in case writeable mount is requested but writing isn't supported.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Cc: Hui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      66ccf961
  4. 08 May, 2013 1 commit
  5. 11 Mar, 2013 1 commit
  6. 26 Feb, 2013 2 commits
  7. 23 Feb, 2013 1 commit
  8. 05 Feb, 2013 3 commits
    • Jan Kara's avatar
      udf: Remove unused s_extLength from udf_bitmap · 288be96d
      Jan Kara authored
      s_extLength was assigned to but the value was never really used. So
      just remove the field.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      288be96d
    • Jan Kara's avatar
      udf: Make s_block_bitmap standard array · c60305b5
      Jan Kara authored
      struct udf_bitmap has array of buffer pointers attached to it. The code
      unnecessarily used s_block_bitmap as a pointer to the array instead of
      the standard trick of using 0 length array in the declaration. Change
      that to make code more readable and actually shrink the structure by one
      pointer.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      c60305b5
    • Jan Kara's avatar
      udf: Fix bitmap overflow on large filesystems with small block size · 89b1f39e
      Jan Kara authored
      For large UDF filesystems with 512-byte blocks the number of necessary
      bitmap blocks is larger than 2^16 so s_nr_groups in udf_bitmap overflows
      (the number will overflow for filesystems larger than 128 GB with
      512-byte blocks). That results in ENOSPC errors despite the filesystem
      has plenty of free space.
      
      Fix the problem by changing s_nr_groups' type to 'int'. That is enough
      even for filesystems 2^32 blocks (UDF maximum) and 512-byte blocksize.
      
      Reported-and-tested-by: v10lator@myway.de
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      89b1f39e
  9. 22 Jan, 2013 1 commit
    • Namjae Jeon's avatar
      udf: add extent cache support in case of file reading · 99600051
      Namjae Jeon authored
      This patch implements extent caching in case of file reading.
      While reading a file, currently, UDF reads metadata serially
      which takes a lot of time depending on the number of extents present
      in the file. Caching last accessd extent improves metadata read time.
      Instead of reading file metadata from start, now we read from
      the cached extent.
      
      This patch considerably improves the time spent by CPU in kernel mode.
      For example, while reading a 10.9 GB file using dd:
      Time before applying patch:
      11677022208 bytes (10.9GB) copied, 1529.748921 seconds, 7.3MB/s
      real    25m 29.85s
      user    0m 12.41s
      sys     15m 34.75s
      
      Time after applying patch:
      11677022208 bytes (10.9GB) copied, 1469.338231 seconds, 7.6MB/s
      real    24m 29.44s
      user    0m 15.73s
      sys     3m 27.61s
      
      [JK: Fix bh refcounting issues, simplify initialization]
      Signed-off-by: default avatarNamjae Jeon <namjae.jeon@samsung.com>
      Signed-off-by: default avatarAshish Sangwan <a.sangwan@samsung.com>
      Signed-off-by: default avatarBonggil Bak <bgbak@samsung.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      99600051
  10. 21 Jan, 2013 1 commit
  11. 14 Jan, 2013 1 commit
  12. 13 Dec, 2012 3 commits
  13. 03 Oct, 2012 1 commit
  14. 21 Sep, 2012 1 commit
  15. 06 Sep, 2012 1 commit
    • Ian Abbott's avatar
      UDF: Add support for O_DIRECT · 5eec54fc
      Ian Abbott authored
      Add support for the O_DIRECT flag.  There are two cases to deal with:
      
      1. Small files stored in the ICB (inode control block?): just return 0
      from the new udf_adinicb_direct_IO() handler to fall back to buffered
      I/O.
      
      2. Larger files, not stored in the ICB: nothing special here.  Just call
      blockdev_direct_IO() from our new udf_direct_IO() handler and tidy up
      any blocks instantiated outside i_size on error.  This is pretty
      standard.  Factor error handling code out of udf_write_begin() into new
      function udf_write_failed() so it can also be called by udf_direct_IO().
      
      Also change the whitespace in udf_aops to make it a bit neater.
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      5eec54fc
  16. 05 Sep, 2012 1 commit
    • Jan Kara's avatar
      udf: Fix data corruption for files in ICB · 9c2fc0de
      Jan Kara authored
      When a file is stored in ICB (inode), we overwrite part of the file, and
      the page containing file's data is not in page cache, we end up corrupting
      file's data by overwriting them with zeros. The problem is we use
      simple_write_begin() which simply zeroes parts of the page which are not
      written to. The problem has been introduced by be021ee4 (udf: convert to
      new aops).
      
      Fix the problem by providing a ->write_begin function which makes the page
      properly uptodate.
      
      CC: <stable@vger.kernel.org> # >= 2.6.24
      Reported-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      9c2fc0de
  17. 03 Sep, 2012 1 commit
    • Namjae Jeon's avatar
      udf: add writepages support for udf · 378b8e1a
      Namjae Jeon authored
      Use mpage_writepages() instead of multiple calls to udf_writepage()
      to make performance higher.
      
      *Write Speed with writepage() =
       RecSize     ReadSpeed    WriteSpeed  RanReadSpeed RanWriteSpeed
      10485760    0.00MB/sec    8.56MB/sec    0.00MB/sec    8.20MB/sec
       1048576    0.00MB/sec    8.57MB/sec    0.00MB/sec    6.42MB/sec
        524288    0.00MB/sec    8.59MB/sec    0.00MB/sec    5.24MB/sec
        262144    0.00MB/sec    8.59MB/sec    0.00MB/sec    4.17MB/sec
        131072    0.00MB/sec    8.53MB/sec    0.00MB/sec    3.32MB/sec
         65536    0.00MB/sec    8.49MB/sec    0.00MB/sec    2.31MB/sec
      
      *Write Speed with writepages()
      RecSize     ReadSpeed    WriteSpeed  RanReadSpeed RanWriteSpeed
      10485760    0.00MB/sec    9.88MB/sec    0.00MB/sec    9.60MB/sec
       1048576    0.00MB/sec    9.95MB/sec    0.00MB/sec    7.52MB/sec
        524288    0.00MB/sec    9.98MB/sec    0.00MB/sec    6.16MB/sec
        262144    0.00MB/sec    9.90MB/sec    0.00MB/sec    4.98MB/sec
        131072    0.00MB/sec    9.89MB/sec    0.00MB/sec    3.78MB/sec
         65536    0.00MB/sec    9.81MB/sec    0.00MB/sec    2.50MB/sec
      
      There is about 1.4MB/sec speed improvement over 8.5MB/sec,
      which comes out around 16% improvement.
      Signed-off-by: default avatarNamjae Jeon <linkinjeon@gmail.com>
      Signed-off-by: default avatarAshish Sangwan <ashish.sangwan2@gmail.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      378b8e1a
  18. 15 Aug, 2012 1 commit
  19. 14 Aug, 2012 2 commits
  20. 14 Jul, 2012 2 commits
  21. 13 Jul, 2012 1 commit
  22. 10 Jul, 2012 1 commit
  23. 09 Jul, 2012 4 commits
  24. 28 Jun, 2012 3 commits
  25. 30 May, 2012 1 commit
  26. 11 May, 2012 1 commit
    • Linus Torvalds's avatar
      vfs: make it possible to access the dentry hash/len as one 64-bit entry · 26fe5750
      Linus Torvalds authored
      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: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      26fe5750
  27. 06 May, 2012 1 commit