All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Beau Belgrave <beaub@linux.microsoft.com>
Cc: mhiramat@kernel.org, linux-trace-devel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 02/13] user_events: Add minimal support for trace_event into ftrace
Date: Thu, 9 Dec 2021 12:47:35 -0500	[thread overview]
Message-ID: <20211209124735.3d1a9707@gandalf.local.home> (raw)
In-Reply-To: <20211209174050.GA21553@kbox>

On Thu, 9 Dec 2021 09:40:50 -0800
Beau Belgrave <beaub@linux.microsoft.com> wrote:

> No, this is not a fast path, and I don't have a problem moving to a
> mutex if you feel that is better. I've likely become too close to this
> code to know when things are confusing for others.

Yeah. I really dislike the "protection by algorithms" then protection by
locking unless it is a fast path.

If this was a fast path then I'd be more concerned. I dislike global locks
as well, but unless contention becomes a concern, I don't think we should
worry about it.

Also, for this comment:

+static int user_events_release(struct inode *node, struct file *file)
+{
+	struct user_event_refs *refs;
+	struct user_event *user;
+	int i;
+
+	/*
+	 * refs is protected by RCU and could in theory change immediately
+	 * before this call on another core. To ensure we read the latest
+	 * version of refs we acquire the RCU read lock again.
+	 */
+	rcu_read_lock_sched();
+	refs = rcu_dereference_sched(file->private_data);
+	rcu_read_unlock_sched();

How do you see refs changing on another core if this can only be called
when nothing has a reference to it?

I think this comment and grabbing the rcu locks is what is causing me
concern.

-- Steve

  reply	other threads:[~2021-12-09 17:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-01 18:25 [PATCH v6 00/13] user_events: Enable user processes to create and write to trace events Beau Belgrave
2021-12-01 18:25 ` [PATCH v6 01/13] user_events: Add UABI header for user access to user_events Beau Belgrave
2021-12-01 18:25 ` [PATCH v6 02/13] user_events: Add minimal support for trace_event into ftrace Beau Belgrave
2021-12-08 23:19   ` Steven Rostedt
2021-12-09  0:58     ` Beau Belgrave
2021-12-09  2:03       ` Steven Rostedt
2021-12-09 17:40         ` Beau Belgrave
2021-12-09 17:47           ` Steven Rostedt [this message]
2021-12-09 19:42             ` Beau Belgrave
2021-12-09 19:57               ` Steven Rostedt
2021-12-09 20:11                 ` Beau Belgrave
2021-12-09 20:19                   ` Steven Rostedt
2021-12-01 18:25 ` [PATCH v6 03/13] user_events: Add print_fmt generation support for basic types Beau Belgrave
2021-12-01 18:25 ` [PATCH v6 04/13] user_events: Handle matching arguments from dyn_events Beau Belgrave
2021-12-01 18:25 ` [PATCH v6 05/13] user_events: Add basic perf and eBPF support Beau Belgrave
2021-12-01 18:25 ` [PATCH v6 06/13] user_events: Add self-test for ftrace integration Beau Belgrave
2021-12-01 18:25 ` [PATCH v6 07/13] user_events: Add self-test for dynamic_events integration Beau Belgrave
2021-12-01 18:25 ` [PATCH v6 08/13] user_events: Add self-test for perf_event integration Beau Belgrave
2021-12-01 18:25 ` [PATCH v6 09/13] user_events: Optimize writing events by only copying data once Beau Belgrave
2021-12-01 18:25 ` [PATCH v6 10/13] user_events: Add documentation file Beau Belgrave
2021-12-01 18:25 ` [PATCH v6 11/13] user_events: Add sample code for typical usage Beau Belgrave
2021-12-01 18:25 ` [PATCH v6 12/13] user_events: Validate user payloads for size and null termination Beau Belgrave
2021-12-01 18:25 ` [PATCH v6 13/13] user_events: Use __get_rel_str for relative string fields 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=20211209124735.3d1a9707@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=beaub@linux.microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=mhiramat@kernel.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.