From: Chuck Lever chuck.lever@oracle.com
This series backports several upstream fixes to origin/linux-6.6.y in order to address CVE-2024-46701:
https://nvd.nist.gov/vuln/detail/CVE-2024-46701
As applied to origin/linux-6.6.y, this series passes fstests and the git regression suite.
Before officially requesting that stable@ merge this series, I'd like to provide an opportunity for community review of the backport patches.
You can also find them them in the "nfsd-6.6.y" branch in
https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
Chuck Lever (10): libfs: Re-arrange locking in offset_iterate_dir() libfs: Define a minimum directory offset libfs: Add simple_offset_empty() libfs: Fix simple_offset_rename_exchange() libfs: Add simple_offset_rename() API shmem: Fix shmem_rename2() libfs: Return ENOSPC when the directory offset range is exhausted Revert "libfs: Add simple_offset_empty()" libfs: Replace simple_offset end-of-directory detection libfs: Use d_children list to iterate simple_offset directories
fs/libfs.c | 177 +++++++++++++++++++++++++++++++++------------ include/linux/fs.h | 2 + mm/shmem.c | 3 +- 3 files changed, 134 insertions(+), 48 deletions(-)
From: Chuck Lever chuck.lever@oracle.com
[ Upstream commit 3f6d810665dfde0d33785420618ceb03fba0619d ]
Liam and Matthew say that once the RCU read lock is released, xa_state is not safe to re-use for the next xas_find() call. But the RCU read lock must be released on each loop iteration so that dput(), which might_sleep(), can be called safely.
Thus we are forced to walk the offset tree with fresh state for each directory entry. xa_find() can do this for us, though it might be a little less efficient than maintaining xa_state locally.
We believe that in the current code base, inode->i_rwsem provides protection for the xa_state maintained in offset_iterate_dir(). However, there is no guarantee that will continue to be the case in the future.
Since offset_iterate_dir() doesn't build xa_state locally any more, there's no longer a strong need for offset_find_next(). Clean up by rolling these two helpers together.
Suggested-by: Liam R. Howlett Liam.Howlett@Oracle.com Message-ID: 170785993027.11135.8830043889278631735.stgit@91.116.238.104.host.secureserver.net Signed-off-by: Chuck Lever chuck.lever@oracle.com Link: https://lore.kernel.org/r/170820142021.6328.15047865406275957018.stgit@91.11... Reviewed-by: Jan Kara jack@suse.cz Signed-off-by: Christian Brauner brauner@kernel.org Signed-off-by: Chuck Lever chuck.lever@oracle.com --- fs/libfs.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/libfs.c b/fs/libfs.c index dc0f7519045f..430f7c95336c 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -401,12 +401,13 @@ static loff_t offset_dir_llseek(struct file *file, loff_t offset, int whence) return vfs_setpos(file, offset, U32_MAX); }
-static struct dentry *offset_find_next(struct xa_state *xas) +static struct dentry *offset_find_next(struct offset_ctx *octx, loff_t offset) { struct dentry *child, *found = NULL; + XA_STATE(xas, &octx->xa, offset);
rcu_read_lock(); - child = xas_next_entry(xas, U32_MAX); + child = xas_next_entry(&xas, U32_MAX); if (!child) goto out; spin_lock(&child->d_lock); @@ -429,12 +430,11 @@ static bool offset_dir_emit(struct dir_context *ctx, struct dentry *dentry)
static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx) { - struct offset_ctx *so_ctx = inode->i_op->get_offset_ctx(inode); - XA_STATE(xas, &so_ctx->xa, ctx->pos); + struct offset_ctx *octx = inode->i_op->get_offset_ctx(inode); struct dentry *dentry;
while (true) { - dentry = offset_find_next(&xas); + dentry = offset_find_next(octx, ctx->pos); if (!dentry) return ERR_PTR(-ENOENT);
@@ -443,8 +443,8 @@ static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx) break; }
+ ctx->pos = dentry2offset(dentry) + 1; dput(dentry); - ctx->pos = xas.xa_index + 1; } return NULL; }
From: Chuck Lever chuck.lever@oracle.com
[ Upstream commit 7beea725a8ca412c6190090ce7c3a13b169592a1 ]
This value is used in several places, so make it a symbolic constant.
Reviewed-by: Jan Kara jack@suse.cz Signed-off-by: Chuck Lever chuck.lever@oracle.com Link: https://lore.kernel.org/r/170820142741.6328.12428356024575347885.stgit@91.11... Signed-off-by: Christian Brauner brauner@kernel.org Stable-dep-of: ecba88a3b32d ("libfs: Add simple_offset_empty()") Signed-off-by: Chuck Lever chuck.lever@oracle.com --- fs/libfs.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/fs/libfs.c b/fs/libfs.c index 430f7c95336c..c3dc58e776f9 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -239,6 +239,11 @@ const struct inode_operations simple_dir_inode_operations = { }; EXPORT_SYMBOL(simple_dir_inode_operations);
+/* 0 is '.', 1 is '..', so always start with offset 2 or more */ +enum { + DIR_OFFSET_MIN = 2, +}; + static void offset_set(struct dentry *dentry, u32 offset) { dentry->d_fsdata = (void *)((uintptr_t)(offset)); @@ -260,9 +265,7 @@ void simple_offset_init(struct offset_ctx *octx) { xa_init_flags(&octx->xa, XA_FLAGS_ALLOC1); lockdep_set_class(&octx->xa.xa_lock, &simple_offset_xa_lock); - - /* 0 is '.', 1 is '..', so always start with offset 2 */ - octx->next_offset = 2; + octx->next_offset = DIR_OFFSET_MIN; }
/** @@ -275,7 +278,7 @@ void simple_offset_init(struct offset_ctx *octx) */ int simple_offset_add(struct offset_ctx *octx, struct dentry *dentry) { - static const struct xa_limit limit = XA_LIMIT(2, U32_MAX); + static const struct xa_limit limit = XA_LIMIT(DIR_OFFSET_MIN, U32_MAX); u32 offset; int ret;
@@ -480,7 +483,7 @@ static int offset_readdir(struct file *file, struct dir_context *ctx) return 0;
/* In this case, ->private_data is protected by f_pos_lock */ - if (ctx->pos == 2) + if (ctx->pos == DIR_OFFSET_MIN) file->private_data = NULL; else if (file->private_data == ERR_PTR(-ENOENT)) return 0;
From: Chuck Lever chuck.lever@oracle.com
[ Upstream commit ecba88a3b32d733d41e27973e25b2bc580f64281 ]
For simple filesystems that use directory offset mapping, rely strictly on the directory offset map to tell when a directory has no children.
After this patch is applied, the emptiness test holds only the RCU read lock when the directory being tested has no children.
In addition, this adds another layer of confirmation that simple_offset_add/remove() are working as expected.
Reviewed-by: Jan Kara jack@suse.cz Signed-off-by: Chuck Lever chuck.lever@oracle.com Link: https://lore.kernel.org/r/170820143463.6328.7872919188371286951.stgit@91.116... Signed-off-by: Christian Brauner brauner@kernel.org Stable-dep-of: 5a1a25be995e ("libfs: Add simple_offset_rename() API") Signed-off-by: Chuck Lever chuck.lever@oracle.com --- fs/libfs.c | 32 ++++++++++++++++++++++++++++++++ include/linux/fs.h | 1 + mm/shmem.c | 4 ++-- 3 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/fs/libfs.c b/fs/libfs.c index c3dc58e776f9..d7b901cb9af4 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -312,6 +312,38 @@ void simple_offset_remove(struct offset_ctx *octx, struct dentry *dentry) offset_set(dentry, 0); }
+/** + * simple_offset_empty - Check if a dentry can be unlinked + * @dentry: dentry to be tested + * + * Returns 0 if @dentry is a non-empty directory; otherwise returns 1. + */ +int simple_offset_empty(struct dentry *dentry) +{ + struct inode *inode = d_inode(dentry); + struct offset_ctx *octx; + struct dentry *child; + unsigned long index; + int ret = 1; + + if (!inode || !S_ISDIR(inode->i_mode)) + return ret; + + index = DIR_OFFSET_MIN; + octx = inode->i_op->get_offset_ctx(inode); + xa_for_each(&octx->xa, index, child) { + spin_lock(&child->d_lock); + if (simple_positive(child)) { + spin_unlock(&child->d_lock); + ret = 0; + break; + } + spin_unlock(&child->d_lock); + } + + return ret; +} + /** * simple_offset_rename_exchange - exchange rename with directory offsets * @old_dir: parent of dentry being moved diff --git a/include/linux/fs.h b/include/linux/fs.h index 6c3d86532e3f..5104405ce3e6 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -3197,6 +3197,7 @@ struct offset_ctx { void simple_offset_init(struct offset_ctx *octx); int simple_offset_add(struct offset_ctx *octx, struct dentry *dentry); void simple_offset_remove(struct offset_ctx *octx, struct dentry *dentry); +int simple_offset_empty(struct dentry *dentry); int simple_offset_rename_exchange(struct inode *old_dir, struct dentry *old_dentry, struct inode *new_dir, diff --git a/mm/shmem.c b/mm/shmem.c index db7dd45c9181..aaf679976f3b 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -3368,7 +3368,7 @@ static int shmem_unlink(struct inode *dir, struct dentry *dentry)
static int shmem_rmdir(struct inode *dir, struct dentry *dentry) { - if (!simple_empty(dentry)) + if (!simple_offset_empty(dentry)) return -ENOTEMPTY;
drop_nlink(d_inode(dentry)); @@ -3425,7 +3425,7 @@ static int shmem_rename2(struct mnt_idmap *idmap, return simple_offset_rename_exchange(old_dir, old_dentry, new_dir, new_dentry);
- if (!simple_empty(new_dentry)) + if (!simple_offset_empty(new_dentry)) return -ENOTEMPTY;
if (flags & RENAME_WHITEOUT) {
From: Chuck Lever chuck.lever@oracle.com
[ Upstream commit 23cdd0eed3f1fff3af323092b0b88945a7950d8e ]
User space expects the replacement (old) directory entry to have the same directory offset after the rename.
Suggested-by: Christian Brauner brauner@kernel.org Fixes: a2e459555c5f ("shmem: stable directory offsets") Signed-off-by: Chuck Lever chuck.lever@oracle.com Link: https://lore.kernel.org/r/20240415152057.4605-2-cel@kernel.org Signed-off-by: Christian Brauner brauner@kernel.org [ cel: adjusted to apply to origin/linux-6.6.y ] Signed-off-by: Chuck Lever chuck.lever@oracle.com --- fs/libfs.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/fs/libfs.c b/fs/libfs.c index d7b901cb9af4..2029cb6a0e15 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -294,6 +294,18 @@ int simple_offset_add(struct offset_ctx *octx, struct dentry *dentry) return 0; }
+static int simple_offset_replace(struct offset_ctx *octx, struct dentry *dentry, + long offset) +{ + void *ret; + + ret = xa_store(&octx->xa, offset, dentry, GFP_KERNEL); + if (xa_is_err(ret)) + return xa_err(ret); + offset_set(dentry, offset); + return 0; +} + /** * simple_offset_remove - Remove an entry to a directory's offset map * @octx: directory offset ctx to be updated @@ -351,6 +363,9 @@ int simple_offset_empty(struct dentry *dentry) * @new_dir: destination parent * @new_dentry: destination dentry * + * This API preserves the directory offset values. Caller provides + * appropriate serialization. + * * Returns zero on success. Otherwise a negative errno is returned and the * rename is rolled back. */ @@ -368,11 +383,11 @@ int simple_offset_rename_exchange(struct inode *old_dir, simple_offset_remove(old_ctx, old_dentry); simple_offset_remove(new_ctx, new_dentry);
- ret = simple_offset_add(new_ctx, old_dentry); + ret = simple_offset_replace(new_ctx, old_dentry, new_index); if (ret) goto out_restore;
- ret = simple_offset_add(old_ctx, new_dentry); + ret = simple_offset_replace(old_ctx, new_dentry, old_index); if (ret) { simple_offset_remove(new_ctx, old_dentry); goto out_restore; @@ -387,10 +402,8 @@ int simple_offset_rename_exchange(struct inode *old_dir, return 0;
out_restore: - offset_set(old_dentry, old_index); - xa_store(&old_ctx->xa, old_index, old_dentry, GFP_KERNEL); - offset_set(new_dentry, new_index); - xa_store(&new_ctx->xa, new_index, new_dentry, GFP_KERNEL); + (void)simple_offset_replace(old_ctx, old_dentry, old_index); + (void)simple_offset_replace(new_ctx, new_dentry, new_index); return ret; }
From: Chuck Lever chuck.lever@oracle.com
[ Upstream commit 5a1a25be995e1014abd01600479915683e356f5c ]
I'm about to fix a tmpfs rename bug that requires the use of internal simple_offset helpers that are not available in mm/shmem.c
Signed-off-by: Chuck Lever chuck.lever@oracle.com Link: https://lore.kernel.org/r/20240415152057.4605-3-cel@kernel.org Signed-off-by: Christian Brauner brauner@kernel.org Signed-off-by: Chuck Lever chuck.lever@oracle.com --- fs/libfs.c | 21 +++++++++++++++++++++ include/linux/fs.h | 2 ++ mm/shmem.c | 3 +-- 3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/fs/libfs.c b/fs/libfs.c index 2029cb6a0e15..15d8c3300dae 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -356,6 +356,27 @@ int simple_offset_empty(struct dentry *dentry) return ret; }
+/** + * simple_offset_rename - handle directory offsets for rename + * @old_dir: parent directory of source entry + * @old_dentry: dentry of source entry + * @new_dir: parent_directory of destination entry + * @new_dentry: dentry of destination + * + * Caller provides appropriate serialization. + * + * Returns zero on success, a negative errno value on failure. + */ +int simple_offset_rename(struct inode *old_dir, struct dentry *old_dentry, + struct inode *new_dir, struct dentry *new_dentry) +{ + struct offset_ctx *old_ctx = old_dir->i_op->get_offset_ctx(old_dir); + struct offset_ctx *new_ctx = new_dir->i_op->get_offset_ctx(new_dir); + + simple_offset_remove(old_ctx, old_dentry); + return simple_offset_add(new_ctx, old_dentry); +} + /** * simple_offset_rename_exchange - exchange rename with directory offsets * @old_dir: parent of dentry being moved diff --git a/include/linux/fs.h b/include/linux/fs.h index 5104405ce3e6..e4d139fcaad0 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -3198,6 +3198,8 @@ void simple_offset_init(struct offset_ctx *octx); int simple_offset_add(struct offset_ctx *octx, struct dentry *dentry); void simple_offset_remove(struct offset_ctx *octx, struct dentry *dentry); int simple_offset_empty(struct dentry *dentry); +int simple_offset_rename(struct inode *old_dir, struct dentry *old_dentry, + struct inode *new_dir, struct dentry *new_dentry); int simple_offset_rename_exchange(struct inode *old_dir, struct dentry *old_dentry, struct inode *new_dir, diff --git a/mm/shmem.c b/mm/shmem.c index aaf679976f3b..ab2b0e87b051 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -3434,8 +3434,7 @@ static int shmem_rename2(struct mnt_idmap *idmap, return error; }
- simple_offset_remove(shmem_get_offset_ctx(old_dir), old_dentry); - error = simple_offset_add(shmem_get_offset_ctx(new_dir), old_dentry); + error = simple_offset_rename(old_dir, old_dentry, new_dir, new_dentry); if (error) return error;
From: Chuck Lever chuck.lever@oracle.com
[ Upstream commit ad191eb6d6942bb835a0b20b647f7c53c1d99ca4 ]
When renaming onto an existing directory entry, user space expects the replacement entry to have the same directory offset as the original one.
Link: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15966 Fixes: a2e459555c5f ("shmem: stable directory offsets") Signed-off-by: Chuck Lever chuck.lever@oracle.com Link: https://lore.kernel.org/r/20240415152057.4605-4-cel@kernel.org Signed-off-by: Christian Brauner brauner@kernel.org Signed-off-by: Chuck Lever chuck.lever@oracle.com --- fs/libfs.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/fs/libfs.c b/fs/libfs.c index 15d8c3300dae..ab9fc182fd22 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -365,6 +365,9 @@ int simple_offset_empty(struct dentry *dentry) * * Caller provides appropriate serialization. * + * User space expects the directory offset value of the replaced + * (new) directory entry to be unchanged after a rename. + * * Returns zero on success, a negative errno value on failure. */ int simple_offset_rename(struct inode *old_dir, struct dentry *old_dentry, @@ -372,8 +375,14 @@ int simple_offset_rename(struct inode *old_dir, struct dentry *old_dentry, { struct offset_ctx *old_ctx = old_dir->i_op->get_offset_ctx(old_dir); struct offset_ctx *new_ctx = new_dir->i_op->get_offset_ctx(new_dir); + long new_offset = dentry2offset(new_dentry);
simple_offset_remove(old_ctx, old_dentry); + + if (new_offset) { + offset_set(new_dentry, 0); + return simple_offset_replace(new_ctx, old_dentry, new_offset); + } return simple_offset_add(new_ctx, old_dentry); }
From: Chuck Lever chuck.lever@oracle.com
[ Upstream commit 903dc9c43a155e0893280c7472d4a9a3a83d75a6 ]
Testing shows that the EBUSY error return from mtree_alloc_cyclic() leaks into user space. The ERRORS section of "man creat(2)" says:
EBUSY O_EXCL was specified in flags and pathname refers to a block device that is in use by the system (e.g., it is mounted).
ENOSPC is closer to what applications expect in this situation.
Note that the normal range of simple directory offset values is 2..2^63, so hitting this error is going to be rare to impossible.
Fixes: 6faddda69f62 ("libfs: Add directory operations for stable offsets") Cc: stable@vger.kernel.org # v6.9+ Reviewed-by: Jeff Layton jlayton@kernel.org Reviewed-by: Yang Erkun yangerkun@huawei.com Signed-off-by: Chuck Lever chuck.lever@oracle.com Link: https://lore.kernel.org/r/20241228175522.1854234-2-cel@kernel.org Signed-off-by: Christian Brauner brauner@kernel.org [ cel: adjusted to apply to origin/linux-6.6.y ] Signed-off-by: Chuck Lever chuck.lever@oracle.com --- fs/libfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/libfs.c b/fs/libfs.c index ab9fc182fd22..200bcfc2ac34 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -287,8 +287,8 @@ int simple_offset_add(struct offset_ctx *octx, struct dentry *dentry)
ret = xa_alloc_cyclic(&octx->xa, &offset, dentry, limit, &octx->next_offset, GFP_KERNEL); - if (ret < 0) - return ret; + if (unlikely(ret < 0)) + return ret == -EBUSY ? -ENOSPC : ret;
offset_set(dentry, offset); return 0;
From: Chuck Lever chuck.lever@oracle.com
[ Upstream commit d7bde4f27ceef3dc6d72010a20d4da23db835a32 ]
simple_empty() and simple_offset_empty() perform the same task. The latter's use as a canary to find bugs has not found any new issues. A subsequent patch will remove the use of the mtree for iterating directory contents, so revert back to using a similar mechanism for determining whether a directory is indeed empty.
Only one such mechanism is ever needed.
Signed-off-by: Chuck Lever chuck.lever@oracle.com Link: https://lore.kernel.org/r/20241228175522.1854234-3-cel@kernel.org Reviewed-by: Yang Erkun yangerkun@huawei.com Signed-off-by: Christian Brauner brauner@kernel.org [ cel: adjusted to apply to origin/linux-6.6.y ] Signed-off-by: Chuck Lever chuck.lever@oracle.com --- fs/libfs.c | 32 -------------------------------- include/linux/fs.h | 1 - mm/shmem.c | 4 ++-- 3 files changed, 2 insertions(+), 35 deletions(-)
diff --git a/fs/libfs.c b/fs/libfs.c index 200bcfc2ac34..082bacf0b9e6 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -324,38 +324,6 @@ void simple_offset_remove(struct offset_ctx *octx, struct dentry *dentry) offset_set(dentry, 0); }
-/** - * simple_offset_empty - Check if a dentry can be unlinked - * @dentry: dentry to be tested - * - * Returns 0 if @dentry is a non-empty directory; otherwise returns 1. - */ -int simple_offset_empty(struct dentry *dentry) -{ - struct inode *inode = d_inode(dentry); - struct offset_ctx *octx; - struct dentry *child; - unsigned long index; - int ret = 1; - - if (!inode || !S_ISDIR(inode->i_mode)) - return ret; - - index = DIR_OFFSET_MIN; - octx = inode->i_op->get_offset_ctx(inode); - xa_for_each(&octx->xa, index, child) { - spin_lock(&child->d_lock); - if (simple_positive(child)) { - spin_unlock(&child->d_lock); - ret = 0; - break; - } - spin_unlock(&child->d_lock); - } - - return ret; -} - /** * simple_offset_rename - handle directory offsets for rename * @old_dir: parent directory of source entry diff --git a/include/linux/fs.h b/include/linux/fs.h index e4d139fcaad0..e47596d354ff 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -3197,7 +3197,6 @@ struct offset_ctx { void simple_offset_init(struct offset_ctx *octx); int simple_offset_add(struct offset_ctx *octx, struct dentry *dentry); void simple_offset_remove(struct offset_ctx *octx, struct dentry *dentry); -int simple_offset_empty(struct dentry *dentry); int simple_offset_rename(struct inode *old_dir, struct dentry *old_dentry, struct inode *new_dir, struct dentry *new_dentry); int simple_offset_rename_exchange(struct inode *old_dir, diff --git a/mm/shmem.c b/mm/shmem.c index ab2b0e87b051..283fb62084d4 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -3368,7 +3368,7 @@ static int shmem_unlink(struct inode *dir, struct dentry *dentry)
static int shmem_rmdir(struct inode *dir, struct dentry *dentry) { - if (!simple_offset_empty(dentry)) + if (!simple_empty(dentry)) return -ENOTEMPTY;
drop_nlink(d_inode(dentry)); @@ -3425,7 +3425,7 @@ static int shmem_rename2(struct mnt_idmap *idmap, return simple_offset_rename_exchange(old_dir, old_dentry, new_dir, new_dentry);
- if (!simple_offset_empty(new_dentry)) + if (!simple_empty(new_dentry)) return -ENOTEMPTY;
if (flags & RENAME_WHITEOUT) {
From: Chuck Lever chuck.lever@oracle.com
[ Upstream commit 68a3a65003145644efcbb651e91db249ccd96281 ]
According to getdents(3), the d_off field in each returned directory entry points to the next entry in the directory. The d_off field in the last returned entry in the readdir buffer must contain a valid offset value, but if it points to an actual directory entry, then readdir/getdents can loop.
This patch introduces a specific fixed offset value that is placed in the d_off field of the last entry in a directory. Some user space applications assume that the EOD offset value is larger than the offsets of real directory entries, so the largest valid offset value is reserved for this purpose. This new value is never allocated by simple_offset_add().
When ->iterate_dir() returns, getdents{64} inserts the ctx->pos value into the d_off field of the last valid entry in the readdir buffer. When it hits EOD, offset_readdir() sets ctx->pos to the EOD offset value so the last entry is updated to point to the EOD marker.
When trying to read the entry at the EOD offset, offset_readdir() terminates immediately.
It is worth noting that using a Maple tree for directory offset value allocation does not guarantee a 63-bit range of values -- on platforms where "long" is a 32-bit type, the directory offset value range is still 0..(2^31 - 1). For broad compatibility with 32-bit user space, the largest tmpfs directory cookie value is now S32_MAX.
Fixes: 796432efab1e ("libfs: getdents() should return 0 after reaching EOD") Signed-off-by: Chuck Lever chuck.lever@oracle.com Link: https://lore.kernel.org/r/20241228175522.1854234-5-cel@kernel.org Signed-off-by: Christian Brauner brauner@kernel.org [ cel: adjusted to apply to origin/linux-6.6.y ] Signed-off-by: Chuck Lever chuck.lever@oracle.com --- fs/libfs.c | 37 +++++++++++++++++++++---------------- 1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/fs/libfs.c b/fs/libfs.c index 082bacf0b9e6..d546f3f0c036 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -239,9 +239,15 @@ const struct inode_operations simple_dir_inode_operations = { }; EXPORT_SYMBOL(simple_dir_inode_operations);
-/* 0 is '.', 1 is '..', so always start with offset 2 or more */ +/* simple_offset_add() never assigns these to a dentry */ enum { - DIR_OFFSET_MIN = 2, + DIR_OFFSET_EOD = S32_MAX, +}; + +/* simple_offset_add() allocation range */ +enum { + DIR_OFFSET_MIN = 2, + DIR_OFFSET_MAX = DIR_OFFSET_EOD - 1, };
static void offset_set(struct dentry *dentry, u32 offset) @@ -278,7 +284,8 @@ void simple_offset_init(struct offset_ctx *octx) */ int simple_offset_add(struct offset_ctx *octx, struct dentry *dentry) { - static const struct xa_limit limit = XA_LIMIT(DIR_OFFSET_MIN, U32_MAX); + static const struct xa_limit limit = XA_LIMIT(DIR_OFFSET_MIN, + DIR_OFFSET_MAX); u32 offset; int ret;
@@ -442,8 +449,6 @@ static loff_t offset_dir_llseek(struct file *file, loff_t offset, int whence) return -EINVAL; }
- /* In this case, ->private_data is protected by f_pos_lock */ - file->private_data = NULL; return vfs_setpos(file, offset, U32_MAX); }
@@ -453,7 +458,7 @@ static struct dentry *offset_find_next(struct offset_ctx *octx, loff_t offset) XA_STATE(xas, &octx->xa, offset);
rcu_read_lock(); - child = xas_next_entry(&xas, U32_MAX); + child = xas_next_entry(&xas, DIR_OFFSET_MAX); if (!child) goto out; spin_lock(&child->d_lock); @@ -474,7 +479,7 @@ static bool offset_dir_emit(struct dir_context *ctx, struct dentry *dentry) inode->i_ino, fs_umode_to_dtype(inode->i_mode)); }
-static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx) +static void offset_iterate_dir(struct inode *inode, struct dir_context *ctx) { struct offset_ctx *octx = inode->i_op->get_offset_ctx(inode); struct dentry *dentry; @@ -482,7 +487,7 @@ static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx) while (true) { dentry = offset_find_next(octx, ctx->pos); if (!dentry) - return ERR_PTR(-ENOENT); + goto out_eod;
if (!offset_dir_emit(ctx, dentry)) { dput(dentry); @@ -492,7 +497,10 @@ static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx) ctx->pos = dentry2offset(dentry) + 1; dput(dentry); } - return NULL; + return; + +out_eod: + ctx->pos = DIR_OFFSET_EOD; }
/** @@ -512,6 +520,8 @@ static void *offset_iterate_dir(struct inode *inode, struct dir_context *ctx) * * On return, @ctx->pos contains an offset that will read the next entry * in this directory when offset_readdir() is called again with @ctx. + * Caller places this value in the d_off field of the last entry in the + * user's buffer. * * Return values: * %0 - Complete @@ -524,13 +534,8 @@ static int offset_readdir(struct file *file, struct dir_context *ctx)
if (!dir_emit_dots(file, ctx)) return 0; - - /* In this case, ->private_data is protected by f_pos_lock */ - if (ctx->pos == DIR_OFFSET_MIN) - file->private_data = NULL; - else if (file->private_data == ERR_PTR(-ENOENT)) - return 0; - file->private_data = offset_iterate_dir(d_inode(dir), ctx); + if (ctx->pos != DIR_OFFSET_EOD) + offset_iterate_dir(d_inode(dir), ctx); return 0; }
From: Chuck Lever chuck.lever@oracle.com
[ Upstream commit b9b588f22a0c049a14885399e27625635ae6ef91 ]
The mtree mechanism has been effective at creating directory offsets that are stable over multiple opendir instances. However, it has not been able to handle the subtleties of renames that are concurrent with readdir.
Instead of using the mtree to emit entries in the order of their offset values, use it only to map incoming ctx->pos to a starting entry. Then use the directory's d_children list, which is already maintained properly by the dcache, to find the next child to emit.
One of the sneaky things about this is that when the mtree-allocated offset value wraps (which is very rare), looking up ctx->pos++ is not going to find the next entry; it will return NULL. Instead, by following the d_children list, the offset values can appear in any order but all of the entries in the directory will be visited eventually.
Note also that the readdir() is guaranteed to reach the tail of this list. Entries are added only at the head of d_children, and readdir walks from its current position in that list towards its tail.
Signed-off-by: Chuck Lever chuck.lever@oracle.com Link: https://lore.kernel.org/r/20241228175522.1854234-6-cel@kernel.org Signed-off-by: Christian Brauner brauner@kernel.org [ cel: adjusted to apply to origin/linux-6.6.y ] Signed-off-by: Chuck Lever chuck.lever@oracle.com --- fs/libfs.c | 84 ++++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 59 insertions(+), 25 deletions(-)
diff --git a/fs/libfs.c b/fs/libfs.c index d546f3f0c036..f5566964aa7d 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -241,12 +241,13 @@ EXPORT_SYMBOL(simple_dir_inode_operations);
/* simple_offset_add() never assigns these to a dentry */ enum { + DIR_OFFSET_FIRST = 2, /* Find first real entry */ DIR_OFFSET_EOD = S32_MAX, };
/* simple_offset_add() allocation range */ enum { - DIR_OFFSET_MIN = 2, + DIR_OFFSET_MIN = DIR_OFFSET_FIRST + 1, DIR_OFFSET_MAX = DIR_OFFSET_EOD - 1, };
@@ -452,51 +453,84 @@ static loff_t offset_dir_llseek(struct file *file, loff_t offset, int whence) return vfs_setpos(file, offset, U32_MAX); }
-static struct dentry *offset_find_next(struct offset_ctx *octx, loff_t offset) +static struct dentry *find_positive_dentry(struct dentry *parent, + struct dentry *dentry, + bool next) { + struct dentry *found = NULL; + + spin_lock(&parent->d_lock); + if (next) + dentry = list_next_entry(dentry, d_child); + else if (!dentry) + dentry = list_first_entry_or_null(&parent->d_subdirs, + struct dentry, d_child); + for (; dentry && !list_entry_is_head(dentry, &parent->d_subdirs, d_child); + dentry = list_next_entry(dentry, d_child)) { + if (!simple_positive(dentry)) + continue; + spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED); + if (simple_positive(dentry)) + found = dget_dlock(dentry); + spin_unlock(&dentry->d_lock); + if (likely(found)) + break; + } + spin_unlock(&parent->d_lock); + return found; +} + +static noinline_for_stack struct dentry * +offset_dir_lookup(struct dentry *parent, loff_t offset) +{ + struct inode *inode = d_inode(parent); + struct offset_ctx *octx = inode->i_op->get_offset_ctx(inode); struct dentry *child, *found = NULL; + XA_STATE(xas, &octx->xa, offset);
- rcu_read_lock(); - child = xas_next_entry(&xas, DIR_OFFSET_MAX); - if (!child) - goto out; - spin_lock(&child->d_lock); - if (simple_positive(child)) - found = dget_dlock(child); - spin_unlock(&child->d_lock); -out: - rcu_read_unlock(); + if (offset == DIR_OFFSET_FIRST) + found = find_positive_dentry(parent, NULL, false); + else { + rcu_read_lock(); + child = xas_next_entry(&xas, DIR_OFFSET_MAX); + found = find_positive_dentry(parent, child, false); + rcu_read_unlock(); + } return found; }
static bool offset_dir_emit(struct dir_context *ctx, struct dentry *dentry) { - u32 offset = dentry2offset(dentry); struct inode *inode = d_inode(dentry);
- return ctx->actor(ctx, dentry->d_name.name, dentry->d_name.len, offset, - inode->i_ino, fs_umode_to_dtype(inode->i_mode)); + return dir_emit(ctx, dentry->d_name.name, dentry->d_name.len, + inode->i_ino, fs_umode_to_dtype(inode->i_mode)); }
-static void offset_iterate_dir(struct inode *inode, struct dir_context *ctx) +static void offset_iterate_dir(struct file *file, struct dir_context *ctx) { - struct offset_ctx *octx = inode->i_op->get_offset_ctx(inode); + struct dentry *dir = file->f_path.dentry; struct dentry *dentry;
+ dentry = offset_dir_lookup(dir, ctx->pos); + if (!dentry) + goto out_eod; while (true) { - dentry = offset_find_next(octx, ctx->pos); - if (!dentry) - goto out_eod; + struct dentry *next;
- if (!offset_dir_emit(ctx, dentry)) { - dput(dentry); + ctx->pos = dentry2offset(dentry); + if (!offset_dir_emit(ctx, dentry)) break; - }
- ctx->pos = dentry2offset(dentry) + 1; + next = find_positive_dentry(dir, dentry, true); dput(dentry); + + if (!next) + goto out_eod; + dentry = next; } + dput(dentry); return;
out_eod: @@ -535,7 +569,7 @@ static int offset_readdir(struct file *file, struct dir_context *ctx) if (!dir_emit_dots(file, ctx)) return 0; if (ctx->pos != DIR_OFFSET_EOD) - offset_iterate_dir(d_inode(dir), ctx); + offset_iterate_dir(file, ctx); return 0; }
On 1/24/25 2:19 PM, cel@kernel.org wrote:
From: Chuck Lever chuck.lever@oracle.com
This series backports several upstream fixes to origin/linux-6.6.y in order to address CVE-2024-46701:
https://nvd.nist.gov/vuln/detail/CVE-2024-46701
As applied to origin/linux-6.6.y, this series passes fstests and the git regression suite.
Before officially requesting that stable@ merge this series, I'd like to provide an opportunity for community review of the backport patches.
You can also find them them in the "nfsd-6.6.y" branch in
https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
Chuck Lever (10): libfs: Re-arrange locking in offset_iterate_dir() libfs: Define a minimum directory offset libfs: Add simple_offset_empty() libfs: Fix simple_offset_rename_exchange() libfs: Add simple_offset_rename() API shmem: Fix shmem_rename2() libfs: Return ENOSPC when the directory offset range is exhausted Revert "libfs: Add simple_offset_empty()" libfs: Replace simple_offset end-of-directory detection libfs: Use d_children list to iterate simple_offset directories
fs/libfs.c | 177 +++++++++++++++++++++++++++++++++------------ include/linux/fs.h | 2 + mm/shmem.c | 3 +- 3 files changed, 134 insertions(+), 48 deletions(-)
I've heard no objections or other comments. Greg, Sasha, shall we proceed with merging this patch series into v6.6 ?
On Wed, Jan 29, 2025 at 08:55:15AM -0500, Chuck Lever wrote:
On 1/24/25 2:19 PM, cel@kernel.org wrote:
From: Chuck Lever chuck.lever@oracle.com
This series backports several upstream fixes to origin/linux-6.6.y in order to address CVE-2024-46701:
https://nvd.nist.gov/vuln/detail/CVE-2024-46701
As applied to origin/linux-6.6.y, this series passes fstests and the git regression suite.
Before officially requesting that stable@ merge this series, I'd like to provide an opportunity for community review of the backport patches.
You can also find them them in the "nfsd-6.6.y" branch in
https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
Chuck Lever (10): libfs: Re-arrange locking in offset_iterate_dir() libfs: Define a minimum directory offset libfs: Add simple_offset_empty() libfs: Fix simple_offset_rename_exchange() libfs: Add simple_offset_rename() API shmem: Fix shmem_rename2() libfs: Return ENOSPC when the directory offset range is exhausted Revert "libfs: Add simple_offset_empty()" libfs: Replace simple_offset end-of-directory detection libfs: Use d_children list to iterate simple_offset directories
fs/libfs.c | 177 +++++++++++++++++++++++++++++++++------------ include/linux/fs.h | 2 + mm/shmem.c | 3 +- 3 files changed, 134 insertions(+), 48 deletions(-)
I've heard no objections or other comments. Greg, Sasha, shall we proceed with merging this patch series into v6.6 ?
Um, but not all of these are in a released kernel yet, so we can't take them all yet. Also what about 6.12.y and 6.13.y for those commits that will be showing up in 6.14-rc1? We can't have regressions for people moving to those releases from 6.6.y, right?
thanks,
greg k-h
On 1/29/25 9:50 AM, Greg Kroah-Hartman wrote:
On Wed, Jan 29, 2025 at 08:55:15AM -0500, Chuck Lever wrote:
On 1/24/25 2:19 PM, cel@kernel.org wrote:
From: Chuck Lever chuck.lever@oracle.com
This series backports several upstream fixes to origin/linux-6.6.y in order to address CVE-2024-46701:
https://nvd.nist.gov/vuln/detail/CVE-2024-46701
As applied to origin/linux-6.6.y, this series passes fstests and the git regression suite.
Before officially requesting that stable@ merge this series, I'd like to provide an opportunity for community review of the backport patches.
You can also find them them in the "nfsd-6.6.y" branch in
https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
Chuck Lever (10): libfs: Re-arrange locking in offset_iterate_dir() libfs: Define a minimum directory offset libfs: Add simple_offset_empty() libfs: Fix simple_offset_rename_exchange() libfs: Add simple_offset_rename() API shmem: Fix shmem_rename2() libfs: Return ENOSPC when the directory offset range is exhausted Revert "libfs: Add simple_offset_empty()" libfs: Replace simple_offset end-of-directory detection libfs: Use d_children list to iterate simple_offset directories
fs/libfs.c | 177 +++++++++++++++++++++++++++++++++------------ include/linux/fs.h | 2 + mm/shmem.c | 3 +- 3 files changed, 134 insertions(+), 48 deletions(-)
I've heard no objections or other comments. Greg, Sasha, shall we proceed with merging this patch series into v6.6 ?
Um, but not all of these are in a released kernel yet, so we can't take them all yet.
Hi Greg -
The new patches are in v6.14 now. I'm asking stable to take these whenever you are ready. Would that be v6.14-rc1? I can send a reminder if you like.
Also what about 6.12.y and 6.13.y for those commits that will be showing up in 6.14-rc1? We can't have regressions for people moving to those releases from 6.6.y, right?
The upstream commits have Fixes tags. I assumed that your automation will find those and apply them to those kernels -- the upstream versions of these patches I expect will apply cleanly to recent LTS.
On Wed, Jan 29, 2025 at 10:06:49AM -0500, Chuck Lever wrote:
On 1/29/25 9:50 AM, Greg Kroah-Hartman wrote:
On Wed, Jan 29, 2025 at 08:55:15AM -0500, Chuck Lever wrote:
On 1/24/25 2:19 PM, cel@kernel.org wrote:
From: Chuck Lever chuck.lever@oracle.com
This series backports several upstream fixes to origin/linux-6.6.y in order to address CVE-2024-46701:
https://nvd.nist.gov/vuln/detail/CVE-2024-46701
As applied to origin/linux-6.6.y, this series passes fstests and the git regression suite.
Before officially requesting that stable@ merge this series, I'd like to provide an opportunity for community review of the backport patches.
You can also find them them in the "nfsd-6.6.y" branch in
https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
Chuck Lever (10): libfs: Re-arrange locking in offset_iterate_dir() libfs: Define a minimum directory offset libfs: Add simple_offset_empty() libfs: Fix simple_offset_rename_exchange() libfs: Add simple_offset_rename() API shmem: Fix shmem_rename2() libfs: Return ENOSPC when the directory offset range is exhausted Revert "libfs: Add simple_offset_empty()" libfs: Replace simple_offset end-of-directory detection libfs: Use d_children list to iterate simple_offset directories
fs/libfs.c | 177 +++++++++++++++++++++++++++++++++------------ include/linux/fs.h | 2 + mm/shmem.c | 3 +- 3 files changed, 134 insertions(+), 48 deletions(-)
I've heard no objections or other comments. Greg, Sasha, shall we proceed with merging this patch series into v6.6 ?
Um, but not all of these are in a released kernel yet, so we can't take them all yet.
Hi Greg -
The new patches are in v6.14 now. I'm asking stable to take these whenever you are ready. Would that be v6.14-rc1? I can send a reminder if you like.
Yes, we have to wait until changes are in a -rc release unless there are "real reasons to take it now" :)
Also what about 6.12.y and 6.13.y for those commits that will be showing up in 6.14-rc1? We can't have regressions for people moving to those releases from 6.6.y, right?
The upstream commits have Fixes tags. I assumed that your automation will find those and apply them to those kernels -- the upstream versions of these patches I expect will apply cleanly to recent LTS.
"Fixes:" are never guaranteed to show up in stable kernels, they are only a "maybe when we get some spare cycles and get around to it we might do a simple pass to see what works or doesn't."
If you KNOW a change is a bugfix for stable kernels, please mark it as such! "Fixes:" is NOT how to do that, and never has been. It's only additional meta-data that helps us out.
So please send us a list of the commits that need to go to 6.12.y and 6.13.y, we have to have that before we could take the 6.6.y changes.
thanks,
greg k-h
On 1/29/25 10:21 AM, Greg Kroah-Hartman wrote:
On Wed, Jan 29, 2025 at 10:06:49AM -0500, Chuck Lever wrote:
On 1/29/25 9:50 AM, Greg Kroah-Hartman wrote:
On Wed, Jan 29, 2025 at 08:55:15AM -0500, Chuck Lever wrote:
On 1/24/25 2:19 PM, cel@kernel.org wrote:
From: Chuck Lever chuck.lever@oracle.com
This series backports several upstream fixes to origin/linux-6.6.y in order to address CVE-2024-46701:
https://nvd.nist.gov/vuln/detail/CVE-2024-46701
As applied to origin/linux-6.6.y, this series passes fstests and the git regression suite.
Before officially requesting that stable@ merge this series, I'd like to provide an opportunity for community review of the backport patches.
You can also find them them in the "nfsd-6.6.y" branch in
https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
Chuck Lever (10): libfs: Re-arrange locking in offset_iterate_dir() libfs: Define a minimum directory offset libfs: Add simple_offset_empty() libfs: Fix simple_offset_rename_exchange() libfs: Add simple_offset_rename() API shmem: Fix shmem_rename2() libfs: Return ENOSPC when the directory offset range is exhausted Revert "libfs: Add simple_offset_empty()" libfs: Replace simple_offset end-of-directory detection libfs: Use d_children list to iterate simple_offset directories
fs/libfs.c | 177 +++++++++++++++++++++++++++++++++------------ include/linux/fs.h | 2 + mm/shmem.c | 3 +- 3 files changed, 134 insertions(+), 48 deletions(-)
I've heard no objections or other comments. Greg, Sasha, shall we proceed with merging this patch series into v6.6 ?
Um, but not all of these are in a released kernel yet, so we can't take them all yet.
Hi Greg -
The new patches are in v6.14 now. I'm asking stable to take these whenever you are ready. Would that be v6.14-rc1? I can send a reminder if you like.
Yes, we have to wait until changes are in a -rc release unless there are "real reasons to take it now" :)
Also what about 6.12.y and 6.13.y for those commits that will be showing up in 6.14-rc1? We can't have regressions for people moving to those releases from 6.6.y, right?
The upstream commits have Fixes tags. I assumed that your automation will find those and apply them to those kernels -- the upstream versions of these patches I expect will apply cleanly to recent LTS.
"Fixes:" are never guaranteed to show up in stable kernels, they are only a "maybe when we get some spare cycles and get around to it we might do a simple pass to see what works or doesn't."
If you KNOW a change is a bugfix for stable kernels, please mark it as such! "Fixes:" is NOT how to do that, and never has been. It's only additional meta-data that helps us out.
So please send us a list of the commits that need to go to 6.12.y and 6.13.y, we have to have that before we could take the 6.6.y changes.
903dc9c43a15 ("libfs: Return ENOSPC when the directory offset range is exhausted") d7bde4f27cee ("Revert "libfs: Add simple_offset_empty()"") b662d858131d ("Revert "libfs: fix infinite directory reads for offset dir"") 68a3a6500314 ("libfs: Replace simple_offset end-of-directory detection") b9b588f22a0c ("libfs: Use d_children list to iterate simple_offset directories")
On Wed, Jan 29, 2025 at 11:37:51AM -0500, Chuck Lever wrote:
On 1/29/25 10:21 AM, Greg Kroah-Hartman wrote:
On Wed, Jan 29, 2025 at 10:06:49AM -0500, Chuck Lever wrote:
On 1/29/25 9:50 AM, Greg Kroah-Hartman wrote:
On Wed, Jan 29, 2025 at 08:55:15AM -0500, Chuck Lever wrote:
On 1/24/25 2:19 PM, cel@kernel.org wrote:
From: Chuck Lever chuck.lever@oracle.com
This series backports several upstream fixes to origin/linux-6.6.y in order to address CVE-2024-46701:
https://nvd.nist.gov/vuln/detail/CVE-2024-46701
As applied to origin/linux-6.6.y, this series passes fstests and the git regression suite.
Before officially requesting that stable@ merge this series, I'd like to provide an opportunity for community review of the backport patches.
You can also find them them in the "nfsd-6.6.y" branch in
https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
Chuck Lever (10): libfs: Re-arrange locking in offset_iterate_dir() libfs: Define a minimum directory offset libfs: Add simple_offset_empty() libfs: Fix simple_offset_rename_exchange() libfs: Add simple_offset_rename() API shmem: Fix shmem_rename2() libfs: Return ENOSPC when the directory offset range is exhausted Revert "libfs: Add simple_offset_empty()" libfs: Replace simple_offset end-of-directory detection libfs: Use d_children list to iterate simple_offset directories
fs/libfs.c | 177 +++++++++++++++++++++++++++++++++------------ include/linux/fs.h | 2 + mm/shmem.c | 3 +- 3 files changed, 134 insertions(+), 48 deletions(-)
I've heard no objections or other comments. Greg, Sasha, shall we proceed with merging this patch series into v6.6 ?
Um, but not all of these are in a released kernel yet, so we can't take them all yet.
Hi Greg -
The new patches are in v6.14 now. I'm asking stable to take these whenever you are ready. Would that be v6.14-rc1? I can send a reminder if you like.
Yes, we have to wait until changes are in a -rc release unless there are "real reasons to take it now" :)
Also what about 6.12.y and 6.13.y for those commits that will be showing up in 6.14-rc1? We can't have regressions for people moving to those releases from 6.6.y, right?
The upstream commits have Fixes tags. I assumed that your automation will find those and apply them to those kernels -- the upstream versions of these patches I expect will apply cleanly to recent LTS.
"Fixes:" are never guaranteed to show up in stable kernels, they are only a "maybe when we get some spare cycles and get around to it we might do a simple pass to see what works or doesn't."
If you KNOW a change is a bugfix for stable kernels, please mark it as such! "Fixes:" is NOT how to do that, and never has been. It's only additional meta-data that helps us out.
So please send us a list of the commits that need to go to 6.12.y and 6.13.y, we have to have that before we could take the 6.6.y changes.
903dc9c43a15 ("libfs: Return ENOSPC when the directory offset range is exhausted") d7bde4f27cee ("Revert "libfs: Add simple_offset_empty()"") b662d858131d ("Revert "libfs: fix infinite directory reads for offset dir"") 68a3a6500314 ("libfs: Replace simple_offset end-of-directory detection") b9b588f22a0c ("libfs: Use d_children list to iterate simple_offset directories")
Cool, thanks for the list (and not all were marked with fixes, i.e. those reverts, I guess we need to start checking for reverts better. I have tooling set up for that but not integrated yet...)
I'll just queue them all up now.
greg k-h
On 1/30/25 3:45 AM, Greg Kroah-Hartman wrote:
On Wed, Jan 29, 2025 at 11:37:51AM -0500, Chuck Lever wrote:
On 1/29/25 10:21 AM, Greg Kroah-Hartman wrote:
On Wed, Jan 29, 2025 at 10:06:49AM -0500, Chuck Lever wrote:
On 1/29/25 9:50 AM, Greg Kroah-Hartman wrote:
On Wed, Jan 29, 2025 at 08:55:15AM -0500, Chuck Lever wrote:
On 1/24/25 2:19 PM, cel@kernel.org wrote: > From: Chuck Lever chuck.lever@oracle.com > > This series backports several upstream fixes to origin/linux-6.6.y > in order to address CVE-2024-46701: > > https://nvd.nist.gov/vuln/detail/CVE-2024-46701 > > As applied to origin/linux-6.6.y, this series passes fstests and the > git regression suite. > > Before officially requesting that stable@ merge this series, I'd > like to provide an opportunity for community review of the backport > patches. > > You can also find them them in the "nfsd-6.6.y" branch in > > https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git > > Chuck Lever (10): > libfs: Re-arrange locking in offset_iterate_dir() > libfs: Define a minimum directory offset > libfs: Add simple_offset_empty() > libfs: Fix simple_offset_rename_exchange() > libfs: Add simple_offset_rename() API > shmem: Fix shmem_rename2() > libfs: Return ENOSPC when the directory offset range is exhausted > Revert "libfs: Add simple_offset_empty()" > libfs: Replace simple_offset end-of-directory detection > libfs: Use d_children list to iterate simple_offset directories > > fs/libfs.c | 177 +++++++++++++++++++++++++++++++++------------ > include/linux/fs.h | 2 + > mm/shmem.c | 3 +- > 3 files changed, 134 insertions(+), 48 deletions(-) >
I've heard no objections or other comments. Greg, Sasha, shall we proceed with merging this patch series into v6.6 ?
Um, but not all of these are in a released kernel yet, so we can't take them all yet.
Hi Greg -
The new patches are in v6.14 now. I'm asking stable to take these whenever you are ready. Would that be v6.14-rc1? I can send a reminder if you like.
Yes, we have to wait until changes are in a -rc release unless there are "real reasons to take it now" :)
Also what about 6.12.y and 6.13.y for those commits that will be showing up in 6.14-rc1? We can't have regressions for people moving to those releases from 6.6.y, right?
The upstream commits have Fixes tags. I assumed that your automation will find those and apply them to those kernels -- the upstream versions of these patches I expect will apply cleanly to recent LTS.
"Fixes:" are never guaranteed to show up in stable kernels, they are only a "maybe when we get some spare cycles and get around to it we might do a simple pass to see what works or doesn't."
If you KNOW a change is a bugfix for stable kernels, please mark it as such! "Fixes:" is NOT how to do that, and never has been. It's only additional meta-data that helps us out.
So please send us a list of the commits that need to go to 6.12.y and 6.13.y, we have to have that before we could take the 6.6.y changes.
903dc9c43a15 ("libfs: Return ENOSPC when the directory offset range is exhausted") d7bde4f27cee ("Revert "libfs: Add simple_offset_empty()"") b662d858131d ("Revert "libfs: fix infinite directory reads for offset dir"") 68a3a6500314 ("libfs: Replace simple_offset end-of-directory detection") b9b588f22a0c ("libfs: Use d_children list to iterate simple_offset directories")
Cool, thanks for the list (and not all were marked with fixes, i.e. those reverts, I guess we need to start checking for reverts better. I have tooling set up for that but not integrated yet...)
I'll just queue them all up now.
My thinking was the patches marked "Fixes:" would show an obvious need for applying the unmarked patches as pre-requisites first.
I promise to do better marking patches with "Cc: stable". But also let me know if there's a way to label pre-req patches more clearly. Maybe "Cc: stable" without "Fixes:" is the way to go there.
Thank you, Greg, for your time.
On Thu, Jan 30, 2025 at 09:02:41AM -0500, Chuck Lever wrote:
On 1/30/25 3:45 AM, Greg Kroah-Hartman wrote:
On Wed, Jan 29, 2025 at 11:37:51AM -0500, Chuck Lever wrote:
On 1/29/25 10:21 AM, Greg Kroah-Hartman wrote:
On Wed, Jan 29, 2025 at 10:06:49AM -0500, Chuck Lever wrote:
On 1/29/25 9:50 AM, Greg Kroah-Hartman wrote:
On Wed, Jan 29, 2025 at 08:55:15AM -0500, Chuck Lever wrote: > On 1/24/25 2:19 PM, cel@kernel.org wrote: >> From: Chuck Lever chuck.lever@oracle.com >> >> This series backports several upstream fixes to origin/linux-6.6.y >> in order to address CVE-2024-46701: >> >> https://nvd.nist.gov/vuln/detail/CVE-2024-46701 >> >> As applied to origin/linux-6.6.y, this series passes fstests and the >> git regression suite. >> >> Before officially requesting that stable@ merge this series, I'd >> like to provide an opportunity for community review of the backport >> patches. >> >> You can also find them them in the "nfsd-6.6.y" branch in >> >> https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git >> >> Chuck Lever (10): >> libfs: Re-arrange locking in offset_iterate_dir() >> libfs: Define a minimum directory offset >> libfs: Add simple_offset_empty() >> libfs: Fix simple_offset_rename_exchange() >> libfs: Add simple_offset_rename() API >> shmem: Fix shmem_rename2() >> libfs: Return ENOSPC when the directory offset range is exhausted >> Revert "libfs: Add simple_offset_empty()" >> libfs: Replace simple_offset end-of-directory detection >> libfs: Use d_children list to iterate simple_offset directories >> >> fs/libfs.c | 177 +++++++++++++++++++++++++++++++++------------ >> include/linux/fs.h | 2 + >> mm/shmem.c | 3 +- >> 3 files changed, 134 insertions(+), 48 deletions(-) >> > > I've heard no objections or other comments. Greg, Sasha, shall we > proceed with merging this patch series into v6.6 ?
Um, but not all of these are in a released kernel yet, so we can't take them all yet.
Hi Greg -
The new patches are in v6.14 now. I'm asking stable to take these whenever you are ready. Would that be v6.14-rc1? I can send a reminder if you like.
Yes, we have to wait until changes are in a -rc release unless there are "real reasons to take it now" :)
Also what about 6.12.y and 6.13.y for those commits that will be showing up in 6.14-rc1? We can't have regressions for people moving to those releases from 6.6.y, right?
The upstream commits have Fixes tags. I assumed that your automation will find those and apply them to those kernels -- the upstream versions of these patches I expect will apply cleanly to recent LTS.
"Fixes:" are never guaranteed to show up in stable kernels, they are only a "maybe when we get some spare cycles and get around to it we might do a simple pass to see what works or doesn't."
If you KNOW a change is a bugfix for stable kernels, please mark it as such! "Fixes:" is NOT how to do that, and never has been. It's only additional meta-data that helps us out.
So please send us a list of the commits that need to go to 6.12.y and 6.13.y, we have to have that before we could take the 6.6.y changes.
903dc9c43a15 ("libfs: Return ENOSPC when the directory offset range is exhausted") d7bde4f27cee ("Revert "libfs: Add simple_offset_empty()"") b662d858131d ("Revert "libfs: fix infinite directory reads for offset dir"") 68a3a6500314 ("libfs: Replace simple_offset end-of-directory detection") b9b588f22a0c ("libfs: Use d_children list to iterate simple_offset directories")
Cool, thanks for the list (and not all were marked with fixes, i.e. those reverts, I guess we need to start checking for reverts better. I have tooling set up for that but not integrated yet...)
I'll just queue them all up now.
My thinking was the patches marked "Fixes:" would show an obvious need for applying the unmarked patches as pre-requisites first.
For when you send us a patch series for inclusion, sure, all is fine. I mean for when you merge stuff to Linus and expect us to pick them up.
I promise to do better marking patches with "Cc: stable". But also let me know if there's a way to label pre-req patches more clearly. Maybe "Cc: stable" without "Fixes:" is the way to go there.
Both is best, that way if you have a Fixes: tag in it, and a patch does not apply properly, you will get a "FAILED" email sent to you. If you only have the cc: stable then we just do a best-effort attempt and stop backporting when it doesn't apply and don't notify you at all about any failures.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org