1. 20 Nov, 2013 6 commits
    • Phillip Lougher's avatar
      Squashfs: Directly decompress into the page cache for file data · 0d455c12
      Phillip Lougher authored
      This introduces an implementation of squashfs_readpage_block()
      that directly decompresses into the page cache.
      
      This uses the previously added page handler abstraction to push
      down the necessary kmap_atomic/kunmap_atomic operations on the
      page cache buffers into the decompressors.  This enables
      direct copying into the page cache without using the slow
      kmap/kunmap calls.
      
      The code detects when multiple threads are racing in
      squashfs_readpage() to decompress the same block, and avoids
      this regression by falling back to using an intermediate
      buffer.
      
      This patch enhances the performance of Squashfs significantly
      when multiple processes are accessing the filesystem simultaneously
      because it not only reduces memcopying, but it more importantly
      eliminates the lock contention on the intermediate buffer.
      
      Using single-thread decompression.
      
              dd if=file1 of=/dev/null bs=4096 &
              dd if=file2 of=/dev/null bs=4096 &
              dd if=file3 of=/dev/null bs=4096 &
              dd if=file4 of=/dev/null bs=4096
      
      Before:
      
      629145600 bytes (629 MB) copied, 45.8046 s, 13.7 MB/s
      
      After:
      
      629145600 bytes (629 MB) copied, 9.29414 s, 67.7 MB/s
      Signed-off-by: 's avatarPhillip Lougher <phillip@squashfs.org.uk>
      Reviewed-by: 's avatarMinchan Kim <minchan@kernel.org>
      0d455c12
    • Phillip Lougher's avatar
      Squashfs: Restructure squashfs_readpage() · 5f55dbc0
      Phillip Lougher authored
      Restructure squashfs_readpage() splitting it into separate
      functions for datablocks, fragments and sparse blocks.
      
      Move the memcpying (from squashfs cache entry) implementation of
      squashfs_readpage_block into file_cache.c
      
      This allows different implementations to be supported.
      Signed-off-by: 's avatarPhillip Lougher <phillip@squashfs.org.uk>
      Reviewed-by: 's avatarMinchan Kim <minchan@kernel.org>
      5f55dbc0
    • Phillip Lougher's avatar
      Squashfs: Generalise paging handling in the decompressors · 846b730e
      Phillip Lougher authored
      Further generalise the decompressors by adding a page handler
      abstraction.  This adds helpers to allow the decompressors
      to access and process the output buffers in an implementation
      independant manner.
      
      This allows different types of output buffer to be passed
      to the decompressors, with the implementation specific
      aspects handled at decompression time, but without the
      knowledge being held in the decompressor wrapper code.
      
      This will allow the decompressors to handle Squashfs
      cache buffers, and page cache pages.
      
      This patch adds the abstraction and an implementation for
      the caches.
      Signed-off-by: 's avatarPhillip Lougher <phillip@squashfs.org.uk>
      Reviewed-by: 's avatarMinchan Kim <minchan@kernel.org>
      846b730e
    • Phillip Lougher's avatar
      Squashfs: add multi-threaded decompression using percpu variable · d208383d
      Phillip Lougher authored
      Add a multi-threaded decompression implementation which uses
      percpu variables.
      
      Using percpu variables has advantages and disadvantages over
      implementations which do not use percpu variables.
      
      Advantages:
        * the nature of percpu variables ensures decompression is
          load-balanced across the multiple cores.
        * simplicity.
      
      Disadvantages: it limits decompression to one thread per core.
      Signed-off-by: 's avatarPhillip Lougher <phillip@squashfs.org.uk>
      d208383d
    • Minchan Kim's avatar
      squashfs: Enhance parallel I/O · cd59c2ec
      Minchan Kim authored
      Now squashfs have used for only one stream buffer for decompression
      so it hurts parallel read performance so this patch supports
      multiple decompressor to enhance performance parallel I/O.
      
      Four 1G file dd read on KVM machine which has 2 CPU and 4G memory.
      
      dd if=test/test1.dat of=/dev/null &
      dd if=test/test2.dat of=/dev/null &
      dd if=test/test3.dat of=/dev/null &
      dd if=test/test4.dat of=/dev/null &
      
      old : 1m39s -> new : 9s
      
      * From v1
        * Change comp_strm with decomp_strm - Phillip
        * Change/add comments - Phillip
      Signed-off-by: 's avatarMinchan Kim <minchan@kernel.org>
      Signed-off-by: 's avatarPhillip Lougher <phillip@squashfs.org.uk>
      cd59c2ec
    • Phillip Lougher's avatar
      Squashfs: Refactor decompressor interface and code · 9508c6b9
      Phillip Lougher authored
      The decompressor interface and code was written from
      the point of view of single-threaded operation.  In doing
      so it mixed a lot of single-threaded implementation specific
      aspects into the decompressor code and elsewhere which makes it
      difficult to seamlessly support multiple different decompressor
      implementations.
      
      This patch does the following:
      
      1.  It removes compressor_options parsing from the decompressor
          init() function.  This allows the decompressor init() function
          to be dynamically called to instantiate multiple decompressors,
          without the compressor options needing to be read and parsed each
          time.
      
      2.  It moves threading and all sleeping operations out of the
          decompressors.  In doing so, it makes the decompressors
          non-blocking wrappers which only deal with interfacing with
          the decompressor implementation.
      
      3. It splits decompressor.[ch] into decompressor generic functions
         in decompressor.[ch], and moves the single threaded
         decompressor implementation into decompressor_single.c.
      
      The result of this patch is Squashfs should now be able to
      support multiple decompressors by adding new decompressor_xxx.c
      files with specialised implementations of the functions in
      decompressor_single.c
      Signed-off-by: 's avatarPhillip Lougher <phillip@squashfs.org.uk>
      Reviewed-by: 's avatarMinchan Kim <minchan@kernel.org>
      9508c6b9
  2. 25 Oct, 2013 1 commit
    • Gu Zheng's avatar
      seq_file: always update file->f_pos in seq_lseek() · 05e16745
      Gu Zheng authored
      This issue was first pointed out by Jiaxing Wang several months ago, but no
      further comments:
      https://lkml.org/lkml/2013/6/29/41
      
      As we know pread() does not change f_pos, so after pread(), file->f_pos
      and m->read_pos become different. And seq_lseek() does not update file->f_pos
      if offset equals to m->read_pos, so after pread() and seq_lseek()(lseek to
      m->read_pos), then a subsequent read may read from a wrong position, the
      following program produces the problem:
      
          char str1[32] = { 0 };
          char str2[32] = { 0 };
          int poffset = 10;
          int count = 20;
      
          /*open any seq file*/
          int fd = open("/proc/modules", O_RDONLY);
      
          pread(fd, str1, count, poffset);
          printf("pread:%s\n", str1);
      
          /*seek to where m->read_pos is*/
          lseek(fd, poffset+count, SEEK_SET);
      
          /*supposed to read from poffset+count, but this read from position 0*/
          read(fd, str2, count);
          printf("read:%s\n", str2);
      
      out put:
      pread:
       ck_netbios_ns 12665
      read:
       nf_conntrack_netbios
      
      /proc/modules:
      nf_conntrack_netbios_ns 12665 0 - Live 0xffffffffa038b000
      nf_conntrack_broadcast 12589 1 nf_conntrack_netbios_ns, Live 0xffffffffa0386000
      
      So we always update file->f_pos to offset in seq_lseek() to fix this issue.
      Signed-off-by: 's avatarJiaxing Wang <hello.wjx@gmail.com>
      Signed-off-by: 's avatarGu Zheng <guz.fnst@cn.fujitsu.com>
      Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
      05e16745
  3. 24 Oct, 2013 1 commit
  4. 22 Oct, 2013 2 commits
  5. 20 Oct, 2013 1 commit
    • Al Viro's avatar
      nfsd regression since delayed fput() · c7314d74
      Al Viro authored
      Background: nfsd v[23] had throughput regression since delayed fput
      went in; every read or write ends up doing fput() and we get a pair
      of extra context switches out of that (plus quite a bit of work
      in queue_work itselfi, apparently).  Use of schedule_delayed_work()
      gives it a chance to accumulate a bit before we do __fput() on all
      of them.  I'm not too happy about that solution, but... on at least
      one real-world setup it reverts about 10% throughput loss we got from
      switch to delayed fput.
      Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
      c7314d74
  6. 18 Oct, 2013 1 commit
  7. 17 Oct, 2013 4 commits
  8. 16 Oct, 2013 1 commit
  9. 15 Oct, 2013 1 commit
  10. 14 Oct, 2013 1 commit
  11. 12 Oct, 2013 2 commits
  12. 11 Oct, 2013 4 commits
    • Miao Xie's avatar
      Btrfs: fix oops caused by the space balance and dead roots · c00869f1
      Miao Xie authored
      When doing space balance and subvolume destroy at the same time, we met
      the following oops:
      
      kernel BUG at fs/btrfs/relocation.c:2247!
      RIP: 0010: [<ffffffffa04cec16>] prepare_to_merge+0x154/0x1f0 [btrfs]
      Call Trace:
       [<ffffffffa04b5ab7>] relocate_block_group+0x466/0x4e6 [btrfs]
       [<ffffffffa04b5c7a>] btrfs_relocate_block_group+0x143/0x275 [btrfs]
       [<ffffffffa0495c56>] btrfs_relocate_chunk.isra.27+0x5c/0x5a2 [btrfs]
       [<ffffffffa0459871>] ? btrfs_item_key_to_cpu+0x15/0x31 [btrfs]
       [<ffffffffa048b46a>] ? btrfs_get_token_64+0x7e/0xcd [btrfs]
       [<ffffffffa04a3467>] ? btrfs_tree_read_unlock_blocking+0xb2/0xb7 [btrfs]
       [<ffffffffa049907d>] btrfs_balance+0x9c7/0xb6f [btrfs]
       [<ffffffffa049ef84>] btrfs_ioctl_balance+0x234/0x2ac [btrfs]
       [<ffffffffa04a1e8e>] btrfs_ioctl+0xd87/0x1ef9 [btrfs]
       [<ffffffff81122f53>] ? path_openat+0x234/0x4db
       [<ffffffff813c3b78>] ? __do_page_fault+0x31d/0x391
       [<ffffffff810f8ab6>] ? vma_link+0x74/0x94
       [<ffffffff811250f5>] vfs_ioctl+0x1d/0x39
       [<ffffffff811258c8>] do_vfs_ioctl+0x32d/0x3e2
       [<ffffffff811259d4>] SyS_ioctl+0x57/0x83
       [<ffffffff813c3bfa>] ? do_page_fault+0xe/0x10
       [<ffffffff813c73c2>] system_call_fastpath+0x16/0x1b
      
      It is because we returned the error number if the reference of the root was 0
      when doing space relocation. It was not right here, because though the root
      was dead(refs == 0), but the space it held still need be relocated, or we
      could not remove the block group. So in this case, we should return the root
      no matter it is dead or not.
      Signed-off-by: 's avatarMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: 's avatarJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: 's avatarChris Mason <chris.mason@fusionio.com>
      c00869f1
    • Miao Xie's avatar
      Btrfs: insert orphan roots into fs radix tree · 14927d95
      Miao Xie authored
      Now we don't drop all the deleted snapshots/subvolumes before the space
      balance. It means we have to relocate the space which is held by the dead
      snapshots/subvolumes. So we must into them into fs radix tree, or we would
      forget to commit the change of them when doing transaction commit, and it
      would corrupt the metadata.
      Signed-off-by: 's avatarMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: 's avatarJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: 's avatarChris Mason <chris.mason@fusionio.com>
      14927d95
    • Josef Bacik's avatar
      Btrfs: limit delalloc pages outside of find_delalloc_range · 7bf811a5
      Josef Bacik authored
      Liu fixed part of this problem and unfortunately I steered him in slightly the
      wrong direction and so didn't completely fix the problem.  The problem is we
      limit the size of the delalloc range we are looking for to max bytes and then we
      try to lock that range.  If we fail to lock the pages in that range we will
      shrink the max bytes to a single page and re loop.  However if our first page is
      inside of the delalloc range then we will end up limiting the end of the range
      to a period before our first page.  This is illustrated below
      
      [0 -------- delalloc range --------- 256mb]
                                        [page]
      
      So find_delalloc_range will return with delalloc_start as 0 and end as 128mb,
      and then we will notice that delalloc_start < *start and adjust it up, but not
      adjust delalloc_end up, so things go sideways.  To fix this we need to not limit
      the max bytes in find_delalloc_range, but in find_lock_delalloc_range and that
      way we don't end up with this confusion.  Thanks,
      Signed-off-by: 's avatarJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: 's avatarChris Mason <chris.mason@fusionio.com>
      7bf811a5
    • Josef Bacik's avatar
      Btrfs: use right root when checking for hash collision · 4871c158
      Josef Bacik authored
      btrfs_rename was using the root of the old dir instead of the root of the new
      dir when checking for a hash collision, so if you tried to move a file into a
      subvol it would freak out because it would see the file you are trying to move
      in its current root.  This fixes the bug where this would fail
      
      btrfs subvol create test1
      btrfs subvol create test2
      mv test1 test2.
      
      Thanks to Chris Murphy for catching this,
      
      Cc: stable@vger.kernel.org
      Reported-by: 's avatarChris Murphy <lists@colorremedies.com>
      Signed-off-by: 's avatarJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: 's avatarChris Mason <chris.mason@fusionio.com>
      4871c158
  13. 07 Oct, 2013 3 commits
  14. 06 Oct, 2013 1 commit
    • Steve French's avatar
      do not treat non-symlink reparse points as valid symlinks · c31f3307
      Steve French authored
      Windows 8 and later can create NFS symlinks (within reparse points)
      which we were assuming were normal NTFS symlinks and thus reporting
      corrupt paths for.  Add check for reparse points to make sure that
      they really are normal symlinks before we try to parse the pathname.
      
      We also should not be parsing other types of reparse points (DFS
      junctions etc) as if they were a  symlink so return EOPNOTSUPP
      on those.  Also fix endian errors (we were not parsing symlink
      lengths as little endian).
      
      This fixes commit d244bf2d
      which implemented follow link for non-Unix CIFS mounts
      
      CC: Stable <stable@kernel.org>
      Reviewed-by: 's avatarAndrew Bartlett <abartlet@samba.org>
      Signed-off-by: 's avatarSteve French <smfrench@gmail.com>
      c31f3307
  15. 05 Oct, 2013 1 commit
    • Darrick J. Wong's avatar
      btrfs: Fix crash due to not allocating integrity data for a bioset · b208c2f7
      Darrick J. Wong authored
      When btrfs creates a bioset, we must also allocate the integrity data pool.
      Otherwise btrfs will crash when it tries to submit a bio to a checksumming
      disk:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
       IP: [<ffffffff8111e28a>] mempool_alloc+0x4a/0x150
       PGD 2305e4067 PUD 23063d067 PMD 0
       Oops: 0000 [#1] PREEMPT SMP
       Modules linked in: btrfs scsi_debug xfs ext4 jbd2 ext3 jbd mbcache
      sch_fq_codel eeprom lpc_ich mfd_core nfsd exportfs auth_rpcgss af_packet
      raid6_pq xor zlib_deflate libcrc32c [last unloaded: scsi_debug]
       CPU: 1 PID: 4486 Comm: mount Not tainted 3.12.0-rc1-mcsum #2
       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       task: ffff8802451c9720 ti: ffff880230698000 task.ti: ffff880230698000
       RIP: 0010:[<ffffffff8111e28a>]  [<ffffffff8111e28a>] mempool_alloc+0x4a/0x150
       RSP: 0018:ffff880230699688  EFLAGS: 00010286
       RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000005f8445
       RDX: 0000000000000001 RSI: 0000000000000010 RDI: 0000000000000000
       RBP: ffff8802306996f8 R08: 0000000000011200 R09: 0000000000000008
       R10: 0000000000000020 R11: ffff88009d6e8000 R12: 0000000000011210
       R13: 0000000000000030 R14: ffff8802306996b8 R15: ffff8802451c9720
       FS:  00007f25b8a16800(0000) GS:ffff88024fc80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 0000000000000018 CR3: 0000000230576000 CR4: 00000000000007e0
       Stack:
        ffff8802451c9720 0000000000000002 ffffffff81a97100 0000000000281250
        ffffffff81a96480 ffff88024fc99150 ffff880228d18200 0000000000000000
        0000000000000000 0000000000000040 ffff880230e8c2e8 ffff8802459dc900
       Call Trace:
        [<ffffffff811b2208>] bio_integrity_alloc+0x48/0x1b0
        [<ffffffff811b26fc>] bio_integrity_prep+0xac/0x360
        [<ffffffff8111e298>] ? mempool_alloc+0x58/0x150
        [<ffffffffa03e8041>] ? alloc_extent_state+0x31/0x110 [btrfs]
        [<ffffffff81241579>] blk_queue_bio+0x1c9/0x460
        [<ffffffff8123e58a>] generic_make_request+0xca/0x100
        [<ffffffff8123e639>] submit_bio+0x79/0x160
        [<ffffffffa03f865e>] btrfs_map_bio+0x48e/0x5b0 [btrfs]
        [<ffffffffa03c821a>] btree_submit_bio_hook+0xda/0x110 [btrfs]
        [<ffffffffa03e7eba>] submit_one_bio+0x6a/0xa0 [btrfs]
        [<ffffffffa03ef450>] read_extent_buffer_pages+0x250/0x310 [btrfs]
        [<ffffffff8125eef6>] ? __radix_tree_preload+0x66/0xf0
        [<ffffffff8125f1c5>] ? radix_tree_insert+0x95/0x260
        [<ffffffffa03c66f6>] btree_read_extent_buffer_pages.constprop.128+0xb6/0x120
      [btrfs]
        [<ffffffffa03c8c1a>] read_tree_block+0x3a/0x60 [btrfs]
        [<ffffffffa03caefd>] open_ctree+0x139d/0x2030 [btrfs]
        [<ffffffffa03a282a>] btrfs_mount+0x53a/0x7d0 [btrfs]
        [<ffffffff8113ab0b>] ? pcpu_alloc+0x8eb/0x9f0
        [<ffffffff81167305>] ? __kmalloc_track_caller+0x35/0x1e0
        [<ffffffff81176ba0>] mount_fs+0x20/0xd0
        [<ffffffff81191096>] vfs_kern_mount+0x76/0x120
        [<ffffffff81193320>] do_mount+0x200/0xa40
        [<ffffffff81135cdb>] ? strndup_user+0x5b/0x80
        [<ffffffff81193bf0>] SyS_mount+0x90/0xe0
        [<ffffffff8156d31d>] system_call_fastpath+0x1a/0x1f
       Code: 4c 8d 75 a8 4c 89 6d e8 45 89 e0 4c 8d 6f 30 48 89 5d d8 41 83 e0 af 48
      89 fb 49 83 c6 18 4c 89 7d f8 65 4c 8b 3c 25 c0 b8 00 00 <48> 8b 73 18 44 89 c7
      44 89 45 98 ff 53 20 48 85 c0 48 89 c2 74
       RIP  [<ffffffff8111e28a>] mempool_alloc+0x4a/0x150
        RSP <ffff880230699688>
       CR2: 0000000000000018
       ---[ end trace 7a96042017ed21e2 ]---
      Signed-off-by: 's avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: 's avatarJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: 's avatarChris Mason <chris.mason@fusionio.com>
      b208c2f7
  16. 04 Oct, 2013 8 commits
    • Ilya Dryomov's avatar
      Btrfs: fix a use-after-free bug in btrfs_dev_replace_finishing · 1357272f
      Ilya Dryomov authored
      free_device rcu callback, scheduled from btrfs_rm_dev_replace_srcdev,
      can be processed before btrfs_scratch_superblock is called, which would
      result in a use-after-free on btrfs_device contents.  Fix this by
      zeroing the superblock before the rcu callback is registered.
      
      Cc: Stefan Behrens <sbehrens@giantdisaster.de>
      Signed-off-by: 's avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: 's avatarJosef Bacik <jbacik@fusionio.com>
      1357272f
    • Ilya Dryomov's avatar
      Btrfs: eliminate races in worker stopping code · 964fb15a
      Ilya Dryomov authored
      The current implementation of worker threads in Btrfs has races in
      worker stopping code, which cause all kinds of panics and lockups when
      running btrfs/011 xfstest in a loop.  The problem is that
      btrfs_stop_workers is unsynchronized with respect to check_idle_worker,
      check_busy_worker and __btrfs_start_workers.
      
      E.g., check_idle_worker race flow:
      
             btrfs_stop_workers():            check_idle_worker(aworker):
      - grabs the lock
      - splices the idle list into the
        working list
      - removes the first worker from the
        working list
      - releases the lock to wait for
        its kthread's completion
                                        - grabs the lock
                                        - if aworker is on the working list,
                                          moves aworker from the working list
                                          to the idle list
                                        - releases the lock
      - grabs the lock
      - puts the worker
      - removes the second worker from the
        working list
                                    ......
              btrfs_stop_workers returns, aworker is on the idle list
                       FS is umounted, memory is freed
                                    ......
                    aworker is waken up, fireworks ensue
      
      With this applied, I wasn't able to trigger the problem in 48 hours,
      whereas previously I could reliably reproduce at least one of these
      races within an hour.
      Reported-by: 's avatarDavid Sterba <dsterba@suse.cz>
      Signed-off-by: 's avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: 's avatarJosef Bacik <jbacik@fusionio.com>
      964fb15a
    • Liu Bo's avatar
      Btrfs: fix crash of compressed writes · 385fe0be
      Liu Bo authored
      The crash[1] is found by xfstests/generic/208 with "-o compress",
      it's not reproduced everytime, but it does panic.
      
      The bug is quite interesting, it's actually introduced by a recent commit
      (573aecaf,
      Btrfs: actually limit the size of delalloc range).
      
      Btrfs implements delay allocation, so during writeback, we
      (1) get a page A and lock it
      (2) search the state tree for delalloc bytes and lock all pages within the range
      (3) process the delalloc range, including find disk space and create
          ordered extent and so on.
      (4) submit the page A.
      
      It runs well in normal cases, but if we're in a racy case, eg.
      buffered compressed writes and aio-dio writes,
      sometimes we may fail to lock all pages in the 'delalloc' range,
      in which case, we need to fall back to search the state tree again with
      a smaller range limit(max_bytes = PAGE_CACHE_SIZE - offset).
      
      The mentioned commit has a side effect, that is, in the fallback case,
      we can find delalloc bytes before the index of the page we already have locked,
      so we're in the case of (delalloc_end <= *start) and return with (found > 0).
      
      This ends with not locking delalloc pages but making ->writepage still
      process them, and the crash happens.
      
      This fixes it by just thinking that we find nothing and returning to caller
      as the caller knows how to deal with it properly.
      
      [1]:
      ------------[ cut here ]------------
      kernel BUG at mm/page-writeback.c:2170!
      [...]
      CPU: 2 PID: 11755 Comm: btrfs-delalloc- Tainted: G           O 3.11.0+ #8
      [...]
      RIP: 0010:[<ffffffff810f5093>]  [<ffffffff810f5093>] clear_page_dirty_for_io+0x1e/0x83
      [...]
      [ 4934.248731] Stack:
      [ 4934.248731]  ffff8801477e5dc8 ffffea00049b9f00 ffff8801869f9ce8 ffffffffa02b841a
      [ 4934.248731]  0000000000000000 0000000000000000 0000000000000fff 0000000000000620
      [ 4934.248731]  ffff88018db59c78 ffffea0005da8d40 ffffffffa02ff860 00000001810016c0
      [ 4934.248731] Call Trace:
      [ 4934.248731]  [<ffffffffa02b841a>] extent_range_clear_dirty_for_io+0xcf/0xf5 [btrfs]
      [ 4934.248731]  [<ffffffffa02a8889>] compress_file_range+0x1dc/0x4cb [btrfs]
      [ 4934.248731]  [<ffffffff8104f7af>] ? detach_if_pending+0x22/0x4b
      [ 4934.248731]  [<ffffffffa02a8bad>] async_cow_start+0x35/0x53 [btrfs]
      [ 4934.248731]  [<ffffffffa02c694b>] worker_loop+0x14b/0x48c [btrfs]
      [ 4934.248731]  [<ffffffffa02c6800>] ? btrfs_queue_worker+0x25c/0x25c [btrfs]
      [ 4934.248731]  [<ffffffff810608f5>] kthread+0x8d/0x95
      [ 4934.248731]  [<ffffffff81060868>] ? kthread_freezable_should_stop+0x43/0x43
      [ 4934.248731]  [<ffffffff814fe09c>] ret_from_fork+0x7c/0xb0
      [ 4934.248731]  [<ffffffff81060868>] ? kthread_freezable_should_stop+0x43/0x43
      [ 4934.248731] Code: ff 85 c0 0f 94 c0 0f b6 c0 59 5b 5d c3 0f 1f 44 00 00 55 48 89 e5 41 54 53 48 89 fb e8 2c de 00 00 49 89 c4 48 8b 03 a8 01 75 02 <0f> 0b 4d 85 e4 74 52 49 8b 84 24 80 00 00 00 f6 40 20 01 75 44
      [ 4934.248731] RIP  [<ffffffff810f5093>] clear_page_dirty_for_io+0x1e/0x83
      [ 4934.248731]  RSP <ffff8801869f9c48>
      [ 4934.280307] ---[ end trace 36f06d3f8750236a ]---
      Signed-off-by: 's avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: 's avatarJosef Bacik <jbacik@fusionio.com>
      385fe0be
    • Josef Bacik's avatar
      Btrfs: fix transid verify errors when recovering log tree · 60e7cd3a
      Josef Bacik authored
      If we crash with a log, remount and recover that log, and then crash before we
      can commit another transaction we will get transid verify errors on the next
      mount.  This is because we were not zero'ing out the log when we committed the
      transaction after recovery.  This is ok as long as we commit another transaction
      at some point in the future, but if you abort or something else goes wrong you
      can end up in this weird state because the recovery stuff says that the tree log
      should have a generation+1 of the super generation, which won't be the case of
      the transaction that was started for recovery.  Fix this by removing the check
      and _always_ zero out the log portion of the super when we commit a transaction.
      This fixes the transid verify issues I was seeing with my force errors tests.
      Thanks,
      Signed-off-by: 's avatarJosef Bacik <jbacik@fusionio.com>
      60e7cd3a
    • Thierry Reding's avatar
      xfs: Use kmem_free() instead of free() · b2a42f78
      Thierry Reding authored
      This fixes a build failure caused by calling the free() function which
      does not exist in the Linux kernel.
      Signed-off-by: 's avatarThierry Reding <treding@nvidia.com>
      Reviewed-by: 's avatarMark Tinguely <tinguely@sgi.com>
      Signed-off-by: 's avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit aaaae980)
      b2a42f78
    • tinguely@sgi.com's avatar
      xfs: fix memory leak in xlog_recover_add_to_trans · 9b3b77fe
      tinguely@sgi.com authored
      Free the memory in error path of xlog_recover_add_to_trans().
      Normally this memory is freed in recovery pass2, but is leaked
      in the error path.
      Signed-off-by: 's avatarMark Tinguely <tinguely@sgi.com>
      Reviewed-by: 's avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: 's avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit 519ccb81)
      9b3b77fe
    • Dave Chinner's avatar
      xfs: dirent dtype presence is dependent on directory magic numbers · 6d313498
      Dave Chinner authored
      The determination of whether a directory entry contains a dtype
      field originally was dependent on the filesystem having CRCs
      enabled. This meant that the format for dtype beign enabled could be
      determined by checking the directory block magic number rather than
      doing a feature bit check. This was useful in that it meant that we
      didn't need to pass a struct xfs_mount around to functions that
      were already supplied with a directory block header.
      
      Unfortunately, the introduction of dtype fields into the v4
      structure via a feature bit meant this "use the directory block
      magic number" method of discriminating the dirent entry sizes is
      broken. Hence we need to convert the places that use magic number
      checks to use feature bit checks so that they work correctly and not
      by chance.
      
      The current code works on v4 filesystems only because the dirent
      size roundup covers the extra byte needed by the dtype field in the
      places where this problem occurs.
      Signed-off-by: 's avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: 's avatarBen Myers <bpm@sgi.com>
      Signed-off-by: 's avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit 367993e7)
      6d313498
    • Dave Chinner's avatar
      xfs: lockdep needs to know about 3 dquot-deep nesting · 89c6c89a
      Dave Chinner authored
      Michael Semon reported that xfs/299 generated this lockdep warning:
      
      =============================================
      [ INFO: possible recursive locking detected ]
      3.12.0-rc2+ #2 Not tainted
      ---------------------------------------------
      touch/21072 is trying to acquire lock:
       (&xfs_dquot_other_class){+.+...}, at: [<c12902fb>] xfs_trans_dqlockedjoin+0x57/0x64
      
      but task is already holding lock:
       (&xfs_dquot_other_class){+.+...}, at: [<c12902fb>] xfs_trans_dqlockedjoin+0x57/0x64
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&xfs_dquot_other_class);
        lock(&xfs_dquot_other_class);
      
       *** DEADLOCK ***
      
       May be due to missing lock nesting notation
      
      7 locks held by touch/21072:
       #0:  (sb_writers#10){++++.+}, at: [<c11185b6>] mnt_want_write+0x1e/0x3e
       #1:  (&type->i_mutex_dir_key#4){+.+.+.}, at: [<c11078ee>] do_last+0x245/0xe40
       #2:  (sb_internal#2){++++.+}, at: [<c122c9e0>] xfs_trans_alloc+0x1f/0x35
       #3:  (&(&ip->i_lock)->mr_lock/1){+.+...}, at: [<c126cd1b>] xfs_ilock+0x100/0x1f1
       #4:  (&(&ip->i_lock)->mr_lock){++++-.}, at: [<c126cf52>] xfs_ilock_nowait+0x105/0x22f
       #5:  (&dqp->q_qlock){+.+...}, at: [<c12902fb>] xfs_trans_dqlockedjoin+0x57/0x64
       #6:  (&xfs_dquot_other_class){+.+...}, at: [<c12902fb>] xfs_trans_dqlockedjoin+0x57/0x64
      
      The lockdep annotation for dquot lock nesting only understands
      locking for user and "other" dquots, not user, group and quota
      dquots. Fix the annotations to match the locking heirarchy we now
      have.
      Reported-by: 's avatarMichael L. Semon <mlsemon35@gmail.com>
      Signed-off-by: 's avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: 's avatarBen Myers <bpm@sgi.com>
      Signed-off-by: 's avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit f112a049)
      89c6c89a
  17. 01 Oct, 2013 2 commits