- 12 Nov, 2020 8 commits
-
-
Bob Peterson authored
Patch b2a846db ("gfs2: Ignore journal log writes for jdata holes") tried (unsuccessfully) to fix a case in which writes were done to jdata blocks, the blocks are sent to the ail list, then a punch_hole or truncate operation caused the blocks to be freed. In other words, the ail items are for jdata holes. Before b2a846db , the jdata hole caused function gfs2_block_map to return -EIO, which was eventually interpreted as an IO error to the journal, and then withdraw. This patch changes function gfs2_get_block_noalloc, which is only used for jdata writes, so it returns -ENODATA rather than -EIO, and when -ENODATA is returned to gfs2_ail1_start_one, the error is ignored. We can safely ignore it because gfs2_ail1_start_one is only called when the jdata pages have already been written and truncated, so the ail1 content no longer applies. Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com>
-
Bob Peterson authored
This reverts commit b2a846db . That commit changed the behavior of function gfs2_block_map to return -ENODATA in cases where a hole (IOMAP_HOLE) is encountered and create is false. While that fixed the intended problem for jdata, it also broke other callers of gfs2_block_map such as some jdata block reads. Before the patch, an encountered hole would be skipped and the buffer seen as unmapped by the caller. The patch changed the behavior to return -ENODATA, which is interpreted as an error by the caller. The -ENODATA return code should be restricted to the specific case where jdata holes are encountered during ail1 writes. That will be done in a later patch. Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com>
-
Trond Myklebust authored
nfs_inc_stats() is already thread-safe, and there are no other reasons to hold the inode lock here. Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com>
-
Trond Myklebust authored
Remove the contentious inode lock, and instead provide thread safety using the file->f_lock spinlock. Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com>
-
Chuck Lever authored
Certain NFSv4.2/RDMA tests fail with v5.9-rc1. rpcrdma_convert_kvec() runs off the end of the rl_segments array because rq_rcv_buf.tail[0].iov_len holds a very large positive value. The resultant kernel memory corruption is enough to crash the client system. Callers of rpc_prepare_reply_pages() must reserve an extra XDR_UNIT in the maximum decode size for a possible XDR pad of the contents of the xdr_buf's pages. That guarantees the allocated receive buffer will be large enough to accommodate the usual contents plus that XDR pad word. encode_op_hdr() cannot add that extra word. If it does, xdr_inline_pages() underruns the length of the tail iovec. Fixes: 3e1f0212 ("NFSv4.2: add client side XDR handling for extended attributes") Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com>
-
J. Bruce Fields authored
We forgot to unregister the nfs4_xattr_large_entry_shrinker. That leaves the global list of shrinkers corrupted after unload of the nfs module, after which possibly unrelated code that calls register_shrinker() or unregister_shrinker() gets a BUG() with "supervisor write access in kernel mode". And similarly for the nfs4_xattr_large_entry_lru. Reported-by:
Kris Karas <bugs-a17@moonlit-rail.com> Tested-By:
Kris Karas <bugs-a17@moonlit-rail.com> Fixes: 95ad37f9 "NFSv4.2: add client side xattr caching." Signed-off-by:
J. Bruce Fields <bfields@redhat.com> CC: stable@vger.kernel.org Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com>
-
Zhang Qilong authored
In the fail path of gfs2_check_blk_type, forgetting to call gfs2_glock_dq_uninit will result in rgd_gh reference leak. Signed-off-by:
Zhang Qilong <zhangqilong3@huawei.com> Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com>
-
Eric Biggers authored
The new helper function fscrypt_prepare_new_inode() runs before S_ENCRYPTED has been set on the new inode. This accidentally made fscrypt_select_encryption_impl() never enable inline encryption on newly created files, due to its use of fscrypt_needs_contents_encryption() which only returns true when S_ENCRYPTED is set. Fix this by using S_ISREG() directly instead of fscrypt_needs_contents_encryption(), analogous to what select_encryption_mode() does. I didn't notice this earlier because by design, the user-visible behavior is the same (other than performance, potentially) regardless of whether inline encryption is used or not. Fixes: a992b20c ("fscrypt: add fscrypt_prepare_new_inode() and fscrypt_set_context()") Reviewed-by:
Satya Tangirala <satyat@google.com> Link: https://lore.kernel.org/r/20201111015224.303073-1-ebiggers@kernel.org Signed-off-by:
Eric Biggers <ebiggers@google.com>
-
- 11 Nov, 2020 2 commits
-
-
Theodore Ts'o authored
This reverts commit acaa5326 which can result in a ext4_superblock_csum_set() trying to sleep while a spinlock is being held. For more discussion of this issue, please see: https://lore.kernel.org/r/000000000000f50cb705b313ed70@google.com Reported-by: syzbot+7a4ba6a239b91a126c28@syzkaller.appspotmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
Mount options dax=inode and dax=never collided with fast_commit and journal checksum. Redefine the mount flags to remove the collision. Reported-by:
Murphy Zhou <jencce.kernel@gmail.com> Fixes: 9cb20f94 ("fs/ext4: Make DAX mount option a tri-state") Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201111183209.447175-1-harshads@google.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
- 07 Nov, 2020 26 commits
-
-
Theodore Ts'o authored
Add missing __acquires() and __releases() annotations. Also, in an "this should never happen" WARN_ON check, if it *does* actually happen, we need to release j_state_lock since this function is always supposed to release that lock. Otherwise, things will quickly grind to a halt after the WARN_ON trips. Fixes: 96f1e097 ("jbd2: avoid long hold times of j_state_lock...") Cc: stable@kernel.org Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Theodore Ts'o authored
Add missing __acquire() and __releases() annotations, and make fc_ineligible_reasons[] static, as it is not used outside of fs/ext4/fast_commit.c. Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
Drop no_fc mount option that disable fast commit even if it was enabled at mkfs time. Move fc_debug_force mount option under ifdef EXT4_DEBUG to annotate that this is strictly for debugging and testing purposes and should not be used in production. Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-23-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
Fast commit should not be started if the journal is aborted. Signed-off-by: Harshad Shirwadkar<harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-22-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
Fast commit file system states are recorded in sbi->s_mount_flags. Fast commit expects these bit manipulations to be atomic. This patch adds helpers to make those modifications atomic. Suggested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-21-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
If the journal dev is different from fsdev, issue a cache flush before committing fast commit blocks to disk. Suggested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Reviewed-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20201106035911.1942128-20-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
Fast commits don't work with data journalling. This patch disables the fast commit support when data journalling is turned on. Suggested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Reviewed-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20201106035911.1942128-19-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
In case of fast commits, determine if the inode is dirty by checking if the inode is on fast commit list. This also helps us get rid of ext4_inode_info.i_fc_committed_subtid field. Reported-by:
Andrea Righi <andrea.righi@canonical.com> Tested-by:
Andrea Righi <andrea.righi@canonical.com> Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-18-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
Remove unnecessary calls to ext4_fc_start_update() and ext4_fc_stop_update() from ext4_file_mmap(). Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-17-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
Mark the fast commit buffer as dirty before submission. Suggested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-16-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
Add a TODO to remember fixing REQ_FUA | REQ_PREFLUSH for fast commit buffers. Also, fix a typo in top level comment in fast_commit.c Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-15-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
This patch removes the deduplicates the code that implements waiting on inode that's being committed. That code is moved into a new function. Suggested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-14-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
Take journal state lock before reading journal->j_commit_sequence. Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-13-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
Fast commit buffers should be filled in before toucing their state. Remove code that sets buffer state as dirty before the buffer is passed to the file system. Suggested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-12-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
Fast commit performance can be optimized if commit thread doesn't wait for ongoing fast commits to complete until the transaction enters T_FLUSH state. Document this optimization. Suggested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-11-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
In jbd2_fc_end_commit_fallback(), we know which tid to commit. There's no need for caller to pass it. Suggested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-10-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
Variables journal->j_fc_off, journal->j_fc_wbuf are accessed during commit path. Since today we allow only one process to perform a fast commit, there is no need take state lock before accessing these variables. This patch removes these locks and adds comments to describe this. Suggested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-9-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
This patch removes jbd2_fc_init() API and its related functions to simplify enabling fast commits. With this change, the number of fast commit blocks to use is solely determined by the JBD2 layer. So, we move the default value for minimum number of fast commit blocks from ext4/fast_commit.h to include/linux/jbd2.h. However, whether or not to use fast commits is determined by the file system. The file system just sets the fast commit feature using jbd2_journal_set_features(). JBD2 layer then determines how many blocks to use for fast commits (based on the value found in the JBD2 superblock). Note that the JBD2 feature flag of fast commits is just an indication that there are fast commit blocks present on disk. It doesn't tell JBD2 layer about the intent of the file system of whether to it wants to use fast commit or not. That's why, we blindly clear the fast commit flag in journal_reset() after the recovery is done. Suggested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-7-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
The on-disk superblock field sb->s_maxlen represents the total size of the journal including the fast commit area and is no more the max number of blocks available for a transaction. The maximum number of blocks available to a transaction is reduced by the number of fast commit blocks. So, this patch renames j_maxlen to j_total_len to better represent its intent. Also, it adds a function to calculate max number of bufs available for a transaction. Suggested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-6-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
Firstly, pass handle to all ext4_fc_track_* functions and use transaction id found in handle->h_transaction->h_tid for tracking fast commit updates. Secondly, don't pass inode to ext4_fc_track_link/create/unlink functions. inode can be found inside these functions as d_inode(dentry). However, rename path is an exeception. That's because in that case, we need inode that's not same as d_inode(dentry). To handle that, add a couple of low-level wrapper functions that take inode and dentry as arguments. Suggested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-5-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
ext4_fc_track_range() should only be called when blocks are added or removed from an inode. So, the only places from where we need to call this function are ext4_map_blocks(), punch hole, collapse / zero range, truncate. Remove all the other redundant calls to ths function. Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-4-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
If inode gets evicted due to memory pressure, we have to remove it from the fast commit list. However, that inode may have uncommitted changes that fast commits will lose. So, just fall back to full commits in this case. Also, rename the fast commit ineligiblity reason from "EXT4_FC_REASON_MEM" to "EXT4_FC_REASON_MEM_NOMEM" for better expression. Suggested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20201106035911.1942128-3-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Harshad Shirwadkar authored
Fast commit feature has flags in the file system as well in JBD2. The meaning of fast commit feature flags can get confusing. Update docs and code to add more documentation about it. Suggested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Reviewed-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20201106035911.1942128-2-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Joseph Qi authored
It takes xattr_sem to check inline data again but without unlock it in case not have. So unlock it before return. Fixes: aef1c851 ("ext4: let ext4_truncate handle inline data correctly") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Tao Ma <boyu.mt@taobao.com> Signed-off-by:
Joseph Qi <joseph.qi@linux.alibaba.com> Reviewed-by:
Andreas Dilger <adilger@dilger.ca> Link: https://lore.kernel.org/r/1604370542-124630-1-git-send-email-joseph.qi@linux.alibaba.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org
-
Dan Carpenter authored
Smatch complains that "i" can be uninitialized if we don't enter the loop. I don't know if it's possible but we may as well silence this warning. [ Initialize i to sb->s_blocksize instead of 0. The only way the for loop could be skipped entirely is the in-memory data structures, in particular the bh->b_data for the on-disk superblock has gotten corrupted enough that calculated value of group is >= to ext4_get_groups_count(sb). In that case, we want to exit immediately without allocating a block. -- TYT ] Fixes: 8016e29f ("ext4: fast commit recovery path") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20201030114620.GB3251003@mwanda Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org
-
Kaixu Xia authored
The macro MOPT_Q is used to indicates the mount option is related to quota stuff and is defined to be MOPT_NOSUPPORT when CONFIG_QUOTA is disabled. Normally the quota options are handled explicitly, so it didn't matter that the MOPT_STRING flag was missing, even though the usrjquota and grpjquota mount options take a string argument. It's important that's present in the !CONFIG_QUOTA case, since without MOPT_STRING, the mount option matcher will match usrjquota= followed by an integer, and will otherwise skip the table entry, and so "mount option not supported" error message is never reported. [ Fixed up the commit description to better explain why the fix works. --TYT ] Fixes: 26092bf5 ("ext4: use a table-driven handler for mount options") Signed-off-by:
Kaixu Xia <kaixuxia@tencent.com> Link: https://lore.kernel.org/r/1603986396-28917-1-git-send-email-kaixuxia@tencent.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org
-
- 06 Nov, 2020 4 commits
-
-
Christoph Hellwig authored
Implement ->read_iter for all proc "seq files" so that splice works on them. Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Greg Kroah-Hartman authored
Implement ->read_iter for all proc "single files" so that more bionic tests cases can pass when they call splice() on other fun files like /proc/version Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Christoph Hellwig authored
Implement ->read_iter so that splice can be used on this file. Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Christoph Hellwig authored
Implement ->read_iter so that the Android bionic test suite can use this random proc file for its splice test case. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-