[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230424213957.55c503c1@rorschach.local.home>
Date: Mon, 24 Apr 2023 21:39:57 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Beau Belgrave <beaub@...ux.microsoft.com>
Cc: mhiramat@...nel.org, mathieu.desnoyers@...icios.com,
dcook@...ux.microsoft.com, alanau@...ux.microsoft.com,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] tracing/user_events: Ensure bit is cleared on
unregister
On Tue, 11 Apr 2023 14:17:08 -0700
Beau Belgrave <beaub@...ux.microsoft.com> wrote:
> +static int user_event_mm_clear_bit(struct user_event_mm *user_mm,
> + unsigned long uaddr, unsigned char bit)
> +{
> + struct user_event_enabler enabler;
> + int result;
> +
> + memset(&enabler, 0, sizeof(enabler));
> + enabler.addr = uaddr;
> + enabler.values = bit;
> +retry:
> + /* Prevents state changes from racing with new enablers */
> + mutex_lock(&event_mutex);
> +
> + /* Force the bit to be cleared, since no event is attached */
> + mmap_read_lock(user_mm->mm);
> + result = user_event_enabler_write(user_mm, &enabler, false);
> + mmap_read_unlock(user_mm->mm);
> +
> + mutex_unlock(&event_mutex);
> +
> + if (result) {
> + /* Attempt to fault-in and retry if it worked */
> + if (!user_event_mm_fault_in(user_mm, uaddr))
> + goto retry;
Without looking into the functions of this call, I wonder if this can
get into an infinite loop?
-- Steve
> + }
> +
> + return result;
> +}
> +
Powered by blists - more mailing lists