1. 12 6月, 2009 2 次提交
  2. 23 5月, 2009 1 次提交
  3. 02 4月, 2009 16 次提交
  4. 26 3月, 2009 1 次提交
  5. 22 1月, 2009 1 次提交
  6. 28 11月, 2008 1 次提交
    • J
      udf: Fix BUG_ON() in destroy_inode() · 52b19ac9
      Jan Kara 提交于
      udf_clear_inode() can leave behind buffers on mapping's i_private list (when
      we truncated preallocation). Call invalidate_inode_buffers() so that the list
      is properly cleaned-up before we return from udf_clear_inode(). This is ugly
      and suggest that we should cleanup preallocation earlier than in clear_inode()
      but currently there's no such call available since drop_inode() is called under
      inode lock and thus is unusable for disk operations.
      Signed-off-by: NJan Kara <jack@suse.cz>
      52b19ac9
  7. 14 11月, 2008 1 次提交
  8. 23 10月, 2008 2 次提交
  9. 14 10月, 2008 1 次提交
  10. 09 9月, 2008 1 次提交
  11. 19 8月, 2008 2 次提交
    • J
      udf: Fix error paths in udf_new_inode() · 97e1cfb0
      Jan Kara 提交于
      I case we failed to allocate memory for inode when creating it, we did not
      properly free block already allocated for this inode. Move memory allocation
      before the block allocation which fixes this issue (thanks for the idea go to
      Ingo Oeser <ioe-lkml@rameria.de>). Also remove a few superfluous
      initializations already done in udf_alloc_inode().
      Reviewed-by: NIngo Oeser <ioe-lkml@rameria.de>
      Signed-off-by: NJan Kara <jack@suse.cz>
      97e1cfb0
    • J
      udf: Fix lock inversion between iprune_mutex and alloc_mutex (v2) · db0badc5
      Jan Kara 提交于
      A memory allocation inside alloc_mutex must not recurse back into the
      filesystem itself because that leads to lock inversion between iprune_mutex and
      alloc_mutex (and thus to deadlocks - see traces below). alloc_mutex is actually
      needed only to update allocation statistics in the superblock so we can drop it
      before we start allocating memory for the inode.
      
      tar           D ffff81015b9c8c90     0  6614   6612
       ffff8100d5a21a20 0000000000000086 0000000000000000 00000000ffff0000
       ffff81015b9c8c90 ffff81015b8f0cd0 ffff81015b9c8ee0 0000000000000000
       0000000000000003 0000000000000000 0000000000000000 0000000000000000
      Call Trace:
       [<ffffffff803c1d8a>] __mutex_lock_slowpath+0x64/0x9b
       [<ffffffff803c1bef>] mutex_lock+0xa/0xb
       [<ffffffff8027f8c2>] shrink_icache_memory+0x38/0x200
       [<ffffffff80257742>] shrink_slab+0xe3/0x15b
       [<ffffffff802579db>] try_to_free_pages+0x221/0x30d
       [<ffffffff8025657e>] isolate_pages_global+0x0/0x31
       [<ffffffff8025324b>] __alloc_pages_internal+0x252/0x3ab
       [<ffffffff8026b08b>] cache_alloc_refill+0x22e/0x47b
       [<ffffffff8026ae37>] kmem_cache_alloc+0x3b/0x61
       [<ffffffff8026b15b>] cache_alloc_refill+0x2fe/0x47b
       [<ffffffff8026b34e>] __kmalloc+0x76/0x9c
       [<ffffffffa00751f2>] :udf:udf_new_inode+0x202/0x2e2
       [<ffffffffa007ae5e>] :udf:udf_create+0x2f/0x16d
       [<ffffffffa0078f27>] :udf:udf_lookup+0xa6/0xad
      ...
      kswapd0       D ffff81015b9d9270     0   125      2
       ffff81015b903c28 0000000000000046 ffffffff8028cbb0 00000000fffffffb
       ffff81015b9d9270 ffff81015b8f0cd0 ffff81015b9d94c0 000000000271b490
       ffffe2000271b458 ffffe2000271b420 ffffe20002728dc8 ffffe20002728d90
      Call Trace:
       [<ffffffff8028cbb0>] __set_page_dirty+0xeb/0xf5
       [<ffffffff8025403a>] get_dirty_limits+0x1d/0x22f
       [<ffffffff803c1d8a>] __mutex_lock_slowpath+0x64/0x9b
       [<ffffffff803c1bef>] mutex_lock+0xa/0xb
       [<ffffffffa0073f58>] :udf:udf_bitmap_free_blocks+0x47/0x1eb
       [<ffffffffa007df31>] :udf:udf_discard_prealloc+0xc6/0x172
       [<ffffffffa007875a>] :udf:udf_clear_inode+0x1e/0x48
       [<ffffffff8027f121>] clear_inode+0x6d/0xc4
       [<ffffffff8027f7f2>] dispose_list+0x56/0xee
       [<ffffffff8027fa5a>] shrink_icache_memory+0x1d0/0x200
       [<ffffffff80257742>] shrink_slab+0xe3/0x15b
       [<ffffffff80257e93>] kswapd+0x346/0x447
      ...
      Reported-by: NTibor Tajti <tibor.tajti@gmail.com>
      Reviewed-by: NIngo Oeser <ioe-lkml@rameria.de>
      Signed-off-by: NJan Kara <jack@suse.cz>
      db0badc5
  12. 27 7月, 2008 1 次提交
  13. 24 6月, 2008 1 次提交
  14. 16 6月, 2008 1 次提交
  15. 07 5月, 2008 2 次提交
  16. 30 4月, 2008 1 次提交
  17. 29 4月, 2008 1 次提交
    • A
      udf: fs/udf/partition.c:udf_get_pblock() mustn't be inline · 22ba0317
      Adrian Bunk 提交于
      This patch fixes the following build error with UML and gcc 4.3:
      
      <--  snip  -->
      
      ...
        CC      fs/udf/partition.o
      /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/partition.c: In function ‘udf_get_pblock_virt15’:
      /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/partition.c:32: sorry, unimplemented: inlining failed in call to ‘udf_get_pblock’: function body not available
      /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/partition.c:102: sorry, unimplemented: called from here
      make[3]: *** [fs/udf/partition.o] Error 1
      
      <--  snip  -->
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NJan Kara <jack@suse.cz>
      22ba0317
  18. 28 4月, 2008 1 次提交
  19. 17 4月, 2008 3 次提交