Re: [PATCH] eventfs: Add warning for out of bounds pos in __eventfs_iterate()

--- Patch [1]: [PATCH] eventfs: Add warning for out of bounds pos in __eventfs_iterate() ---

commit 2f3bdca57e4eb4f6f462c12ceab80527f383bb86
Author: Steven Rostedt [off-list ref]

eventfs: Add warning for out of bounds pos in __eventfs_iterate()

This commit adds a WARN_ON_ONCE to eventfs_iterate() to catch out of bounds
positions. It ensures that ctx->pos remains within the expected range, 
guarding against potential overflow issues from 64-bit seeks.

Link: https://sashiko.dev/#/patchset/20260810160708.3460a2fd%40gandalf.local.home

quoted

diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
index a524584353279..604ba3e841d24 100644
--- a/fs/tracefs/event_inode.c
+++ b/fs/tracefs/event_inode.c

@@ -594,6 +594,10 @@ static int eventfs_iterate(struct file *file, struct dir_context *ctx)
 	if (!(ti->flags & TRACEFS_EVENT_INODE))
 		return -EINVAL;
 
+	/* Logic should prevent ctx->pos from going out of range */
+	if (WARN_ON_ONCE(ctx->pos < 2 || ctx->pos > 0x7fffffffULL))
+		return -EINVAL;
+
 	c = ctx->pos - 2;
 
 	guard(srcu)(&eventfs_srcu);

[ ... ]

quoted

 	list_for_each_entry_srcu(ei_child, &ei->children, list,
 				 srcu_read_lock_held(&eventfs_srcu)) {

[ ... ]

quoted

 		smp_rmb();
 		if (ei->is_freed)
 			return -EINVAL;
 
 		if (c > 0) {
 			c--;
 			continue;
 		}

This is a pre-existing issue, but does the skip logic here using the
absolute index c risk omitting valid directory entries during concurrent
modifications?

If a user calls getdents on an eventfs directory and it returns partially
(e.g., due to a full buffer), and a child entry is concurrently removed from
ei->children via list_del_rcu(), the list shrinks.

When getdents resumes on the next syscall, eventfs_iterate() recalculates
c = ctx->pos - 2. Since the list physically shrank, using this absolute
index might skip too many elements in the now-shrunken list, bypassing valid
entries that have shifted forward.

Is there a mechanism preventing this race between getdents and concurrent
removals?