- 06 Aug, 2018 40 commits
-
-
Gu Jinxiang authored
fs_devices is always passed to btrfs_scan_one_device which overrides it. In the call stack below fs_devices is passed to btrfs_scan_one_device from btrfs_mount_root. In btrfs_mount_root the output fs_devices of this call stack is not used. btrfs_mount_root btrfs_parse_early_options btrfs_scan_one_device So, it is not necessary to pass fs_devices from btrfs_mount_root, using a local variable in btrfs_parse_early_options is enough. Signed-off-by:Gu Jinxiang <gujx@cn.fujitsu.com> Reviewed-by:
Anand Jain <Anand.Jain@oracle.com> Reviewed-by:
Nikolay Borisov <nborisov@suse.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
David Sterba authored
Technically this extends the critical section covered by uuid_mutex to: - parse early mount options -- here we can call device scan on paths that can be passed as 'device=/dev/...' - scan the device passed to mount - open the devices related to the fs_devices -- this increases fs_devices::opened The race can happen when mount calls one of the scans and there's another one called eg. by mkfs or 'btrfs dev scan': Mount Scan ----- ---- scan_one_device (dev1, fsid1) scan_one_device (dev2, fsid1) add the device free stale devices fsid1 fs_devices::opened == 0 find fsid1:dev1 free fsid1:dev1 if it's the last one, free fs_devices of fsid1 too open_devices (dev1, fsid1) dev1 not found When fixed, the uuid mutex will make sure that mount will increase fs_devices::opened and this will not be touched by the racing scan ioctl. Reported-and-tested-by: syzbot+909a5177749d7990ffa4@syzkaller.appspotmail.com Reported-and-tested-by: syzbot+ceb2606025ec1cc3479c@syzkaller.appspotmail.com Reviewed-by: -
David Sterba authored
In preparation to take a big lock, move resource initialization before the critical section. It's not obvious from the diff, the desired order is: - initialize mount security options - allocate temporary fs_info - allocate superblock buffers Reviewed-by:
-
David Sterba authored
Prepartory work to fix race between mount and device scan. btrfs_parse_early_options calls the device scan from mount and we'll need to let mount completely manage the critical section. Reviewed-by:
-
David Sterba authored
Prepartory work to fix race between mount and device scan. The callers will have to manage the critical section, eg. mount wants to scan and then call btrfs_open_devices without the ioctl scan walking in and modifying the fs devices in the meantime. Reviewed-by:
-
David Sterba authored
Prepartory work to fix race between mount and device scan. The callers will have to manage the critical section, eg. mount wants to scan and then call btrfs_open_devices without the ioctl scan walking in and modifying the fs devices in the meantime. Reviewed-by:
-
Anand Jain authored
btrfs_free_stale_devices() finds a stale (not opened) device matching path in the fs_uuid list. We are already under uuid_mutex so when we check for each fs_devices, hold the device_list_mutex too. Signed-off-by:
-
Anand Jain authored
Over the years we named %fs_devices and %devices to represent the struct btrfs_fs_devices and the struct btrfs_device. So follow the same scheme here too. No functional changes. Signed-off-by:
-
Anand Jain authored
Make sure the device_list_lock is held the whole time: * when the device is being looked up * new device is initialized and put to the list * the list counters are updated (fs_devices::opened, fs_devices::total_devices) Signed-off-by:
-
Anand Jain authored
btrfs_free_stale_devices() looks for device path reused for another filesystem, and deletes the older fs_devices::device entry. In preparation to handle locking in device_list_add, move btrfs_free_stale_devices outside as these two functions serve a different purpose. Signed-off-by:
-
Nikolay Borisov authored
Since commit 88c14590 ("btrfs: use RCU in btrfs_show_devname for device list traversal") btrfs_show_devname no longer takes device_list_mutex. As such the deadlock that 0ccd0528 ("btrfs: fix a possible umount deadlock") aimed to fix no longer exists, we can free the devices immediatelly and remove the code that does the pending work. Signed-off-by:
-
Qu Wenruo authored
This function is not used since the alloc_start parameter has been obsoleted in commit 0d0c71b3 ("btrfs: obsolete and remove mount option alloc_start"). Signed-off-by:
Qu Wenruo <wqu@suse.com> Reviewed-by:
-
Gu Jinxiang authored
Since parameter flags is no more used since commit d7407606 ("btrfs: split parse_early_options() in two"), remove it. Signed-off-by:
-
Anand Jain authored
In case of deleting the seed device the %cur_devices (seed) and the %fs_devices (parent) are different. Now, as the parent fs_devices::total_devices also maintains the total number of devices including the seed device, so decrement its in-memory value for the successful seed delete. We are already updating its corresponding on-disk btrfs_super_block::number_devices value. Signed-off-by:
-
Nikolay Borisov authored
Commit 5d23515b ("btrfs: Move qgroup rescan on quota enable to btrfs_quota_enable") not only resulted in an easier to follow code but it also introduced a subtle bug. It changed the timing when the initial transaction rescan was happening: - before the commit: it would happen after transaction commit had occured - after the commit: it might happen before the transaction was committed This results in failure to correctly rescan the quota since there could be data which is still not committed on disk. This patch aims to fix this by moving the transaction creation/commit inside btrfs_quota_enable, which allows to schedule the quota commit after the transaction has been committed. Fixes: 5d23515b ("btrfs: Move qgroup rescan on quota enable to btrfs_quota_enable") Reported-by:
Misono Tomohiro <misono.tomohiro@jp.fujitsu.com> Link: https://marc.info/?l=linux-btrfs&m=152999289017582Signed-off-by:
-
David Sterba authored
Add fall-back code to catch failure of full_stripe_write. Proper error handling from inside run_plug would need more code restructuring as it's called at arbitrary points by io scheduler. Signed-off-by: -
David Sterba authored
There's only one call site of the unlocked helper so it can be folded into the caller. Signed-off-by: -
David Sterba authored
Signed-off-by: -
David Sterba authored
Signed-off-by: -
David Sterba authored
Signed-off-by: -
David Sterba authored
Add helper that schedules a given function to run on the rmw workqueue. This will replace several standalone helpers. Signed-off-by: -
David Sterba authored
The helper is trivial and marked as deprecated. Signed-off-by: -
David Sterba authored
The loops iterating eb pages use unsigned long, that's an overkill as we know that there are at most 16 pages (64k / 4k), and 4 by default (with nodesize 16k). Reviewed-by:
-
David Sterba authored
Reviewed-by:
-
David Sterba authored
Almost all callers pass the start and len as 2 arguments but this is not necessary, all the information is provided by the eb. By reordering the calls to num_extent_pages, we don't need the local variables with start/len. Reviewed-by:
-
David Sterba authored
Remove includes if none of the interfaces and exports is used in the given source file. Signed-off-by: -
David Sterba authored
Use the helper that's possibly optimized for full page copies. Signed-off-by: -
David Sterba authored
Functions that get btrfs inode can simply reach the fs_info by dereferencing the root and this looks a bit more straightforward compared to the btrfs_sb(...) indirection. If the transaction handle is available and not NULL it's used instead. Signed-off-by: -
David Sterba authored
There are several places when the btrfs inode is converted to the generic inode, back to btrfs and then passed to btrfs_ino. We can remove the extra back and forth conversions. Signed-off-by: -
Zhihui Zhang authored
io_ctl_set_generation() assumes that the generation number shares the same page with inline CRCs. Let's make sure this is always true. Signed-off-by:
Zhihui Zhang <zzhsuny@gmail.com> Reviewed-by:
-
Anand Jain authored
There is only usage of the declared devices variable, instead use its value directly. Signed-off-by:
-
Anand Jain authored
There are many instances of the %fs_info->fs_devices pointer dereferences, use a temporary variable instead. Signed-off-by:
-
Qu Wenruo authored
Invalid reloc tree can cause kernel NULL pointer dereference when btrfs does some cleanup of the reloc roots. It turns out that fs_info::reloc_ctl can be NULL in btrfs_recover_relocation() as we allocate relocation control after all reloc roots have been verified. So when we hit: note, we haven't called set_reloc_control() thus fs_info::reloc_ctl is still NULL. Link: https://bugzilla.kernel.org/show_bug.cgi?id=199833Reported-by:
Xu Wen <wen.xu@gatech.edu> Signed-off-by:
-
Qu Wenruo authored
A crafted image has empty root tree block, which will later cause NULL pointer dereference. The following trees should never be empty: 1) Tree root Must contain at least root items for extent tree, device tree and fs tree 2) Chunk tree Or we can't even bootstrap as it contains the mapping. 3) Fs tree At least inode item for top level inode (.). 4) Device tree Dev extents for chunks 5) Extent tree Must have corresponding extent for each chunk. If any of them is empty, we are sure the fs is corrupted and no need to mount it. Link: https://bugzilla.kernel.org/show_bug.cgi?id=199847Reported-by:
-
Qu Wenruo authored
A crafted image with invalid block group items could make free space cache code to cause panic. We could detect such invalid block group item by checking: 1) Item size Known fixed value. 2) Block group size (key.offset) We have an upper limit on block group item (10G) 3) Chunk objectid Known fixed value. 4) Type Only 4 valid type values, DATA, METADATA, SYSTEM and DATA|METADATA. No more than 1 bit set for profile type. 5) Used space No more than the block group size. This should allow btrfs to detect and refuse to mount the crafted image. Link: https://bugzilla.kernel.org/show_bug.cgi?id=199849Reported-by:
-
David Sterba authored
The v0 extent type checks are the right case for the unlikely annotations as we don't expect to ever see them, so let's give the compiler some hint. Reviewed-by:
-
Nikolay Borisov authored
Following the removal of the v0 handling code let's be courteous and print an error message when such extents are handled. In the cases where we have a transaction just abort it, otherwise just call btrfs_handle_fs_error. Both cases result in the FS being re-mounted RO. In case the error handling would be too intrusive, leave the BUG_ON in place, like extent_data_ref_count, other proper handling would catch that earlier. Signed-off-by:
-
Nikolay Borisov authored
The v0 compat code was introduced in commit 5d4f98a2 ("Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE)") 9 years ago, which was merged in 2.6.31. This means that the code is there to support filesystems which are _VERY_ old and if you are using btrfs on such an old kernel, you have much bigger problems. This coupled with the fact that no one is likely testing/maintining this code likely means it has bugs lurking. All things considered I think 43 kernel releases later it's high time this remnant of the past got removed. This patch removes all code wrapped in #ifdefs but leaves the BUG_ONs in case we have a v0 with no support intact as a sort of safety-net. Signed-off-by:
-
Chengguang Xu authored
It's only coding style fix not functinal change. When if/else has only one statement then the braces are not needed. Signed-off-by:
Chengguang Xu <cgxu519@gmx.com> Reviewed-by:
-
Chengguang Xu authored
It's not good to override the error code when failing from btrfs_getxattr() in btrfs_get_acl() because it hides the real reason of the failure. Signed-off-by:
-
