1. 09 6月, 2013 1 次提交
    • M
      hpfs: fix warnings when the filesystem fills up · bbd465df
      Mikulas Patocka 提交于
      This patch fixes warnings due to missing lock on write error path.
      
        WARNING: at fs/hpfs/hpfs_fn.h:353 hpfs_truncate+0x75/0x80 [hpfs]()
        Hardware name: empty
        Pid: 26563, comm: dd Tainted: P           O 3.9.4 #12
        Call Trace:
          hpfs_truncate+0x75/0x80 [hpfs]
          hpfs_write_begin+0x84/0x90 [hpfs]
          _hpfs_bmap+0x10/0x10 [hpfs]
          generic_file_buffered_write+0x121/0x2c0
          __generic_file_aio_write+0x1c7/0x3f0
          generic_file_aio_write+0x7c/0x100
          do_sync_write+0x98/0xd0
          hpfs_file_write+0xd/0x50 [hpfs]
          vfs_write+0xa2/0x160
          sys_write+0x51/0xa0
          page_fault+0x22/0x30
          system_call_fastpath+0x1a/0x1f
      Signed-off-by: NMikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Cc: stable@kernel.org  # 2.6.39+
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bbd465df
  2. 10 4月, 2013 1 次提交
  3. 23 2月, 2013 1 次提交
  4. 21 12月, 2012 1 次提交
  5. 21 7月, 2011 1 次提交
    • J
      fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers · 02c24a82
      Josef Bacik 提交于
      Btrfs needs to be able to control how filemap_write_and_wait_range() is called
      in fsync to make it less of a painful operation, so push down taking i_mutex and
      the calling of filemap_write_and_wait() down into the ->fsync() handlers.  Some
      file systems can drop taking the i_mutex altogether it seems, like ext3 and
      ocfs2.  For correctness sake I just pushed everything down in all cases to make
      sure that we keep the current behavior the same for everybody, and then each
      individual fs maintainer can make up their mind about what to do from there.
      Thanks,
      Acked-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJosef Bacik <josef@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      02c24a82
  6. 10 5月, 2011 2 次提交
  7. 10 3月, 2011 1 次提交
  8. 03 3月, 2011 1 次提交
    • A
      hpfs: remove the BKL · 9a311b96
      Arnd Bergmann 提交于
      This removes the BKL in hpfs in a rather awful
      way, by making the code only work on uniprocessor
      systems without kernel preemption, as suggested
      by Andi Kleen.
      
      The HPFS code probably has close to zero remaining
      users on current kernels, all archeological uses of
      the file system can probably be done with the significant
      restrictions.
      
      The hpfs_lock/hpfs_unlock functions are left in the
      code, sincen Mikulas has indicated that he is still
      interested in fixing it in a better way.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NAndi Kleen <ak@linux.intel.com>
      Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Cc: linux-fsdevel@vger.kernel.org
      9a311b96
  9. 10 8月, 2010 1 次提交
  10. 28 5月, 2010 1 次提交
  11. 13 7月, 2009 1 次提交
  12. 23 10月, 2008 1 次提交
  13. 17 10月, 2007 1 次提交
  14. 10 7月, 2007 1 次提交
  15. 13 2月, 2007 1 次提交
  16. 09 12月, 2006 1 次提交
  17. 01 10月, 2006 1 次提交
  18. 29 6月, 2006 1 次提交
  19. 29 3月, 2006 1 次提交
  20. 09 11月, 2005 1 次提交
  21. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4