Commit e5008e01 authored by Dave Chinner's avatar Dave Chinner Committed by Long Li
Browse files

xfs: reorder iunlink remove operation in xfs_ifree

stable inclusion
from stable-v5.10.145
commit a6bfdc157f853004c47e93357303f3626afaa872
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=tags/v5.10.146&id=a6bfdc157f853004c47e93357303f3626afaa872



--------------------------------

commit 9a5280b3 upstream.

[backport for 5.10.y]

The O_TMPFILE creation implementation creates a specific order of
operations for inode allocation/freeing and unlinked list
modification. Currently both are serialised by the AGI, so the order
doesn't strictly matter as long as the are both in the same
transaction.

However, if we want to move the unlinked list insertions largely out
from under the AGI lock, then we have to be concerned about the
order in which we do unlinked list modification operations.
O_TMPFILE creation tells us this order is inode allocation/free,
then unlinked list modification.

Change xfs_ifree() to use this same ordering on unlinked list
removal. This way we always guarantee that when we enter the
iunlinked list removal code from this path, we already have the AGI
locked and we don't have to worry about lock nesting AGI reads
inside unlink list locks because it's already locked and attached to
the transaction.

We can do this safely as the inode freeing and unlinked list removal
are done in the same transaction and hence are atomic operations
with respect to log recovery.

Reported-by: default avatarFrank Hofmann <fhofmann@cloudflare.com>
Fixes: 298f7bec ("xfs: pin inode backing buffer to the inode log item")
Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
Acked-by: default avatarDarrick J. Wong <djwong@kernel.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: default avatarLong Li <leo.lilong@huawei.com>
parent f45e867e
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment