linux-stable.git/fs/ext4/fast_commit.c, branch v6.14

ext4 fast_commit: make use of name_snapshot primitives

2025-01-28T00:24:43+00:00

... rather than open-coding them.  As a bonus, that avoids the pointless
work with extra allocations, etc. for long names.

Reviewed-by: Jeff Layton 
Reviewed-by: Jan Kara 
Signed-off-by: Al Viro

ext4: cleanup variable name in ext4_fc_del()

2024-11-13T04:54:15+00:00

The variables "&EXT4_SB(inode->i_sb)->s_fc_lock" and "&sbi->s_fc_lock"
are the same lock.  This function uses a mix of both, which is a bit
unsightly and confuses Smatch.

Signed-off-by: Dan Carpenter 
Link: https://patch.msgid.link/96008557-8ff4-44cc-b5e3-ce242212f1a3@stanley.mountain
Signed-off-by: Theodore Ts'o

ext4: simplify if condition

2024-11-13T04:54:13+00:00

The if condition !A || A && B can be simplified to !A || B.

./fs/ext4/fast_commit.c:362:21-23: WARNING !A || A && B is equivalent to !A || B.

Reported-by: Abaci Robot 
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9837
Signed-off-by: Jiapeng Chong 
Reviewed-by: Jan Kara 
Link: https://patch.msgid.link/20240830071713.40565-1-jiapeng.chong@linux.alibaba.com
Signed-off-by: Theodore Ts'o

ext4: use handle to mark fc as ineligible in __track_dentry_update()

2024-10-04T21:35:54+00:00

Calling ext4_fc_mark_ineligible() with a NULL handle is racy and may result
in a fast-commit being done before the filesystem is effectively marked as
ineligible.  This patch fixes the calls to this function in
__track_dentry_update() by adding an extra parameter to the callback used in
ext4_fc_track_template().

Suggested-by: Jan Kara 
Signed-off-by: Luis Henriques (SUSE) 
Reviewed-by: Jan Kara 
Link: https://patch.msgid.link/20240923104909.18342-2-luis.henriques@linux.dev
Signed-off-by: Theodore Ts'o 
Cc: stable@kernel.org

ext4: make some fast commit functions reuse extents path

2024-09-04T02:14:12+00:00

The ext4_find_extent() can update the extent path so that it does not have
to allocate and free the path repeatedly, thus reducing the consumption of
memory allocation and freeing in the following functions:

    ext4_ext_clear_bb
    ext4_ext_replay_set_iblocks
    ext4_fc_replay_add_range
    ext4_fc_set_bitmaps_and_counters

No functional changes. Note that ext4_find_extent() does not support error
pointers, so in this case set path to NULL first.

Signed-off-by: Baokun Li 
Reviewed-by: Jan Kara 
Reviewed-by: Ojaswin Mujoo 
Tested-by: Ojaswin Mujoo 
Link: https://patch.msgid.link/20240822023545.1994557-25-libaokun@huaweicloud.com
Signed-off-by: Theodore Ts'o

ext4: get rid of ppath in ext4_ext_insert_extent()

2024-09-04T02:12:17+00:00

The use of path and ppath is now very confusing, so to make the code more
readable, pass path between functions uniformly, and get rid of ppath.

To get rid of the ppath in ext4_ext_insert_extent(), the following is done
here:

 * Free the extents path when an error is encountered.
 * Its caller needs to update ppath if it uses ppath.
 * Free path when npath is used, free npath when it is not used.
 * The got_allocated_blocks label in ext4_ext_map_blocks() does not
   update err now, so err is updated to 0 if the err returned by
   ext4_ext_search_right() is greater than 0 and is about to enter
   got_allocated_blocks.

No functional changes.

Signed-off-by: Baokun Li 
Reviewed-by: Jan Kara 
Reviewed-by: Ojaswin Mujoo 
Tested-by: Ojaswin Mujoo 
Link: https://patch.msgid.link/20240822023545.1994557-15-libaokun@huaweicloud.com
Signed-off-by: Theodore Ts'o

ext4: fix incorrect tid assumption in ext4_fc_mark_ineligible()

2024-08-27T03:40:00+00:00

Function jbd2_journal_shrink_checkpoint_list() assumes that '0' is not a
valid value for transaction IDs, which is incorrect.

Furthermore, the sbi->s_fc_ineligible_tid handling also makes the same
assumption by being initialised to '0'.  Fortunately, the sb flag
EXT4_MF_FC_INELIGIBLE can be used to check whether sbi->s_fc_ineligible_tid
has been previously set instead of comparing it with '0'.

Signed-off-by: Luis Henriques (SUSE) 
Reviewed-by: Jan Kara 
Link: https://patch.msgid.link/20240724161119.13448-5-luis.henriques@linux.dev
Signed-off-by: Theodore Ts'o 
Cc: stable@kernel.org

ext4: fix fast commit inode enqueueing during a full journal commit

2024-08-27T01:21:10+00:00

When a full journal commit is on-going, any fast commit has to be enqueued
into a different queue: FC_Q_STAGING instead of FC_Q_MAIN.  This enqueueing
is done only once, i.e. if an inode is already queued in a previous fast
commit entry it won't be enqueued again.  However, if a full commit starts
_after_ the inode is enqueued into FC_Q_MAIN, the next fast commit needs to
be done into FC_Q_STAGING.  And this is not being done in function
ext4_fc_track_template().

This patch fixes the issue by re-enqueuing an inode into the STAGING queue
during the fast commit clean-up callback when doing a full commit.  However,
to prevent a race with a fast-commit, the clean-up callback has to be called
with the journal locked.

This bug was found using fstest generic/047.  This test creates several 32k
bytes files, sync'ing each of them after it's creation, and then shutting
down the filesystem.  Some data may be loss in this operation; for example a
file may have it's size truncated to zero.

Suggested-by: Jan Kara 
Signed-off-by: Luis Henriques (SUSE) 
Reviewed-by: Jan Kara 
Link: https://patch.msgid.link/20240717172220.14201-1-luis.henriques@linux.dev
Signed-off-by: Theodore Ts'o 
Cc: stable@kernel.org

ext4: don't track ranges in fast_commit if inode has inlined data

2024-07-09T03:59:37+00:00

When fast-commit needs to track ranges, it has to handle inodes that have
inlined data in a different way because ext4_fc_write_inode_data(), in the
actual commit path, will attempt to map the required blocks for the range.
However, inodes that have inlined data will have it's data stored in
inode->i_block and, eventually, in the extended attribute space.

Unfortunately, because fast commit doesn't currently support extended
attributes, the solution is to mark this commit as ineligible.

Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039883
Signed-off-by: Luis Henriques (SUSE) 
Tested-by: Ben Hutchings 
Fixes: 9725958bb75c ("ext4: fast commit may miss tracking unwritten range during ftruncate")
Link: https://patch.msgid.link/20240618144312.17786-1-luis.henriques@linux.dev
Signed-off-by: Theodore Ts'o

ext4: fix possible tid_t sequence overflows

2024-07-09T03:59:35+00:00

In the fast commit code there are a few places where tid_t variables are
being compared without taking into account the fact that these sequence
numbers may wrap.  Fix this issue by using the helper functions tid_gt()
and tid_geq().

Signed-off-by: Luis Henriques (SUSE) 
Reviewed-by: Jan Kara 
Reviewed-by: Harshad Shirwadkar 
Link: https://patch.msgid.link/20240529092030.9557-3-luis.henriques@linux.dev
Signed-off-by: Theodore Ts'o