- 09 Jun, 2014 2 commits
-
-
Dave Chinner authored
-
Dave Chinner authored
The kbuild test robot reported: >> fs/xfs/xfs_dir2_readdir.c:672:41: sparse: Using plain integer as NULL pointer Fix it. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Brian Foster <bfoster@redhat.com> Signed-off-by:
Dave Chinner <david@fromorbit.com>
-
- 06 Jun, 2014 17 commits
-
-
Dave Chinner authored
It's carried in state->args->geo, so there's no need to duplicate it and use more stack space than necessary. Signed-off-by:
-
Dave Chinner authored
Signed-off-by:
-
Dave Chinner authored
As it's only ever called from contexts where the xfs_da_args is present and contains all the information needed inside the args structure. Signed-off-by:
-
Dave Chinner authored
Rather than using the superblock value obtained through the xfs_mount. Signed-off-by:
-
Dave Chinner authored
We don't pass the xfs_da_args or the geometry all the way down to the directory buffer logging code, hence we have to use mp->m_dir_geo here. Fix this to use the geometry passed via the xfs_da_args, and convert all the directory logging functions for consistency. Signed-off-by:
-
Dave Chinner authored
There are many places in the directory code were we don't pass the args into and so have to extract the geometry direct from the mount structure. Push the args or the geometry into these leaf functions so that we don't need to grab it from the struct xfs_mount. This, in turn, brings use to the point where directory geometry is no longer a property of the struct xfs_mount; it is not a global property anymore, and hence we can start to consider per-directory configuration of physical geometries. Start by converting the xfs_dir_isblock/leaf code - pass in the xfs_da_args and convert the readdir code to use xfs_da_args like the rest of the directory code to pass information around. Signed-off-by:
-
Dave Chinner authored
Signed-off-by:
-
Dave Chinner authored
Signed-off-by:
-
Dave Chinner authored
Signed-off-by:
-
Dave Chinner authored
Signed-off-by:
-
Dave Chinner authored
Signed-off-by:
-
Dave Chinner authored
Signed-off-by:
-
Dave Chinner authored
Signed-off-by:
-
Dave Chinner authored
Signed-off-by:
-
Dave Chinner authored
They are just simple wrappers around xfs_dir2_byte_to_db(), and we've already removed one usage earlier in the patch set. Kill the rest before we start removing the xfs_mount from conversion functions. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Dave Chinner authored
Because they aren't actually part of the on-disk format, and so shouldn't be in xfs_da_format.h. Signed-off-by:
-
Dave Chinner authored
The directory code has a dependency on the struct xfs_mount to supply the directory block geometry. Block size, block log size, and other parameters are pre-caclulated in the struct xfs_mount or access directly from the superblock embedded in the struct xfs_mount. Extract all of this geometry information out of the struct xfs_mount and superblock and place it into a new struct xfs_da_geometry defined by the directory code. Allocate and initialise it at mount time, and attach it to the struct xfs_mount so it canbe passed back into the directory code appropriately rather than using the struct xfs_mount. Signed-off-by:
-
- 19 May, 2014 12 commits
-
-
Dave Chinner authored
Conflicts: fs/xfs/xfs_inode.c
-
Dave Chinner authored
Conflicts: fs/xfs/xfs_ialloc.c
-
Roger Willcocks authored
xfs_ialloc.h:102: error: expected ',' or '...' before 'delete' Simple parameter rename, no changes to behaviour. Signed-off-by:
Roger Willcocks <roger@filmlight.ltd.uk> Reviewed-by:
-
Jie Liu authored
Write to a file with an offset greater than 16TB on 32-bit system and then trigger page write-back via sync(1) will cause task hang. # block_size=4096 # offset=$(((2**32 - 1) * $block_size)) # xfs_io -f -c "pwrite $offset $block_size" /storage/test_file # sync INFO: task sync:2590 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. sync D c1064a28 0 2590 2097 0x00000000 ..... Call Trace: [<c1064a28>] ? ttwu_do_wakeup+0x18/0x130 [<c1066d0e>] ? try_to_wake_up+0x1ce/0x220 [<c1066dbf>] ? wake_up_process+0x1f/0x40 [<c104fc2e>] ? wake_up_worker+0x1e/0x30 [<c15b6083>] schedule+0x23/0x60 [<c15b3c2d>] schedule_timeout+0x18d/0x1f0 [<c12a143e>] ? do_raw_spin_unlock+0x4e/0x90 [<c10515f1>] ? __queue_delayed_work+0x91/0x150 [<c12a12ef>] ? do_raw_spin_lock+0x3f/0x100 [<c12a143e>] ? do_raw_spin_unlock+0x4e/0x90 [<c15b5b5d>] wait_for_completion+0x7d/0xc0 [<c1066d60>] ? try_to_wake_up+0x220/0x220 [<c116a4d2>] sync_inodes_sb+0x92/0x180 [<c116fb05>] sync_inodes_one_sb+0x15/0x20 [<c114a8f8>] iterate_supers+0xb8/0xc0 [<c116faf0>] ? fdatawrite_one_bdev+0x20/0x20 [<c116fc21>] sys_sync+0x31/0x80 [<c15be18d>] sysenter_do_call+0x12/0x28 This issue can be triggered via xfstests/generic/308. The reason is that the end_index is unsigned long with maximum value '2^32-1=4294967295' on 32-bit platform, and the given offset cause it wrapped to 0, so that the following codes will repeat again and again until the task schedule time out: end_index = offset >> PAGE_CACHE_SHIFT; last_index = (offset - 1) >> PAGE_CACHE_SHIFT; if (page->index >= end_index) { unsigned offset_into_page = offset & (PAGE_CACHE_SIZE - 1); /* * Just skip the page if it is fully outside i_size, e.g. due * to a truncate operation that is in progress. */ if (page->index >= end_index + 1 || offset_into_page == 0) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unlock_page(page); return 0; } In order to check if a page is fully outsids i_size or not, we can fix the code logic as below: if (page->index > end_index || (page->index == end_index && offset_into_page == 0)) Secondly, there still has another similar issue when calculating the end offset for mapping the filesystem blocks to the file blocks for delalloc. With the same tests to above, run unmount(8) will cause kernel panic if CONFIG_XFS_DEBUG is enabled: XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || \ ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 964 kernel BUG at fs/xfs/xfs_message.c:108! invalid opcode: 0000 [#1] SMP task: edddc100 ti: ec6ee000 task.ti: ec6ee000 EIP: 0060:[<f83d87cb>] EFLAGS: 00010296 CPU: 1 EIP is at assfail+0x2b/0x30 [xfs] .............. Call Trace: [<f83d9cd4>] xfs_fs_destroy_inode+0x74/0x120 [xfs] [<c115ddf1>] destroy_inode+0x31/0x50 [<c115deff>] evict+0xef/0x170 [<c115dfb2>] dispose_list+0x32/0x40 [<c115ea3a>] evict_inodes+0xca/0xe0 [<c1149706>] generic_shutdown_super+0x46/0xd0 [<c11497b9>] kill_block_super+0x29/0x70 [<c1149a14>] deactivate_locked_super+0x44/0x70 [<c114a427>] deactivate_super+0x47/0x60 [<c1161c3d>] mntput_no_expire+0xcd/0x120 [<c1162ae8>] SyS_umount+0xa8/0x370 [<c1162dce>] SyS_oldumount+0x1e/0x20 [<c15be18d>] sysenter_do_call+0x12/0x28 That because the end_offset is evaluated to 0 which is the same reason to above, hence the mapping and covertion for dealloc file blocks to file system blocks did not happened. This patch just fixed both issues. Reported-by:Michael L. Semon <mlsemon35@gmail.com> Signed-off-by:
Jie Liu <jeff.liu@oracle.com> Reviewed-by:
-
Dave Chinner authored
All of the verification checks of magic numbers are now done by verifiers, so ther eis no need to check them again once the buffer has been successfully read. If the magic number is bad, it won't even get to that code to verify it so it really serves no purpose at all anymore. Remove it. Signed-off-by:
-
Dave Chinner authored
The addition of direct formatting of log items into the CIL linear buffer added alignment restrictions that the start of each vector needed to be 64 bit aligned. Hence padding was added in xlog_finish_iovec() to round up the vector length to ensure the next vector started with the correct alignment. This adds a small number of bytes to the size of the linear buffer that is otherwise unused. The issue is that we then use the linear buffer size to determine the log space used by the log item, and this includes the unused space. Hence when we account for space used by the log item, it's more than is actually written into the iclogs, and hence we slowly leak this space. This results on log hangs when reserving space, with threads getting stuck with these stack traces: Call Trace: [<ffffffff81d15989>] schedule+0x29/0x70 [<ffffffff8150d3a2>] xlog_grant_head_wait+0xa2/0x1a0 [<ffffffff8150d55d>] xlog_grant_head_check+0xbd/0x140 [<ffffffff8150ee33>] xfs_log_reserve+0x103/0x220 [<ffffffff814b7f05>] xfs_trans_reserve+0x2f5/0x310 ..... The 4 bytes is significant. Brain Foster did all the hard work in tracking down a reproducable leak to inode chunk allocation (it went away with the ikeep mount option). His rough numbers were that creating 50,000 inodes leaked 11 log blocks. This turns out to be roughly 800 inode chunks or 1600 inode cluster buffers. That works out at roughly 4 bytes per cluster buffer logged, and at that I started looking for a 4 byte leak in the buffer logging code. What I found was that a struct xfs_buf_log_format structure for an inode cluster buffer is 28 bytes in length. This gets rounded up to 32 bytes, but the vector length remains 28 bytes. Hence the CIL ticket reservation is decremented by 32 bytes (via lv->lv_buf_len) for that vector rather than 28 bytes which are written into the log. The fix for this problem is to separately track the bytes used by the log vectors in the item and use that instead of the buffer length when accounting for the log space that will be used by the formatted log item. Again, thanks to Brian Foster for doing all the hard work and long hours to isolate this leak and make finding the bug relatively simple. Signed-off-by:
-
Namjae Jeon authored
There is no need to dip into reserve pool. Reserve pool is used for much more important things. And xfs_trans_reserve will never return ENOSPC because punch hole is already done. If we get ENOSPC, collapse range will be simply failed. Cc: Brian Foster <bfoster@redhat.com> Signed-off-by:
Namjae Jeon <namjae.jeon@samsung.com> Signed-off-by:
Ashish Sangwan <a.sangwan@samsung.com> Reviewed-by:
-
Dave Chinner authored
We reject any filesystem that is mounted with this feature bit set, so we don't need to check for it anywhere else. Remove the function for checking if the feature bit is set and any code that uses it. Signed-off-by:
-
Dave Chinner authored
If the the V2 directory feature bit is not set in the superblock feature mask the filesystem will fail the good version check. Hence we don't need any other version checking on the dir2 feature bit in the code as the filesystem will not mount without it set. Remove the checking code. Signed-off-by:
-
Dave Chinner authored
mkfs has turned on the XFS_SB_VERSION_NLINKBIT feature bit by default since November 2007. It's about time we simply made the kernel code turn it on by default and so always convert v1 inodes to v2 inodes when reading them in from disk or allocating them. This This removes needless version checks and modification when bumping link counts on inodes, and will take code out of a few common code paths. text data bss dec hex filename 783251 100867 616 884734 d7ffe fs/xfs/xfs.o.orig 782664 100867 616 884147 d7db3 fs/xfs/xfs.o.patched Signed-off-by:
-
Dave Chinner authored
Whenever we update sb_features2, we need to update sb_bad_features2 so that they remain identical on disk. This prevents future mounts or userspace utilities from getting confused over which features the filesystem supports. Signed-off-by:
-
Dave Chinner authored
We only support filesystems that have v2 directory support, and than means all the checking and handling of superblock versions prior to this support being added is completely unnecessary overhead. Strip out all the version 1-3 support, sanitise the good version checking to reflect the supported versions, update all the feature supported functions and clean up all the support bit definitions to reflect the fact that we no longer care about Irix bootloader flag regions for v4 feature bits. Also, convert the return values to boolean types and remove typedefs from function declarations to clean up calling conventions, too. Because the feature bit checking is all inline code, this relatively small cleanup has a noticable impact on code size: text data bss dec hex filename 785195 100867 616 886678 d8796 fs/xfs/xfs.o.orig 783595 100867 616 885078 d8156 fs/xfs/xfs.o.patched i.e. it reduces it by 1600 bytes. Signed-off-by:
-
- 14 May, 2014 9 commits
-
-
Dave Chinner authored
Conflicts: fs/xfs/xfs_attr.c
-
Dave Chinner authored
-
Dave Chinner authored
-
Dave Chinner authored
-
Dave Chinner authored
-
Dave Chinner authored
And we don't invert it properly when initialising the dquot lru list. Signed-off-by:
-
Dave Chinner authored
Signed-off-by:
-
Dave Chinner authored
Signed-off-by:
-
Dave Chinner authored
Signed-off-by:
-
