mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Deepanshu Kartikey <kartikey406@gmail.com>
Cc: mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	syzbot+3ef80b4ed02226d04a06@syzkaller.appspotmail.com,
	stable@vger.kernel.org
Subject: Re: [PATCH] eventfs: Initialize ei->children and ei->list in init_ei()
Date: Mon, 24 Aug 2026 11:03:45 -0400	[thread overview]
Message-ID: <20260824110345.22c1cfa1@fedora> (raw)
In-Reply-To: <20260824144653.54044-1-kartikey406@gmail.com>

On Mon, 24 Aug 2026 20:16:53 +0530
Deepanshu Kartikey <kartikey406@gmail.com> wrote:

Yeah, I saw the syzbot report and came up immediately with this fix as
well. But the change log is way too verbose for such a simple fix. Did
you use AI for this patch? If so, you must divulge that information,
usually with a tag.

> eventfs_create_events_dir() allocates the eventfs_inode via
> alloc_root_ei(), but only calls INIT_LIST_HEAD() on ei->children
> and ei->list after the tracefs_get_inode() check. If that check
> fails, the code jumps to the fail label and calls cleanup_ei(),
> which calls free_ei():
> 
> 	WARN_ON_ONCE(!list_empty(&ei->children));
> 
> Since ei was allocated with kzalloc(), ei->children.next is NULL
> at this point, not a self-referencing pointer. list_empty() checks
> head->next == head, so it returns false on an uninitialized list
> head, triggering a false-positive WARN_ON_ONCE() even though the
> list was never used.
> 
> eventfs_create_dir() has the same latent issue: alloc_ei() is
> called before INIT_LIST_HEAD(), leaving a window where an early
> failure path could hit cleanup_ei() on an uninitialized list head.
> 
> Move the INIT_LIST_HEAD() calls into init_ei(), which is called
> by both alloc_ei() and alloc_root_ei() immediately after
> allocation. This guarantees every eventfs_inode has a valid,
> self-linked, empty children/list the moment it is allocated,
> regardless of which failure path runs afterward.

The change log only needs to say:

  eventfs_create_dir() allocates the eventfs_inode and initializes it
  with init_ei(). But this does not initialize the eventfs_inode
  list_heads. If the eventfs_create_dir() fails due to memory pressure,
  it will call free_ei() which checks to make sure the eventfs_inode
  has no children. But because the list wasn't initialized, it will
  give a false warning.

  Fix it by moving the list initialization into init_ei().

See, much better. Right to the point without all the AI slop.

I'll take your patch, but I'm replacing the commit log with the above.

-- Steve


> 
> Fixes: 5790b1fb3d67 ("eventfs: Remove eventfs_file and just use eventfs_inode")
> Reported-by: syzbot+3ef80b4ed02226d04a06@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=3ef80b4ed02226d04a06
> Cc: stable@vger.kernel.org
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
> ---
>  fs/tracefs/event_inode.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
> index 604ba3e841d2..6e3513b13cfa 100644
> --- a/fs/tracefs/event_inode.c
> +++ b/fs/tracefs/event_inode.c
> @@ -438,6 +438,8 @@ static inline struct eventfs_inode *init_ei(struct eventfs_inode *ei, const char
>  	if (!ei->name)
>  		return NULL;
>  	kref_init(&ei->kref);
> +	INIT_LIST_HEAD(&ei->children);
> +	INIT_LIST_HEAD(&ei->list);
>  	return ei;
>  }
>  
> @@ -729,8 +731,6 @@ struct eventfs_inode *eventfs_create_dir(const char *name, struct eventfs_inode
>  	ei->entries = entries;
>  	ei->nr_entries = size;
>  	ei->data = data;
> -	INIT_LIST_HEAD(&ei->children);
> -	INIT_LIST_HEAD(&ei->list);
>  
>  	scoped_guard(mutex, &eventfs_mutex) {
>  		if (!parent->is_freed)
> @@ -802,9 +802,6 @@ struct eventfs_inode *eventfs_create_events_dir(const char *name, struct dentry
>  	ei->attr.uid = uid;
>  	ei->attr.gid = gid;
>  
> -	INIT_LIST_HEAD(&ei->children);
> -	INIT_LIST_HEAD(&ei->list);
> -
>  	ti = get_tracefs(inode);
>  	ti->flags |= TRACEFS_EVENT_INODE;
>  	ti->private = ei;


  reply	other threads:[~2026-08-24 15:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24 14:46 Deepanshu Kartikey
2026-08-24 15:03 ` Steven Rostedt [this message]
2026-08-25  1:23   ` Deepanshu Kartikey
2026-08-25  1:36     ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260824110345.22c1cfa1@fedora \
    --to=rostedt@goodmis.org \
    --cc=kartikey406@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=syzbot+3ef80b4ed02226d04a06@syzkaller.appspotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®