1. 04 9月, 2014 2 次提交
  2. 20 8月, 2014 1 次提交
  3. 16 7月, 2014 3 次提交
  4. 07 5月, 2014 5 次提交
  5. 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
  6. 02 4月, 2014 1 次提交
  7. 13 3月, 2014 1 次提交
    • T
      fs: push sync_filesystem() down to the file system's remount_fs() · 02b9984d
      Theodore Ts'o 提交于
      Previously, the no-op "mount -o mount /dev/xxx" operation when the
      file system is already mounted read-write causes an implied,
      unconditional syncfs().  This seems pretty stupid, and it's certainly
      documented or guaraunteed to do this, nor is it particularly useful,
      except in the case where the file system was mounted rw and is getting
      remounted read-only.
      
      However, it's possible that there might be some file systems that are
      actually depending on this behavior.  In most file systems, it's
      probably fine to only call sync_filesystem() when transitioning from
      read-write to read-only, and there are some file systems where this is
      not needed at all (for example, for a pseudo-filesystem or something
      like romfs).
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Artem Bityutskiy <dedekind1@gmail.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Evgeniy Dushistov <dushistov@mail.ru>
      Cc: Jan Kara <jack@suse.cz>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Anders Larsen <al@alarsen.net>
      Cc: Phillip Lougher <phillip@squashfs.org.uk>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Cc: Petr Vandrovec <petr@vandrovec.name>
      Cc: xfs@oss.sgi.com
      Cc: linux-btrfs@vger.kernel.org
      Cc: linux-cifs@vger.kernel.org
      Cc: samba-technical@lists.samba.org
      Cc: codalist@coda.cs.cmu.edu
      Cc: linux-ext4@vger.kernel.org
      Cc: linux-f2fs-devel@lists.sourceforge.net
      Cc: fuse-devel@lists.sourceforge.net
      Cc: cluster-devel@redhat.com
      Cc: linux-mtd@lists.infradead.org
      Cc: jfs-discussion@lists.sourceforge.net
      Cc: linux-nfs@vger.kernel.org
      Cc: linux-nilfs@vger.kernel.org
      Cc: linux-ntfs-dev@lists.sourceforge.net
      Cc: ocfs2-devel@oss.oracle.com
      Cc: reiserfs-devel@vger.kernel.org
      02b9984d
  8. 03 3月, 2014 2 次提交
  9. 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
  10. 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
  11. 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
  12. 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
  13. 13 9月, 2013 1 次提交
  14. 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
  15. 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
  16. 29 6月, 2013 2 次提交
  17. 08 5月, 2013 1 次提交
  18. 11 3月, 2013 1 次提交
  19. 26 2月, 2013 2 次提交
  20. 23 2月, 2013 1 次提交
  21. 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
  22. 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
  23. 21 1月, 2013 1 次提交
  24. 15 1月, 2013 1 次提交
  25. 13 12月, 2012 3 次提交