- 02 Aug, 2010 40 commits
-
-
Avi Kivity authored
If cr0.wp=0, we have to allow the guest kernel access to a page with pte.w=0. We do that by setting spte.w=1, since the host cr0.wp must remain set so the host can write protect pages. Once we allow write access, we must remove user access otherwise we mistakenly allow the user to write the page. Reviewed-by:
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by:
Avi Kivity <avi@redhat.com> (cherry picked from commit 69325a12)
-
Frank Mayhar authored
commit 14ece102 upstream (as of v2.6.34-git13) Add a new ext4 state to tell us when a file has been newly created; use that state in ext4_sync_file in no-journal mode to tell us when we need to sync the parent directory as well as the inode and data itself. This fixes a problem in which a panic or power failure may lose the entire file even when using fsync, since the parent directory entry is lost. Addresses-Google-Bug: #2480057 Signed-off-by:
Frank Mayhar <fmayhar@google.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ben Hutchings authored
commit 4d92dc0f upstream (as of v2.6.34-git13) struct ext4_new_group_input needs to be converted because u64 has only 32-bit alignment on some 32-bit architectures, notably i386. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Ben Hutchings authored
commit 899ad0ce upstream (as of v2.6.34-git13) It is unnecessary, and in general impossible, to define the compat ioctl numbers except when building the filesystem with CONFIG_COMPAT defined. Signed-off-by:
-
Dmitry Monakhov authored
commit 0617b83f upstream (as of v2.6.34-git13) If i_data_sem was internally dropped due to transaction restart, it is necessary to restart path look-up because extents tree was possibly modified by ext4_get_block(). https://bugzilla.kernel.org/show_bug.cgi?id=15827Signed-off-by:
Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Theodore Ts'o authored
commit 786ec791 upstream (as of v2.6.34-git13) Dimitry Monakhov discovered an edge case where it was possible for the EXT4_EOFBLOCKS_FL flag could get cleared unnecessarily. This is true; I have a test case that can be exercised via downloading and decompressing the file: wget ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/ext4-testcases/eofblocks-fl-test-case.img.bz2 bunzip2 eofblocks-fl-test-case.img dd if=/dev/zero of=eofblocks-fl-test-case.img bs=1k seek=17925 bs=1k count=1 conv=notrunc However, triggering it in real life is highly unlikely since it requires an extremely fragmented sparse file with a hole in exactly the right place in the extent tree. (It actually took quite a bit of work to generate this test case.) Still, it's nice to get even extreme corner cases to be correct, so this patch makes sure that we don't clear the EXT4_EOFBLOCKS_FL incorrectly even in this corner case. Signed-off-by:
-
Theodore Ts'o authored
commit f70f362b upstream (as of v2.6.34-git13) If the EOFBLOCK_FL flag is set when it should not be and the inode is zero length, then eh_entries is zero, and ex is NULL, so dereferencing ex to print ex->ee_block causes a kernel OOPS in ext4_ext_map_blocks(). On top of that, the error message which is printed isn't very helpful. So we fix this by printing something more explanatory which doesn't involve trying to print ex->ee_block. Addresses-Google-Bug: #2655740 Signed-off-by:
-
Dmitry Monakhov authored
commit 12e9b892 upstream (as of v2.6.34-git13) At several places we modify EXT4_I(inode)->i_flags without holding i_mutex (ext4_do_update_inode, ...). These modifications are racy and we can lose updates to i_flags. So convert handling of i_flags to use bitops which are atomic. https://bugzilla.kernel.org/show_bug.cgi?id=15792Signed-off-by:
-
Jan Kara authored
commit 39a4bade upstream (as of v2.6.34-git13) We failed to show journal_checksum option in /proc/mounts. Fix it. Signed-off-by:
-
Curt Wohlgemuth authored
commit 8a57d9d6 upstream (as of v2.6.34-git13) This adds a new field in ext4_group_info to cache the largest available block range in a block group; and don't load the buddy pages until *after* we've done a sanity check on the block group. With large allocation requests (e.g., fallocate(), 8MiB) and relatively full partitions, it's easy to have no block groups with a block extent large enough to satisfy the input request length. This currently causes the loop during cr == 0 in ext4_mb_regular_allocator() to load the buddy bitmap pages for EVERY block group. That can be a lot of pages. The patch below allows us to call ext4_mb_good_group() BEFORE we load the buddy pages (although we have check again after we lock the block group). Addresses-Google-Bug: #2578108 Addresses-Google-Bug: #2704453 Signed-off-by:
Curt Wohlgemuth <curtw@google.com> Signed-off-by:
-
Nikanth Karthikesan authored
commit 6d19c42b upstream (as of v2.6.34-git13) Currently using posix_fallocate one can bypass an RLIMIT_FSIZE limit and create a file larger than the limit. Add a check for that. Signed-off-by:
Nikanth Karthikesan <knikanth@suse.de> Signed-off-by:
Amit Arora <aarora@in.ibm.com> Signed-off-by:
-
Curt Wohlgemuth authored
commit fbe845dd upstream (as of v2.6.34-git13) Addresses-Google-Bug: #2562325 Signed-off-by:
-
Dmitry Monakhov authored
commit 84061e07 upstream (as of v2.6.34-git13) Currently block/inode/dir counters initialized before journal was recovered. In fact after journal recovery this info will probably change. And freeblocks it critical for correct delalloc mode accounting. https://bugzilla.kernel.org/show_bug.cgi?id=15768Signed-off-by:
-
Dmitry Monakhov authored
commit d17413c0 upstrea (as of v2..34-git13) - Reorganize locking scheme to batch two atomic operation in to one. This also allow us to state what healthy group must obey following rule ext4_free_inodes_count(sb, gdp) == ext4_count_free(inode_bitmap, NUM); - Fix possible undefined pointer dereference. - Even if group descriptor stats aren't accessible we have to update inode bitmaps. - Move non-group members update out of group_lock. Note: this commit has been observed to fix fs corruption problems under heavy fs load Signed-off-by:
-
Dmitry Monakhov authored
commit 21ca087a upstream (as of v2.6.34-git13) The extents code will sometimes zero out blocks and mark them as initialized instead of splitting an extent into several smaller ones. This optimization however, causes problems if the extent is beyond i_size because fsck will complain if there are uninitialized blocks after i_size as this can not be distinguished from an inode that has an incorrect i_size field. https://bugzilla.kernel.org/show_bug.cgi?id=15742Signed-off-by:
-
Eric Sandeen authored
commit c445e3e0 upstream (as of v2.6.34-git13) There was a bug reported on RHEL5 that a 10G dd on a 12G box had a very, very slow sync after that. At issue was the loop in write_cache_pages scanning all the way to the end of the 10G file, even though the subsequent call to mpage_da_submit_io would only actually write a smallish amt; then we went back to the write_cache_pages loop ... wasting tons of time in calling __mpage_da_writepage for thousands of pages we would just revisit (many times) later. Upstream it's not such a big issue for sys_sync because we get to the loop with a much smaller nr_to_write, which limits the loop. However, talking with Aneesh he realized that fsync upstream still gets here with a very large nr_to_write and we face the same problem. This patch makes mpage_add_bh_to_extent stop the loop after we've accumulated 2048 pages, by setting mpd->io_done = 1; which ultimately causes the write_cache_pages loop to break. Repeating the test with a dirty_ratio of 80 (to leave something for fsync to do), I don't see huge IO performance gains, but the reduction in cpu usage is striking: 80% usage with stock, and 2% with the below patch. Instrumenting the loop in write_cache_pages clearly shows that we are wasting time here. Eventually we need to change mpage_da_map_pages() also submit its I/O to the block layer, subsuming mpage_da_submit_io(), and then change it call ext4_get_blocks() multiple times. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
-
Eric Sandeen authored
commit a30eec2a upstream (as of v2.6.34-git13) Turn off issuance of discard requests if the device does not support it - similar to the action we take for barriers. This will save a little computation time if a non-discardable device is mounted with -o discard, and also makes it obvious that it's not doing what was asked at mount time ... Signed-off-by:
-
Eric Sandeen authored
commit 6b0310fb upstream (as of v2.6.34-git13) ext4_freeze() used jbd2_journal_lock_updates() which takes the j_barrier mutex, and then returns to userspace. The kernel does not like this: ================================================ [ BUG: lock held when returning to user space! ] ------------------------------------------------ lvcreate/1075 is leaving the kernel with locks still held! 1 lock held by lvcreate/1075: #0: (&journal->j_barrier){+.+...}, at: [<ffffffff811c6214>] jbd2_journal_lock_updates+0xe1/0xf0 Use vfs_check_frozen() added to ext4_journal_start_sb() and ext4_force_commit() instead. Addresses-Red-Hat-Bugzilla: #568503 Signed-off-by:
-
Eric Sandeen authored
commit 42007efd upstream (as of v2.6.34-git13) If groups_per_flex < 2, sbi->s_flex_groups[] doesn't get filled out, and every other access to this first tests s_log_groups_per_flex; same thing needs to happen in resize or we'll wander off into a null pointer when doing an online resize of the file system. Thanks to Christoph Biedl, who came up with the trivial testcase: # truncate --size 128M fsfile # mkfs.ext3 -F fsfile # tune2fs -O extents,uninit_bg,dir_index,flex_bg,huge_file,dir_nlink,extra_isize fsfile # e2fsck -yDf -C0 fsfile # truncate --size 132M fsfile # losetup /dev/loop0 fsfile # mount /dev/loop0 mnt # resize2fs -p /dev/loop0 https://bugzilla.kernel.org/show_bug.cgi?id=13549Reported-by:
Alessandro Polverini <alex@nibbles.it> Test-case-by:
Christoph Biedl <bugzilla.kernel.bpeb@manchmal.in-ulm.de> Signed-off-by:
-
Dmitry Monakhov authored
commit 35121c98 upstream (as of v2.6.34-git13) allocated_meta_data is already included in 'used' variable. Signed-off-by:
-
Christian Borntraeger authored
commit b684b2ee upstream (as of v2.6.34-git13) I have an x86_64 kernel with i386 userspace. e4defrag fails on the EXT4_IOC_MOVE_EXT ioctl because it is not wired up for the compat case. It seems that struct move_extent is compat save, only types with fixed widths are used: { __u32 reserved; /* should be zero */ __u32 donor_fd; /* donor file descriptor */ __u64 orig_start; /* logical start offset in block for orig */ __u64 donor_start; /* logical start offset in block for donor */ __u64 len; /* block length to be moved */ __u64 moved_len; /* moved block length */ }; Lets just wire up EXT4_IOC_MOVE_EXT for the compat case. Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
Jing Zhang authored
commit e39e07fd upstream (as of v2.6.34-git13) This function cleans up after ext4_mb_load_buddy(), so the renaming makes the code clearer. Signed-off-by:
Jing Zhang <zj.barak@gmail.com> Signed-off-by:
-
Jing Zhang authored
commit 62e823a2 upstream (as of v2.6.34-git13) Signed-off-by:
-
Jing Zhang authored
commit b720303d upstream (as of v2.6.34-git13) When EIO occurs after bio is submitted, there is no memory free operation for bio, which results in memory leakage. And there is also no check against bio_alloc() for bio. Acked-by:
Dave Kleikamp <shaggy@linux.vnet.ibm.com> Signed-off-by:
-
Dmitry Monakhov authored
commit 0671e704 upstream (as of v2.6.34-git13) Signed-off-by:
-
Theodore Ts'o authored
commit b90f6870 upstream (as of v2.6.34-rc6) Otherwise, we can end up having data corruption because the blocks could get reused and then discarded! https://bugzilla.kernel.org/show_bug.cgi?id=15579Signed-off-by:
-
Curt Wohlgemuth authored
commit fd2dd9fb upstream (as of v2.6.34-rc6) Calls to ext4_get_inode_loc() returns with a reference to a buffer head in iloc->bh. The callers of this function in ext4_write_inode() when in no journal mode and in ext4_xattr_fiemap() don't release the buffer head after using it. Addresses-Google-Bug: #2548165 Signed-off-by:
-
Curt Wohlgemuth authored
commit 8b472d73 upstream (as of v2.6.34-rc6) In the no-journal case, ext4_write_inode() will fetch the bh and call sync_dirty_buffer() on it. However, if the bh has already been written and the bh reclaimed for some other purpose, AND if the inode is the only one in the inode table block in use, then ext4_get_inode_loc() will not read the inode table block from disk, but as an optimization, fill the block with zero's assuming that its caller will copy in the on-disk version of the inode. This is not done by ext4_write_inode(), so the contents of the inode can simply get lost. The fix is to use __ext4_get_inode_loc() with in_mem set to 0, instead of ext4_get_inode_loc(). Long term the API needs to be fixed so it's obvious why latter is not safe. Addresses-Google-Bug: #2526446 Signed-off-by:
-
Eric Sandeen authored
commit c4caae25 upstream (as of v2.6.34-rc3) When used_dirs was introduced for the flex_groups struct, it looks like the accounting was not put into place properly, in some places manipulating free_inodes rather than used_dirs. Signed-off-by:
-
Jan Kara authored
commit d330a5be upstream (as of v2.6.34-rc3) http://bugzilla.kernel.org/show_bug.cgi?id=15420Signed-off-by:
-
Akira Fujita authored
commit c437b273 upstream (as of v2.6.33-git11) a) Fix sparse warning in ext4_ioctl() b) Remove unneeded variable in mext_leaf_block() c) Fix spelling typo in mext_check_arguments() Signed-off-by:
Akira Fujita <a-fujita@rs.jp.nec.com> Signed-off-by:
-
Akira Fujita authored
commit 7247c0ca upstream (as of v2.6.33-git11) If EXT4_IOC_MOVE_EXT ioctl is called with NULL donor_fd, fget() in ext4_ioctl() gets inappropriate file structure for donor; so we need to do this check earlier, before calling double_down_write_data_sem(). Signed-off-by:
-
Akira Fujita authored
commit 5fd5249a upstream (as of v2.6.33-git11) If the leaf node has 2 extent space or fewer and EXT4_IOC_MOVE_EXT ioctl is called with the file offset where after the 2nd extent covers, mext_insert_across_blocks() always tries to insert extent into the first extent. As a result, the file gets corrupted because of wrong extent order. The patch fixes this problem. Signed-off-by:
-
Toshiyuki Okajima authored
commit b8b8afe2 upstream (as of v2.6.33-git11) The callers of ext4_check_dir_entry() usually pass in the "file offset" (ext4_readdir, htree_dirblock_to_tree, search_dirblock, ext4_dx_find_entry, empty_dir), but a few callers (add_dirent_to_buf, ext4_delete_entry) only pass in the buffer offset. To accomodate those last two (which would be hard to fix otherwise), this patch changes ext4_check_dir_entry() to print the physical block number and the relative offset as well as the passed-in offset. Signed-off-by:
Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com> Signed-off-by:
-
Dmitry Monakhov authored
commit 6e3617e5 upstream (as of v2.6.33-git11) In case of truncate errors we explicitly remove inode from in-core orphan list via orphan_del(NULL, inode) without modifying the on-disk list. But later on, the same inode may be inserted in the orphan list again which will result the on-disk linked list getting corrupted. If inode i_dtime contains valid value, then skip on-disk list modification. Signed-off-by:
-
Dmitry Monakhov authored
commit da1dafca upstream (as of v2.6.33-git11) Otherwise non-empty orphan list will be triggered on umount. Signed-off-by:
-
Dmitry Monakhov authored
commit f39490bc upstream (as of v2.6.33-git11) Set i_nlink to zero for temporary inode from very beginning. otherwise we may fail to start new journal handle and this inode will be unreferenced but with i_nlink == 1 Since we hold inode reference it can not be pruned. Also add missed journal_start retval check. Signed-off-by:
-
Tao Ma authored
commit cc483f10 upstream (as of v2.6.33-git11) The ext4 multiblock allocator decides whether to use group or file preallocation based on the file size. When the file size reaches s_mb_stream_request (default is 16 blocks), it changes to use a file-specific preallocation. This is cool, but it has a tiny problem. See a simple script: mkfs.ext4 -b 1024 /dev/sda8 1000000 mount -t ext4 -o nodelalloc /dev/sda8 /mnt/ext4 for((i=0;i<5;i++)) do cat /mnt/4096>>/mnt/ext4/a #4096 is a file with 4096 characters. cat /mnt/4096>>/mnt/ext4/b done debuge4fs -R 'stat a' /dev/sda8|grep BLOCKS -A 1 And you get BLOCKS: (0-14):8705-8719, (15):2356, (16-19):8465-8468 So there are 3 extents, a bit strange for the lonely 15th logical block. As we write to the 16 blocks, we choose file preallocation in ext4_mb_group_or_file, but in ext4_mb_normalize_request, we meet with the 16*1024 range, so no preallocation will be carried. file b then reserves the space after '2356', so when when write 16, we start from another part. This patch just change the check in ext4_mb_group_or_file, so that for the lonely 15 we will still use group preallocation. After the patch, we will get: debuge4fs -R 'stat a' /dev/sda8|grep BLOCKS -A 1 BLOCKS: (0-15):8705-8720, (16-19):8465-8468 Looks more sane. Thanks. Signed-off-by:
Tao Ma <tao.ma@oracle.com> Signed-off-by:
-
Jiaying Zhang authored
commit c8d46e41 upstream (as of v2.6.33-git11) fallocate() may potentially instantiate blocks past EOF, depending on the flags used when it is called. e2fsck currently has a test for blocks past i_size, and it sometimes trips up - noticeably on xfstests 013 which runs fsstress. This patch from Jiayang does fix it up - it (along with e2fsprogs updates and other patches recently from Aneesh) has survived many fsstress runs in a row. Signed-off-by:
Jiaying Zhang <jiayingz@google.com> Signed-off-by:
-
Curt Wohlgemuth authored
commit 73b50c1c upstream (as of v2.6.33-git11) Calls to ext4_handle_dirty_metadata should only pass in an inode pointer for inode-specific metadata, and not for shared metadata blocks such as inode table blocks, block group descriptors, the superblock, etc. The BUG_ON can get tripped when updating a special device (such as a block device) that is opened (so that i_mapping is set in fs/block_dev.c) and the file system is mounted in no journal mode. Addresses-Google-Bug: #2404870 Signed-off-by:
-
