1. 04 4月, 2014 1 次提交
    • J
      mm + fs: store shadow entries in page cache · 91b0abe3
      Johannes Weiner 提交于
      Reclaim will be leaving shadow entries in the page cache radix tree upon
      evicting the real page.  As those pages are found from the LRU, an
      iput() can lead to the inode being freed concurrently.  At this point,
      reclaim must no longer install shadow pages because the inode freeing
      code needs to ensure the page tree is really empty.
      
      Add an address_space flag, AS_EXITING, that the inode freeing code sets
      under the tree lock before doing the final truncate.  Reclaim will check
      for this flag before installing shadow pages.
      Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
      Reviewed-by: NRik van Riel <riel@redhat.com>
      Reviewed-by: NMinchan Kim <minchan@kernel.org>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Bob Liu <bob.liu@oracle.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Luigi Semenzato <semenzato@google.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Metin Doslu <metin@citusdata.com>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Ozgun Erdogan <ozgun@citusdata.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Roman Gushchin <klamm@yandex-team.ru>
      Cc: Ryan Mallon <rmallon@gmail.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      91b0abe3
  2. 21 2月, 2014 1 次提交
    • J
      udf: Fix data corruption on file type conversion · 09ebb17a
      Jan Kara 提交于
      UDF has two types of files - files with data stored in inode (ICB in
      UDF terminology) and files with data stored in external data blocks. We
      convert file from in-inode format to external format in
      udf_file_aio_write() when we find out data won't fit into inode any
      longer. However the following race between two O_APPEND writes can happen:
      
      CPU1					CPU2
      udf_file_aio_write()			udf_file_aio_write()
        down_write(&iinfo->i_data_sem);
        checks that i_size + count1 fits within inode
          => no need to convert
        up_write(&iinfo->i_data_sem);
      					  down_write(&iinfo->i_data_sem);
      					  checks that i_size + count2 fits
      					    within inode => no need to convert
      					  up_write(&iinfo->i_data_sem);
        generic_file_aio_write()
          - extends file by count1 bytes
      					  generic_file_aio_write()
      					    - extends file by count2 bytes
      
      Clearly if count1 + count2 doesn't fit into the inode, we overwrite
      kernel buffers beyond inode, possibly corrupting the filesystem as well.
      
      Fix the problem by acquiring i_mutex before checking whether write fits
      into the inode and using __generic_file_aio_write() afterwards which
      puts check and write into one critical section.
      Reported-by: NAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: NJan Kara <jack@suse.cz>
      09ebb17a
  3. 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
  4. 19 10月, 2013 1 次提交
    • P
      udf: fix for pathetic mount times in case of invalid file system · 44499602
      Peter A. Felvegi 提交于
      The UDF driver was not strict enough about checking the IDs in the
      VSDs when mounting, which resulted in reading through all the sectors
      of the block device in some unfortunate cases. Eg, trying to mount my
      uninitialized 200G SSD partition (all 0xFF bytes) took ~350 minutes to
      fail, because the code expected some of the valid IDs or a zero byte.
      During this, the mount couldn't be killed, sync from the cmdline
      blocked, and the machine froze into the shutdown. Valid filesystems
      (extX, btrfs, ntfs) were rejected by the mere accident of having a
      zero byte at just the right place in some of their sectors, close
      enough to the beginning not to generate excess I/O. The fix adds a
      hard limit on the VSD sector offset, adds the two missing VSD IDs, and
      stops scanning when encountering an invalid ID. Also replaced the
      magic number 32768 with a more meaningful #define, and supressed the
      bogus message about failing to read the first sector if no UDF fs was
      detected.
      Signed-off-by: NPeter A. Felvegi <petschy@gmail.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      44499602
  5. 24 9月, 2013 1 次提交
    • J
      udf: Fortify LVID loading · 69d75671
      Jan Kara 提交于
      A user has reported an oops in udf_statfs() that was caused by
      numOfPartitions entry in LVID structure being corrupted. Fix the problem
      by verifying whether numOfPartitions makes sense at least to the extent
      that LVID fits into a single block as it should.
      Reported-by: NJuergen Weigert <jw@suse.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      69d75671
  6. 13 9月, 2013 1 次提交
  7. 01 8月, 2013 2 次提交
    • J
      udf: Refuse RW mount of the filesystem instead of making it RO · e729eac6
      Jan Kara 提交于
      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: NHui Wang <hui.wang@canonical.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      e729eac6
    • J
      udf: Standardize return values in mount sequence · d759bfa4
      Jan Kara 提交于
      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: NJan Kara <jack@suse.cz>
      d759bfa4
  8. 30 7月, 2013 1 次提交
    • K
      aio: Kill aio_rw_vect_retry() · 73a7075e
      Kent Overstreet 提交于
      This code doesn't serve any purpose anymore, since the aio retry
      infrastructure has been removed.
      
      This change should be safe because aio_read/write are also used for
      synchronous IO, and called from do_sync_read()/do_sync_write() - and
      there's no looping done in the sync case (the read and write syscalls).
      Signed-off-by: NKent Overstreet <koverstreet@google.com>
      Cc: Zach Brown <zab@redhat.com>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Mark Fasheh <mfasheh@suse.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Asai Thambi S P <asamymuthupa@micron.com>
      Cc: Selvan Mani <smani@micron.com>
      Cc: Sam Bradshaw <sbradshaw@micron.com>
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Benjamin LaHaise <bcrl@kvack.org>
      Signed-off-by: NBenjamin LaHaise <bcrl@kvack.org>
      73a7075e
  9. 29 6月, 2013 2 次提交
  10. 08 5月, 2013 1 次提交
  11. 11 3月, 2013 1 次提交
  12. 26 2月, 2013 2 次提交
  13. 23 2月, 2013 1 次提交
  14. 06 2月, 2013 3 次提交
    • J
      udf: Remove unused s_extLength from udf_bitmap · 288be96d
      Jan Kara 提交于
      s_extLength was assigned to but the value was never really used. So
      just remove the field.
      Signed-off-by: NJan Kara <jack@suse.cz>
      288be96d
    • J
      udf: Make s_block_bitmap standard array · c60305b5
      Jan Kara 提交于
      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: NJan Kara <jack@suse.cz>
      c60305b5
    • J
      udf: Fix bitmap overflow on large filesystems with small block size · 89b1f39e
      Jan Kara 提交于
      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: NJan Kara <jack@suse.cz>
      89b1f39e
  15. 22 1月, 2013 1 次提交
    • N
      udf: add extent cache support in case of file reading · 99600051
      Namjae Jeon 提交于
      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: NNamjae Jeon <namjae.jeon@samsung.com>
      Signed-off-by: NAshish Sangwan <a.sangwan@samsung.com>
      Signed-off-by: NBonggil Bak <bgbak@samsung.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      99600051
  16. 21 1月, 2013 1 次提交
  17. 15 1月, 2013 1 次提交
  18. 13 12月, 2012 3 次提交
  19. 03 10月, 2012 1 次提交
  20. 21 9月, 2012 1 次提交
  21. 06 9月, 2012 1 次提交
    • I
      UDF: Add support for O_DIRECT · 5eec54fc
      Ian Abbott 提交于
      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: NIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: NJan Kara <jack@suse.cz>
      5eec54fc
  22. 05 9月, 2012 1 次提交
    • J
      udf: Fix data corruption for files in ICB · 9c2fc0de
      Jan Kara 提交于
      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: NIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: NJan Kara <jack@suse.cz>
      9c2fc0de
  23. 04 9月, 2012 1 次提交
    • N
      udf: add writepages support for udf · 378b8e1a
      Namjae Jeon 提交于
      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: NNamjae Jeon <linkinjeon@gmail.com>
      Signed-off-by: NAshish Sangwan <ashish.sangwan2@gmail.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      378b8e1a
  24. 15 8月, 2012 3 次提交
  25. 14 7月, 2012 2 次提交
  26. 13 7月, 2012 1 次提交
  27. 11 7月, 2012 1 次提交
  28. 09 7月, 2012 3 次提交