Skip to content

Commit 951cafa

Browse files
jankaratytso
authored andcommitted
ext4: Simplify handling of journalled data in ext4_bmap()
Now that ext4_writepages() gets journalled data into its final location we just use filemap_write_and_wait() instead of special handling of journalled data in ext4_bmap(). We can also drop EXT4_STATE_JDATA flag as it is not used anymore. Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230329154950.19720-11-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
1 parent 7c37587 commit 951cafa

2 files changed

Lines changed: 5 additions & 40 deletions

File tree

fs/ext4/ext4.h

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1886,7 +1886,6 @@ static inline void ext4_simulate_fail_bh(struct super_block *sb,
18861886
* Inode dynamic state flags
18871887
*/
18881888
enum {
1889-
EXT4_STATE_JDATA, /* journaled data exists */
18901889
EXT4_STATE_NEW, /* inode is newly created */
18911890
EXT4_STATE_XATTR, /* has in-inode xattrs */
18921891
EXT4_STATE_NO_EXPAND, /* No space for expansion */

fs/ext4/inode.c

Lines changed: 5 additions & 39 deletions
Original file line numberDiff line numberDiff line change
@@ -1414,7 +1414,6 @@ static int ext4_journalled_write_end(struct file *file,
14141414
}
14151415
if (!verity)
14161416
size_changed = ext4_update_inode_size(inode, pos + copied);
1417-
ext4_set_inode_state(inode, EXT4_STATE_JDATA);
14181417
EXT4_I(inode)->i_datasync_tid = handle->h_transaction->t_tid;
14191418
folio_unlock(folio);
14201419
folio_put(folio);
@@ -2340,8 +2339,6 @@ static int ext4_journal_page_buffers(handle_t *handle, struct page *page,
23402339
ret = err;
23412340
EXT4_I(inode)->i_datasync_tid = handle->h_transaction->t_tid;
23422341

2343-
ext4_set_inode_state(inode, EXT4_STATE_JDATA);
2344-
23452342
return ret;
23462343
}
23472344

@@ -3085,9 +3082,7 @@ int ext4_alloc_da_blocks(struct inode *inode)
30853082
static sector_t ext4_bmap(struct address_space *mapping, sector_t block)
30863083
{
30873084
struct inode *inode = mapping->host;
3088-
journal_t *journal;
30893085
sector_t ret = 0;
3090-
int err;
30913086

30923087
inode_lock_shared(inode);
30933088
/*
@@ -3097,45 +3092,16 @@ static sector_t ext4_bmap(struct address_space *mapping, sector_t block)
30973092
goto out;
30983093

30993094
if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY) &&
3100-
test_opt(inode->i_sb, DELALLOC)) {
3095+
(test_opt(inode->i_sb, DELALLOC) ||
3096+
ext4_should_journal_data(inode))) {
31013097
/*
3102-
* With delalloc we want to sync the file
3103-
* so that we can make sure we allocate
3104-
* blocks for file
3098+
* With delalloc or journalled data we want to sync the file so
3099+
* that we can make sure we allocate blocks for file and data
3100+
* is in place for the user to see it
31053101
*/
31063102
filemap_write_and_wait(mapping);
31073103
}
31083104

3109-
if (EXT4_JOURNAL(inode) &&
3110-
ext4_test_inode_state(inode, EXT4_STATE_JDATA)) {
3111-
/*
3112-
* This is a REALLY heavyweight approach, but the use of
3113-
* bmap on dirty files is expected to be extremely rare:
3114-
* only if we run lilo or swapon on a freshly made file
3115-
* do we expect this to happen.
3116-
*
3117-
* (bmap requires CAP_SYS_RAWIO so this does not
3118-
* represent an unprivileged user DOS attack --- we'd be
3119-
* in trouble if mortal users could trigger this path at
3120-
* will.)
3121-
*
3122-
* NB. EXT4_STATE_JDATA is not set on files other than
3123-
* regular files. If somebody wants to bmap a directory
3124-
* or symlink and gets confused because the buffer
3125-
* hasn't yet been flushed to disk, they deserve
3126-
* everything they get.
3127-
*/
3128-
3129-
ext4_clear_inode_state(inode, EXT4_STATE_JDATA);
3130-
journal = EXT4_JOURNAL(inode);
3131-
jbd2_journal_lock_updates(journal);
3132-
err = jbd2_journal_flush(journal, 0);
3133-
jbd2_journal_unlock_updates(journal);
3134-
3135-
if (err)
3136-
goto out;
3137-
}
3138-
31393105
ret = iomap_bmap(mapping, block, &ext4_iomap_ops);
31403106

31413107
out:

0 commit comments

Comments
 (0)