All of lore.kernel.org
 help / color / mirror / Atom feed
From: Beau Belgrave <beaub@linux.microsoft.com>
To: rostedt@goodmis.org, mhiramat@kernel.org, mathieu.desnoyers@efficios.com
Cc: linux-trace-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC PATCH v2 6/7] tracing/user_events: Enable setting event limit within namespace
Date: Thu, 28 Jul 2022 16:52:40 -0700	[thread overview]
Message-ID: <20220728235241.2249-7-beaub@linux.microsoft.com> (raw)
In-Reply-To: <20220728235241.2249-1-beaub@linux.microsoft.com>

When granting non-admin users the ability to register and write data to
user events they should have a limit imposed. Using the namespace
options file, operators can change the limit of the events that are
allowed to be created.

There is also a new line in the user_events_status file to let users
know the current limit (and to ask the operator for more if required).

For example, to limit the namespace to only 256 events:
echo user_events_limit=256 > options

From within the namespace root:
cat user_events_status
...
Limit: 256

Signed-off-by: Beau Belgrave <beaub@linux.microsoft.com>
---
 kernel/trace/trace_events_user.c | 57 +++++++++++++++++++++++++++++---
 1 file changed, 52 insertions(+), 5 deletions(-)

diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
index 9694eee27956..1dc88bbd04f9 100644
--- a/kernel/trace/trace_events_user.c
+++ b/kernel/trace/trace_events_user.c
@@ -41,6 +41,7 @@
 #define MAX_PAGES (1 << MAX_PAGE_ORDER)
 #define MAX_BYTES (MAX_PAGES * PAGE_SIZE)
 #define MAX_EVENTS (MAX_BYTES * 8)
+#define MAX_LIMIT (MAX_EVENTS - 1)
 
 /* Limit how long of an event name plus args within the subsystem. */
 #define MAX_EVENT_DESC 512
@@ -85,6 +86,7 @@ struct user_event_group {
 	DECLARE_BITMAP(page_bitmap, MAX_EVENTS);
 	refcount_t refcnt;
 	int id;
+	int reg_limit;
 };
 
 static DEFINE_HASHTABLE(group_table, 8);
@@ -252,6 +254,13 @@ static struct user_event_group *user_event_group_create(const char *name,
 			goto error;
 	}
 
+	/*
+	 * Register limit is based on available events:
+	 * The ABI states event 0 is reserved, so the real max is the amount
+	 * of bits in the bitmap minus 1 (the reserved event slot).
+	 */
+	group->reg_limit = MAX_LIMIT;
+
 	group->pages = alloc_pages(GFP_KERNEL | __GFP_ZERO, MAX_PAGE_ORDER);
 
 	if (!group->pages)
@@ -1276,8 +1285,7 @@ static int user_event_parse(struct user_event_group *group, char *name,
 			    char *args, char *flags,
 			    struct user_event **newuser)
 {
-	int ret;
-	int index;
+	int ret, index, limit;
 	u32 key;
 	struct user_event *user;
 
@@ -1296,9 +1304,16 @@ static int user_event_parse(struct user_event_group *group, char *name,
 		return 0;
 	}
 
-	index = find_first_zero_bit(group->page_bitmap, MAX_EVENTS);
+	/*
+	 * 0 is a reserved bit, so the real limit needs to be one higher.
+	 * An example of this is a limit of 1, bit 0 is always set. To make
+	 * this work, the limit must be 2 in this case (bit 1 will be set).
+	 */
+	limit = min(group->reg_limit + 1, (int)MAX_EVENTS);
+
+	index = find_first_zero_bit(group->page_bitmap, limit);
 
-	if (index == MAX_EVENTS)
+	if (index == limit)
 		return -EMFILE;
 
 	user = kzalloc(sizeof(*user), GFP_KERNEL);
@@ -1831,6 +1846,7 @@ static int user_seq_show(struct seq_file *m, void *p)
 	seq_printf(m, "Active: %d\n", active);
 	seq_printf(m, "Busy: %d\n", busy);
 	seq_printf(m, "Max: %ld\n", MAX_EVENTS);
+	seq_printf(m, "Limit: %d\n", group->reg_limit);
 
 	return 0;
 }
@@ -2010,13 +2026,44 @@ static int user_event_ns_remove(struct trace_namespace *ns)
 	return ret;
 }
 
+#define NS_EVENT_LIMIT_PREFIX "user_events_limit="
+
 static int user_event_ns_parse(struct trace_namespace *ns, const char *command)
 {
-	return -ECANCELED;
+	struct user_event_group *group = user_event_group_find(ns->id);
+	int len, value, ret = -ECANCELED;
+
+	if (!group)
+		return -ECANCELED;
+
+	len = str_has_prefix(command, NS_EVENT_LIMIT_PREFIX);
+	if (len && !kstrtouint(command + len, 0, &value)) {
+		if (value <= 0 || value > MAX_LIMIT) {
+			ret = -EINVAL;
+			goto out;
+		}
+
+		group->reg_limit = value;
+		ret = 0;
+		goto out;
+	}
+out:
+	user_event_group_release(group);
+
+	return ret;
 }
 
 static int user_event_ns_show(struct trace_namespace *ns, struct seq_file *m)
 {
+	struct user_event_group *group = user_event_group_find(ns->id);
+
+	if (!group)
+		return 0;
+
+	seq_printf(m, "%s%d\n", NS_EVENT_LIMIT_PREFIX, group->reg_limit);
+
+	user_event_group_release(group);
+
 	return 0;
 }
 
-- 
2.25.1


  parent reply	other threads:[~2022-07-28 23:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-28 23:52 [RFC PATCH v2 0/7] tracing: Add tracing namespace API for user Beau Belgrave
2022-07-28 23:52 ` [RFC PATCH v2 1/7] tracing/user_events: Remove BROKEN and restore user_events.h location Beau Belgrave
2022-07-28 23:52 ` [RFC PATCH v2 2/7] tracing: Add namespace instance directory to tracefs Beau Belgrave
2022-07-28 23:52 ` [RFC PATCH v2 3/7] tracing: Add tracing namespace API for systems to register with Beau Belgrave
2022-07-28 23:52 ` [RFC PATCH v2 4/7] tracing/user_events: Move pages/locks into groups to prepare for namespaces Beau Belgrave
2022-07-28 23:52 ` [RFC PATCH v2 5/7] tracing/user_events: Register with trace namespace API Beau Belgrave
2022-07-28 23:52 ` Beau Belgrave [this message]
2022-07-28 23:52 ` [RFC PATCH v2 7/7] tracing/user_events: Add self-test for namespace integration Beau Belgrave

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=20220728235241.2249-7-beaub@linux.microsoft.com \
    --to=beaub@linux.microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.