| Message ID | 20240415152057.4605-1-cel@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Fix shmem_rename2 directory offset calculation | expand |
On Mon, Apr 15, 2024 at 11:20:53AM -0400, cel@kernel.org wrote: > From: Chuck Lever <chuck.lever@oracle.com> > > The existing code in shmem_rename2() allocates a fresh directory > offset value when renaming over an existing destination entry. User > space does not expect this behavior. In particular, applications > that rename while walking a directory can loop indefinitely because > they never reach the end of the directory. > > The only test that is problematic at the moment is generic/449, > which live-locks (interruptibly). I don't have a baseline yet, so > I can't say whether the fix introduces this behavior or pre-dates > the shmem conversion to simple_offset. v6.5 exhibits the same behavior, so this fix did not introduce this issue. IMO these patches are ready. > -- > Changes since v1: > - Patches reorganized for easier review and backport > - Passes git regression and fstests (with scratch device) > - Dropped the API clean-up patch for now > > Chuck Lever (3): > libfs: Fix simple_offset_rename_exchange() > libfs: Add simple_offset_rename() API > shmem: Fix shmem_rename2() > > fs/libfs.c | 55 +++++++++++++++++++++++++++++++++++++++++----- > include/linux/fs.h | 2 ++ > mm/shmem.c | 3 +-- > 3 files changed, 52 insertions(+), 8 deletions(-) > > > base-commit: fec50db7033ea478773b159e0e2efb135270e3b7 > -- > 2.44.0
On Mon, 15 Apr 2024 11:20:53 -0400, cel@kernel.org wrote: > From: Chuck Lever <chuck.lever@oracle.com> > > The existing code in shmem_rename2() allocates a fresh directory > offset value when renaming over an existing destination entry. User > space does not expect this behavior. In particular, applications > that rename while walking a directory can loop indefinitely because > they never reach the end of the directory. > > [...] Thanks for fixing this! --- Applied to the vfs.misc branch of the vfs/vfs.git tree. Patches in the vfs.misc branch should appear in linux-next soon. Please report any outstanding bugs that were missed during review in a new review to the original patch series allowing us to drop it. It's encouraged to provide Acked-bys and Reviewed-bys even though the patch has now been applied. If possible patch trailers will be updated. Note that commit hashes shown below are subject to change due to rebase, trailer updates or similar. If in doubt, please check the listed branch. tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git branch: vfs.misc [1/3] libfs: Fix simple_offset_rename_exchange() https://git.kernel.org/vfs/vfs/c/23cdd0eed3f1 [2/3] libfs: Add simple_offset_rename() API https://git.kernel.org/vfs/vfs/c/5a1a25be995e [3/3] shmem: Fix shmem_rename2() https://git.kernel.org/vfs/vfs/c/ad191eb6d694
From: Chuck Lever <chuck.lever@oracle.com> The existing code in shmem_rename2() allocates a fresh directory offset value when renaming over an existing destination entry. User space does not expect this behavior. In particular, applications that rename while walking a directory can loop indefinitely because they never reach the end of the directory. The only test that is problematic at the moment is generic/449, which live-locks (interruptibly). I don't have a baseline yet, so I can't say whether the fix introduces this behavior or pre-dates the shmem conversion to simple_offset. -- Changes since v1: - Patches reorganized for easier review and backport - Passes git regression and fstests (with scratch device) - Dropped the API clean-up patch for now Chuck Lever (3): libfs: Fix simple_offset_rename_exchange() libfs: Add simple_offset_rename() API shmem: Fix shmem_rename2() fs/libfs.c | 55 +++++++++++++++++++++++++++++++++++++++++----- include/linux/fs.h | 2 ++ mm/shmem.c | 3 +-- 3 files changed, 52 insertions(+), 8 deletions(-) base-commit: fec50db7033ea478773b159e0e2efb135270e3b7