1. 23 5月, 2018 2 次提交
  2. 21 5月, 2018 4 次提交
  3. 14 5月, 2018 6 次提交
  4. 13 5月, 2018 3 次提交
  5. 12 5月, 2018 2 次提交
  6. 10 5月, 2018 3 次提交
    • E
      ext4: use raw i_version value for ea_inode · e254d1af
      Eryu Guan 提交于
      Currently, creating large xattr (e.g. 2k) in ea_inode would cause
      ea_inode refcount corruption, e.g.
      
        Pass 4: Checking reference counts
        Extended attribute inode 13 ref count is 0, should be 1. Fix? no
      
      This is because that we save the lower 32bit of refcount in
      inode->i_version and store it in raw_inode->i_disk_version on disk.
      But since commit ee73f9a5 ("ext4: convert to new i_version
      API"), we load/store modified i_disk_version from/to disk instead of
      raw value, which causes on-disk ea_inode refcount corruption.
      
      Fix it by loading/storing raw i_version/i_disk_version, because it's
      a self-managed value in this case.
      
      Fixes: ee73f9a5 ("ext4: convert to new i_version API")
      Cc: Tahsin Erdogan <tahsin@google.com>
      Signed-off-by: NEryu Guan <guaneryu@gmail.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      e254d1af
    • E
      ext4: use XATTR_CREATE in ext4_initxattrs() · 3f706c8c
      Eryu Guan 提交于
      I hit ENOSPC error when creating new file in a newly created ext4
      with ea_inode feature enabled, if selinux is enabled and ext4 is
      mounted without any selinux context. e.g.
      
        mkfs -t ext4 -O ea_inode -F /dev/sda5
        mount /dev/sda5 /mnt/ext4
        touch /mnt/ext4/testfile  # got ENOSPC here
      
      It turns out that we run out of journal credits in
      ext4_xattr_set_handle() when creating new selinux label for the
      newly created inode.
      
      This is because that in __ext4_new_inode() we use
      __ext4_xattr_set_credits() to calculate the reserved credits for new
      xattr, with the 'is_create' argument being true, which implies less
      credits in the ea_inode case. But we calculate the required credits
      in ext4_xattr_set_handle() with 'is_create' being false, which means
      we need more credits if ea_inode feature is enabled. So we don't
      have enough credits and error out with ENOSPC.
      
      Fix it by simply calling ext4_xattr_set_handle() with XATTR_CREATE
      flag in ext4_initxattrs(), so we end up with requiring less credits
      than reserved. The semantic of XATTR_CREATE is "Perform a pure
      create, which fails if the named attribute exists already." (from
      setxattr(2)), which is fine in this case, because we only call
      ext4_initxattrs() on newly created inode.
      
      Fixes: af65207c ("ext4: fix __ext4_new_inode() journal credits calculation")
      Cc: Tahsin Erdogan <tahsin@google.com>
      Signed-off-by: NEryu Guan <guaneryu@gmail.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      3f706c8c
    • M
      ext4: make function ‘ext4_getfsmap_find_fixed_metadata’ static · 472d8ea1
      Mathieu Malaterre 提交于
      Since function ‘ext4_getfsmap_find_fixed_metadata’ can be made static,
      make it so. Remove the following gcc warning (W=1):
      
        fs/ext4/fsmap.c:405:5: warning: no previous prototype for ‘ext4_getfsmap_find_fixed_metadata’ [-Wmissing-prototypes]
      Signed-off-by: NMathieu Malaterre <malat@debian.org>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      472d8ea1
  7. 04 5月, 2018 1 次提交
    • J
      bdi: Fix oops in wb_workfn() · b8b78495
      Jan Kara 提交于
      Syzbot has reported that it can hit a NULL pointer dereference in
      wb_workfn() due to wb->bdi->dev being NULL. This indicates that
      wb_workfn() was called for an already unregistered bdi which should not
      happen as wb_shutdown() called from bdi_unregister() should make sure
      all pending writeback works are completed before bdi is unregistered.
      Except that wb_workfn() itself can requeue the work with:
      
      	mod_delayed_work(bdi_wq, &wb->dwork, 0);
      
      and if this happens while wb_shutdown() is waiting in:
      
      	flush_delayed_work(&wb->dwork);
      
      the dwork can get executed after wb_shutdown() has finished and
      bdi_unregister() has cleared wb->bdi->dev.
      
      Make wb_workfn() use wakeup_wb() for requeueing the work which takes all
      the necessary precautions against racing with bdi unregistration.
      
      CC: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      CC: Tejun Heo <tj@kernel.org>
      Fixes: 839a8e86Reported-by: Nsyzbot <syzbot+9873874c735f2892e7e9@syzkaller.appspotmail.com>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      b8b78495
  8. 03 5月, 2018 1 次提交
  9. 02 5月, 2018 2 次提交
    • F
      Btrfs: send, fix missing truncate for inode with prealloc extent past eof · a6aa10c7
      Filipe Manana 提交于
      An incremental send operation can miss a truncate operation when an inode
      has an increased size in the send snapshot and a prealloc extent beyond
      its size.
      
      Consider the following scenario where a necessary truncate operation is
      missing in the incremental send stream:
      
      1) In the parent snapshot an inode has a size of 1282957 bytes and it has
         no prealloc extents beyond its size;
      
      2) In the the send snapshot it has a size of 5738496 bytes and has a new
         extent at offsets 1884160 (length of 106496 bytes) and a prealloc
         extent beyond eof at offset 6729728 (and a length of 339968 bytes);
      
      3) When processing the prealloc extent, at offset 6729728, we end up at
         send.c:send_write_or_clone() and set the @len variable to a value of
         18446744073708560384 because @offset plus the original @len value is
         larger then the inode's size (6729728 + 339968 > 5738496). We then
         call send_extent_data(), with that @offset and @len, which in turn
         calls send_write(), and then the later calls fill_read_buf(). Because
         the offset passed to fill_read_buf() is greater then inode's i_size,
         this function returns 0 immediately, which makes send_write() and
         send_extent_data() do nothing and return immediately as well. When
         we get back to send.c:send_write_or_clone() we adjust the value
         of sctx->cur_inode_next_write_offset to @offset plus @len, which
         corresponds to 6729728 + 18446744073708560384 = 5738496, which is
         precisely the the size of the inode in the send snapshot;
      
      4) Later when at send.c:finish_inode_if_needed() we determine that
         we don't need to issue a truncate operation because the value of
         sctx->cur_inode_next_write_offset corresponds to the inode's new
         size, 5738496 bytes. This is wrong because the last write operation
         that was issued started at offset 1884160 with a length of 106496
         bytes, so the correct value for sctx->cur_inode_next_write_offset
         should be 1990656 (1884160 + 106496), so that a truncate operation
         with a value of 5738496 bytes would have been sent to insert a
         trailing hole at the destination.
      
      So fix the issue by making send.c:send_write_or_clone() not attempt
      to send write or clone operations for extents that start beyond the
      inode's size, since such attempts do nothing but waste time by
      calling helper functions and allocating path structures, and send
      currently has no fallocate command in order to create prealloc extents
      at the destination (either beyond a file's eof or not).
      
      The issue was found running the test btrfs/007 from fstests using a seed
      value of 1524346151 for fsstress.
      Reported-by: NGu, Jinxiang <gujx@cn.fujitsu.com>
      Fixes: ffa7c429 ("Btrfs: send, do not issue unnecessary truncate operations")
      Signed-off-by: NFilipe Manana <fdmanana@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      a6aa10c7
    • E
      btrfs: Take trans lock before access running trans in check_delayed_ref · 998ac6d2
      ethanwu 提交于
      In preivous patch:
      Btrfs: kill trans in run_delalloc_nocow and btrfs_cross_ref_exist
      We avoid starting btrfs transaction and get this information from
      fs_info->running_transaction directly.
      
      When accessing running_transaction in check_delayed_ref, there's a
      chance that current transaction will be freed by commit transaction
      after the NULL pointer check of running_transaction is passed.
      
      After looking all the other places using fs_info->running_transaction,
      they are either protected by trans_lock or holding the transactions.
      
      Fix this by using trans_lock and increasing the use_count.
      
      Fixes: e4c3b2dc ("Btrfs: kill trans in run_delalloc_nocow and btrfs_cross_ref_exist")
      CC: stable@vger.kernel.org # 4.14+
      Signed-off-by: Nethanwu <ethanwu@synology.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      998ac6d2
  10. 27 4月, 2018 1 次提交
  11. 26 4月, 2018 5 次提交
  12. 24 4月, 2018 3 次提交
  13. 23 4月, 2018 1 次提交
  14. 21 4月, 2018 6 次提交