linux-trace-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Beau Belgrave <beaub@linux.microsoft.com>
To: rostedt@goodmis.org
Cc: linux-trace-kernel@vger.kernel.org
Subject: trace_event names with more than NAME_MAX chars
Date: Fri, 8 Dec 2023 18:36:01 +0000	[thread overview]
Message-ID: <20231208183601.GA46-beaub@linux.microsoft.com> (raw)

While developing some unrelated features I happened to create a
trace_event that was more than NAME_MAX (255) characters. When this
happened the creation worked, but tracefs would hang any task that tried
to list the directory of the trace_event or remove it.

I followed the code down to the reason being eventfs would call
simple_lookup(), and if it failed, it would still try to create the
dentry. In this case DCACHE_PAR_LOOKUP would get set and never cleared.
This caused d_wait_lookup() to loop forever, since that flag is used in
d_in_lookup().

Both tracefs and eventfs use simple_lookup() and it fails for
dentries that exceed NAME_MAX. Should we even allow trace_events to
be created that exceed this limit? Or should tracefs/eventfs allow
this but somehow represent these differently?

I have a fix that appears to work for myself, but unsure if there are
other locations (attached at the end of this mail).

Thanks,
-Beau

diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
index f8a594a50ae6..d2c06ba26db4 100644
--- a/fs/tracefs/event_inode.c
+++ b/fs/tracefs/event_inode.c
@@ -561,6 +561,8 @@ static struct dentry *eventfs_root_lookup(struct inode *dir,
                if (strcmp(ei_child->name, name) != 0)
                        continue;
                ret = simple_lookup(dir, dentry, flags);
+               if (IS_ERR(ret))
+                       goto out;
                create_dir_dentry(ei, ei_child, ei_dentry, true);
                created = true;
                break;
@@ -583,6 +585,8 @@ static struct dentry *eventfs_root_lookup(struct inode *dir,
                        if (r <= 0)
                                continue;
                        ret = simple_lookup(dir, dentry, flags);
+                       if (IS_ERR(ret))
+                               goto out;
                        create_file_dentry(ei, i, ei_dentry, name, mode, cdata,
                                           fops, true);
                        break;

             reply	other threads:[~2023-12-08 18:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-08 18:36 Beau Belgrave [this message]
2023-12-09 14:49 ` trace_event names with more than NAME_MAX chars 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=20231208183601.GA46-beaub@linux.microsoft.com \
    --to=beaub@linux.microsoft.com \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /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;
as well as URLs for NNTP newsgroup(s).