aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-02-06Btrfs: fix EDQUOT handling in btrfs_delalloc_reserve_metadataJan Schmidt1-12/+10
When btrfs_qgroup_reserve returned a failure, we were missing a counter operation for BTRFS_I(inode)->outstanding_extents++, leading to warning messages about outstanding extents and space_info->bytes_may_use != 0. Additionally, the error handling code didn't take into account that we dropped the inode lock which might require more cleanup. Luckily, all the cleanup code we need is already there and can be shared with reserve_metadata_bytes, which is exactly what this patch does. Reported-by: Lev Vainblat <[email protected]> Signed-off-by: Jan Schmidt <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-02-05Merge git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git ↵Chris Mason16-119/+370
for-chris into for-linus
2013-02-05Btrfs: fix possible stale data exposureJosef Bacik1-1/+1
We specifically do not update the disk i_size if there are ordered extents outstanding for any area between the current disk_i_size and our ordered extent so that we do not expose stale data. The problem is the check we have only checks if the ordered extent starts at or after the current disk_i_size, which doesn't take into account an ordered extent that starts before the current disk_i_size and ends past the disk_i_size. Fix this by checking if the extent ends past the disk_i_size. Thanks, Signed-off-by: Josef Bacik <[email protected]>
2013-02-05Btrfs: fix missing i_size updateJosef Bacik1-2/+9
If we have an ordered extent before the ordered extent we are currently completing that is after the current disk_i_size we will put our i_size update into that ordered extent so that we do not expose stale data. The problem is that if our disk i_size is updated past the previous ordered extent we won't update the i_size with the pending i_size update. So check the pending i_size update and if its above the current disk i_size we need to go ahead and try to update. Thanks, Signed-off-by: Josef Bacik <[email protected]>
2013-02-05Btrfs: fix race between snapshot deletion and getting inodeLiu Bo2-9/+38
While running snapshot testscript created by Mitch and David, the race between autodefrag and snapshot deletion can lead to corruption of dead_root list so that we can get crash on btrfs_clean_old_snapshots(). And besides autodefrag, scrub also does the same thing, ie. read root first and get inode. Here is the story(take autodefrag as an example): (1) when we delete a snapshot or subvolume, it will set its root's refs to zero and do a iput() on its own inode, and if this inode happens to be the only active in-meory one in root's inode rbtree, it will add itself to the global dead_roots list for later cleanup. (2) after (1), the autodefrag thread may read another inode for defrag and the inode is just in the deleted snapshot/subvolume, but all of these are without checking if the root is still valid(refs > 0). So the end up result is adding the deleted snapshot/subvolume's root to the global dead_roots list AGAIN. Fortunately, we already have a srcu lock to avoid the race, ie. subvol_srcu. So all we need to do is to take the lock to protect 'read root and get inode', since we synchronize to wait for the rcu grace period before adding something to the global dead_roots list. Reported-by: Mitch Harder <[email protected]> Signed-off-by: Liu Bo <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-02-05Btrfs: fix missing release of the space/qgroup reservation in ↵Miao Xie1-8/+19
start_transaction() When we fail to start a transaction, we need to release the reserved free space and qgroup space, fix it. Signed-off-by: Miao Xie <[email protected]> Reviewed-by: Jan Schmidt <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-02-05Btrfs: fix wrong sync_writers decrement in btrfs_file_aio_write()Miao Xie1-1/+2
If the checks at the beginning of btrfs_file_aio_write() fail, we needn't decrease ->sync_writers, because we have not increased it. Fix it. Signed-off-by: Miao Xie <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-02-05Btrfs: do not merge logged extents if we've removed them from the treeJosef Bacik1-1/+2
You can run into this problem where if somebody is fsyncing and writing out the existing extents you will have removed the extent map from the em tree, but it's still valid for the current fsync so we go ahead and write it. The problem is we unconditionally try to merge it back into the em tree, but if we've removed it from the em tree that will cause use after free problems. Fix this to only merge if we are still a part of the tree. Thanks, Signed-off-by: Josef Bacik <[email protected]>
2013-02-01btrfs: don't try to notify udev about missing devicesEric Sandeen1-1/+2
If we remove a missing device, bdev is null, and if we send that off to btrfs_kobject_uevent we'll panic. Signed-off-by: Eric Sandeen <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-01-24Btrfs: fix repeated delalloc work allocationMiao Xie1-14/+41
btrfs_start_delalloc_inodes() locks the delalloc_inodes list, fetches the first inode, unlocks the list, triggers btrfs_alloc_delalloc_work/ btrfs_queue_worker for this inode, and then it locks the list, checks the head of the list again. But because we don't delete the first inode that it deals with before, it will fetch the same inode. As a result, this function allocates a huge amount of btrfs_delalloc_work structures, and OOM happens. Fix this problem by splice this delalloc list. Reported-by: Alex Lyakas <[email protected]> Signed-off-by: Miao Xie <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-01-24Btrfs: fix wrong max device number for single profileMiao Xie1-1/+1
The max device number of single profile is 1, not 0 (0 means 'as many as possible'). Fix it. Cc: Liu Bo <[email protected]> Signed-off-by: Miao Xie <[email protected]> Reviewed-by: Liu Bo <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-01-24Btrfs: fix missed transaction->aborted checkMiao Xie1-0/+16
First, though the current transaction->aborted check can stop the commit early and avoid unnecessary operations, it is too early, and some transaction handles don't end, those handles may set transaction->aborted after the check. Second, when we commit the transaction, we will wake up some worker threads to flush the space cache and inode cache. Those threads also allocate some transaction handles and may set transaction->aborted if some serious error happens. So we need more check for ->aborted when committing the transaction. Fix it. Signed-off-by: Miao Xie <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-01-24Btrfs: Add ACCESS_ONCE() to transaction->abort accessesMiao Xie2-2/+3
We may access and update transaction->aborted on the different CPUs without lock, so we need ACCESS_ONCE() wrapper to prevent the compiler from creating unsolicited accesses and make sure we can get the right value. Signed-off-by: Miao Xie <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-01-24Btrfs: put csums on the right ordered extentJosef Bacik1-2/+2
I noticed a WARN_ON going off when adding csums because we were going over the amount of csum bytes that should have been allowed for an ordered extent. This is a leftover from when we used to hold the csums privately for direct io, but now we use the normal ordered sum stuff so we need to make sure and check if we've moved on to another extent so that the csums are added to the right extent. Without this we could end up with csums for bytenrs that don't have extents to cover them yet. Thanks, Signed-off-by: Josef Bacik <[email protected]>
2013-01-24Btrfs: use right range to find checksum for compressed extentsLiu Bo1-0/+5
For compressed extents, the range of checksum is covered by disk length, and the disk length is different with ram length, so we need to use disk length instead to get us the right checksum. Signed-off-by: Liu Bo <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-01-24Btrfs: fix panic when recovering tree logJosef Bacik1-8/+12
A user reported a BUG_ON(ret) that occured during tree log replay. Ret was -EAGAIN, so what I think happened is that we removed an extent that covered a bitmap entry and an extent entry. We remove the part from the bitmap and return -EAGAIN and then search for the next piece we want to remove, which happens to be an entire extent entry, so we just free the sucker and return. The problem is ret is still set to -EAGAIN so we trip the BUG_ON(). The user used btrfs-zero-log so I'm not 100% sure this is what happened so I've added a WARN_ON() to catch the other possibility. Thanks, Reported-by: Jan Steffens <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-01-24Btrfs: do not allow logged extents to be merged or removedJosef Bacik3-3/+16
We drop the extent map tree lock while we're logging extents, so somebody could come in and merge another extent into this one and screw up our logging, or they could even remove us from the list which would keep us from logging the extent or freeing our ref on it, so we need to make sure to not clear LOGGING until after the extent is logged, and then we can merge it to adjacent extents. Thanks, Signed-off-by: Josef Bacik <[email protected]>
2013-01-21Btrfs: fix a regression in balance usage filterIlya Dryomov1-1/+8
Commit 3fed40cc ("Btrfs: cleanup duplicated division functions"), which was merged into 3.8-rc1, has introduced a regression by removing logic that was guarding us against bad user input. Bring it back. Signed-off-by: Ilya Dryomov <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-01-21Merge branch 'mutex-ops@next-for-chris' of ↵Chris Mason2-31/+86
git://github.com/idryomov/btrfs-unstable into linus
2013-01-21Merge branch 'for-chris' of ↵Chris Mason6-35/+91
git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next into linus
2013-01-21Btrfs: prevent qgroup destroy when there are still relationsArne Jansen1-1/+12
Currently you can just destroy a qgroup even though it is in use by other qgroups or has qgroups assigned to it. This patch prevents destruction of qgroups unless they are completely unused. Otherwise destroy will return EBUSY. Reported-by: Eric Hopper <[email protected]> Signed-off-by: Arne Jansen <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-01-21Btrfs: ignore orphan qgroup relationsArne Jansen1-0/+7
If a qgroup that has still assignments is deleted by the user, the corresponding relations are left in the tree. This leads to an unmountable filesystem. With this patch, those relations are simple ignored. Reported-by: Eric Hopper <[email protected]> Signed-off-by: Arne Jansen <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2013-01-20Btrfs: reorder locks and sanity checks in btrfs_ioctl_defragIlya Dryomov1-8/+9
Operation-specific check (whether subvol is readonly or not) should go after the mutual exclusiveness check. Signed-off-by: Ilya Dryomov <[email protected]>
2013-01-20Btrfs: fix unlock order in btrfs_ioctl_rm_devIlya Dryomov1-1/+1
Fix unlock order in btrfs_ioctl_rm_dev(). Signed-off-by: Ilya Dryomov <[email protected]>
2013-01-20Btrfs: fix unlock order in btrfs_ioctl_resizeIlya Dryomov1-1/+1
Fix unlock order in btrfs_ioctl_resize(). Signed-off-by: Ilya Dryomov <[email protected]>
2013-01-20Btrfs: fix "mutually exclusive op is running" error codeIlya Dryomov1-4/+4
The error code that is returned in response to starting a mutually exclusive operation when there is one already running got silently changed from EINVAL to EINPROGRESS by 5ac00add. Returning EINPROGRESS to, say, add_dev, when rm_dev is running is misleading. Furthermore, the operation itself may want to use EINPROGRESS for other purposes. Signed-off-by: Ilya Dryomov <[email protected]>
2013-01-20Btrfs: bring back balance pause/resume logicIlya Dryomov2-17/+71
Balance pause/resume logic got broken by 5ac00add (went in into 3.8-rc1 as part of dev-replace merge). Offending commit took a stab at making mutually exclusive volume operations (add_dev, rm_dev, resize, balance, replace_dev) not block behind volume_mutex if another such operation is in progress and instead return an error right away. Balancing front-end relied on the blocking behaviour, so the fix is ugly, but short of a complete rework, it's the best we can do. Reported-by: Liu Bo <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2013-01-14btrfs: update timestamps on truncate()Eric Sandeen1-3/+14
truncate() vs. ftruncate() differ in the VFS; truncate() doesn't set (ATTR_CTIME | ATTR_MTIME), and it's up to the fs to do the timestamp updates if the size changes. Signed-off-by: Eric Sandeen <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-01-14btrfs: fix btrfs_cont_expand() freeing IS_ERR emZach Brown1-0/+1
btrfs_cont_expand() tries to free an IS_ERR em as it gets an error from btrfs_get_extent() and breaks out of its loop. An instance of -EEXIST was reported in the wild: https://bugzilla.redhat.com/show_bug.cgi?id=874407 I have no idea if that -EEXIST is surprising, or not. Regardless, this error handling should be cleaned up to handle other reasonable errors (ENOMEM, EIO; whatever). This seemed to be the only buggy freeing of the relatively rare IS_ERR em so I opted to fix the caller rather than teach free_extent_map() to use IS_ERR_OR_NULL(). Signed-off-by: Zach Brown <[email protected]> Reviewed-by: Eric Sandeen <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-01-14Btrfs: fix a bug when llseek for delalloc bytes behind prealloc extentsLiu Bo2-6/+14
xfstests case 285 complains. It it because btrfs did not try to find unwritten delalloc bytes(only dirty pages, not yet writeback) behind prealloc extents, it ends up finding nothing while we're with SEEK_DATA. Signed-off-by: Liu Bo <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-01-14Btrfs: fix off-by-one in lseekLiu Bo1-0/+1
Lock end is inclusive. Signed-off-by: Liu Bo <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-01-14Btrfs: reset path lock state to zeroLiu Bo1-0/+2
We forgot to reset the path lock state to zero after we unlock the path block, and this can lead to the ASSERT checker in tree unlock API. Reported-by: Slava Barinov <[email protected]> Signed-off-by: Liu Bo <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-01-14Btrfs: let allocation start from the right raid typeLiu Bo1-1/+1
This'd avoid us empty looping. Say we have only one disk and the metadata raid type will be defaultly DUP, and we do not need to start from index=0(RAID10) and get over two empty loops to index=2(DUP). Signed-off-by: Liu Bo <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-01-14Btrfs: add orphan before truncating pagecacheJosef Bacik1-15/+38
Running xfstests 83 in a loop would sometimes fail the fsck. This happens because if we invalidate a page that already has an ordered extent setup for it we will complete the ordered extent ourselves, assuming that the truncate will clean everything up. The problem with this is there is plenty of time for the truncate to fail after we've done this work. So to fix this we need to add the orphan item first to make sure the cleanup gets done properly, and then we can truncate the pagecache and all that stuff and be safe. This fixes the btrfsck failures I was seeing while running 83 in a loop. Thanks, Signed-off-by: Josef Bacik <[email protected]>
2013-01-14Btrfs: set flushing if we're limited flushingJosef Bacik1-1/+1
We still need to say we're flushing if we're limit flushing to keep somebody from coming in and stealing our reservation. Thanks, Signed-off-by: Josef Bacik <[email protected]>
2013-01-14Btrfs: fix missing write access release in btrfs_ioctl_resize()Miao Xie1-0/+1
We forget to give up the write access after we find some device operation is going on. Fix it. Signed-off-by: Miao Xie <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-01-14Btrfs: fix resize a readonly deviceMiao Xie1-2/+4
We should not resize a readonly device, fix it. Signed-off-by: Miao Xie <[email protected]> Signed-off-by: Josef Bacik <[email protected]>
2013-01-14Btrfs: do not delete a subvolume which is in a R/O subvolumeMiao Xie1-5/+5
Step to reproduce: # mkfs.btrfs <disk> # mount <disk> <mnt> # btrfs sub create <mnt>/subv0 # btrfs sub snap <mnt> <mnt>/subv0/snap0 # change <mnt>/subv0 from R/W to R/O # btrfs sub del <mnt>/subv0/snap0 We deleted the snapshot successfully. I think we should not be able to delete the snapshot since the parent subvolume is R/O. Signed-off-by: Miao Xie <[email protected]>
2013-01-14Btrfs: disable qgroup id 0Miao Xie1-0/+5
Qgroup id 0 is a special number, we should set the id of a qgroup to 0. Fix it. Signed-off-by: Miao Xie <[email protected]>
2013-01-14btrfs: get the device in write mode when deleting itLukas Czerner1-1/+1
When we're deleting the device we should get it in write mode since we're going to re-write the super block magic on that device. And it should fail if the device is read-only. Signed-off-by: Lukas Czerner <[email protected]>
2013-01-14Btrfs: fix memory leak in name_cache_insert()Tsutomu Itoh1-1/+3
We should free name_cache_entry before returning from the error handling code. Signed-off-by: Tsutomu Itoh <[email protected]>
2012-12-18Revert "Btrfs: reorder tree mod log operations in deleting a pointer"Chris Mason1-6/+4
This reverts commit 6a7a665d78c5dd8bc76a010648c4e7d84517ab5a. This was bug was fixed differently in 3.6, so this commit isn't needed. Conflicts: fs/btrfs/ctree.c Signed-off-by: Chris Mason <[email protected]>
2012-12-18Revert "Btrfs: MOD_LOG_KEY_REMOVE_WHILE_MOVING never change node's nritems"Chris Mason1-2/+2
This reverts commit 95c80bb1f6b24b57058d971ed252b2c1c5121b51. The bug addressed by this commit was fixed differently back in 3.6 Signed-off-by: Chris Mason <[email protected]>
2012-12-17Btrfs: fix a bug of per-file nocowLiu Bo2-3/+5
Users report a bug, the reproducer is: $ mkfs.btrfs /dev/loop0 $ mount /dev/loop0 /mnt/btrfs/ $ mkdir /mnt/btrfs/dir $ chattr +C /mnt/btrfs/dir/ $ dd if=/dev/zero of=/mnt/btrfs/dir/foo bs=4K count=10; $ lsattr /mnt/btrfs/dir/foo ---------------C- /mnt/btrfs/dir/foo $ filefrag /mnt/btrfs/dir/foo /mnt/btrfs/dir/foo: 1 extent found ---> an extent $ dd if=/dev/zero of=/mnt/btrfs/dir/foo bs=4K count=1 seek=5 conv=notrunc,nocreat; sync $ filefrag /mnt/btrfs/dir/foo /mnt/btrfs/dir/foo: 3 extents found ---> with nocow, btrfs breaks the extent into three parts The new created file should not only inherit the NODATACOW flag, but also honor NODATASUM flag, because we must do COW on a file extent with checksum. Signed-off-by: Liu Bo <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2012-12-17Btrfs: fix hash overflow handlingChris Mason5-2/+95
The handling for directory crc hash overflows was fairly obscure, split_leaf returns EOVERFLOW when we try to extend the item and that is supposed to bubble up to userland. For a while it did so, but along the way we added better handling of errors and forced the FS readonly if we hit IO errors during the directory insertion. Along the way, we started testing only for EEXIST and the EOVERFLOW case was dropped. The end result is that we may force the FS readonly if we catch a directory hash bucket overflow. This fixes a few problem spots. First I add tests for EOVERFLOW in the places where we can safely just return the error up the chain. btrfs_rename is harder though, because it tries to insert the new directory item only after it has already unlinked anything the rename was going to overwrite. Rather than adding very complex logic, I added a helper to test for the hash overflow case early while it is still safe to bail out. Snapshot and subvolume creation had a similar problem, so they are using the new helper now too. Signed-off-by: Chris Mason <[email protected]> Reported-by: Pascal Junod <[email protected]>
2012-12-16Btrfs: don't take inode delalloc mutex if we're a free space inodeJosef Bacik1-6/+19
This confuses and angers lockdep even though it's ok. We don't really need the lock for free space inodes since only the transaction committer will be reserving space. Thanks, Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2012-12-16Btrfs: fix autodefrag and umount lockupJosef Bacik1-2/+17
This happens because writeback_inodes_sb_nr_if_idle does down_read. This doesn't work for us and it has not been fixed upstream yet, so do it ourselves and use that instead so we can stop having this stupid long standing lockup. Thanks, Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2012-12-16Btrfs: fix permissions of empty files not affected by umaskFilipe Brandenburger1-0/+4
When a new file is created with btrfs_create(), the inode will initially be created with permissions 0666 and later on in btrfs_init_acl() it will be adapted to mask out the umask bits. The problem is that this change won't make it into the btrfs_inode unless there's another change to the inode (e.g. writing content changing the size or touching the file changing the mtime.) This fix adds a call to btrfs_update_inode() to btrfs_create() to make sure that the change will not get lost if the in-memory inode is flushed before other changes are made to the file. Signed-off-by: Filipe Brandenburger <[email protected]> Reviewed-by: Liu Bo <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2012-12-16Btrfs: put raid properties into global tableLiu Bo4-33/+29
Raid properties can be shared among raid calculation code, we can put them into a global table to keep it simple. Signed-off-by: Liu Bo <[email protected]> Signed-off-by: Chris Mason <[email protected]>
2012-12-16Btrfs: fix BUG() in scrub when first superblock reading gives EIOStefan Behrens1-0/+11
This fixes a very special case that can be reproduced by just disconnecting a disk at runtime, and without unmounting the filesystem first, start scrub on the filesystem with the disconnected disk. All read and write EIOs are handled correctly, only the first superblock is an exception and gives a BUG() in a subfunction. The BUG() is correct, it would crash later otherwise. The subfunction must not be called for superblocks and this is what the fix changes. Reported-by: Joeri Vanthienen <[email protected]> Signed-off-by: Stefan Behrens <[email protected]> Signed-off-by: Chris Mason <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.