On Fri, Apr 5, 2024 at 8:41 PM Masami Hiramatsu wrote:
>
> On Tue, 2 Apr 2024 22:21:00 -0700
> Andrii Nakryiko wrote:
>
> > On Tue, Apr 2, 2024 at 9:00 PM Andrii Nakryiko
> > wrote:
> > >
> > > On Tue, Apr 2, 2024 at 5:52 PM Steven Rostedt wrote:
> > > >
> > > > On Wed, 3 Apr 2024 09:40:48
On Tue, 2 Apr 2024 22:21:00 -0700
Andrii Nakryiko wrote:
> On Tue, Apr 2, 2024 at 9:00 PM Andrii Nakryiko
> wrote:
> >
> > On Tue, Apr 2, 2024 at 5:52 PM Steven Rostedt wrote:
> > >
> > > On Wed, 3 Apr 2024 09:40:48 +0900
> > > Masami Hiramatsu (Google) wrote:
> > >
> > > > OK, for me, this
On Tue, 2 Apr 2024 22:21:00 -0700
Andrii Nakryiko wrote:
> > I just checked our fleet-wide production data for the last 24 hours.
> > Within the kprobe/kretprobe code path (ftrace_trampoline and
> > everything called from it), rcu_is_watching (both calls, see below)
> > cause 0.484% CPU cycles
On Tue, 2 Apr 2024 21:00:19 -0700
Andrii Nakryiko wrote:
> I just noticed another rcu_is_watching() call, in rethook_try_get(),
> which seems to be a similar and complementary validation check to the
> one we are putting under CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING option
> in this patch. It
On Tue, Apr 2, 2024 at 9:00 PM Andrii Nakryiko
wrote:
>
> On Tue, Apr 2, 2024 at 5:52 PM Steven Rostedt wrote:
> >
> > On Wed, 3 Apr 2024 09:40:48 +0900
> > Masami Hiramatsu (Google) wrote:
> >
> > > OK, for me, this last sentence is preferred for the help message. That
> > > explains
> > >
On Tue, Apr 2, 2024 at 5:52 PM Steven Rostedt wrote:
>
> On Wed, 3 Apr 2024 09:40:48 +0900
> Masami Hiramatsu (Google) wrote:
>
> > OK, for me, this last sentence is preferred for the help message. That
> > explains
> > what this is for.
> >
> > All callbacks that attach to the function
On Wed, 3 Apr 2024 09:40:48 +0900
Masami Hiramatsu (Google) wrote:
> OK, for me, this last sentence is preferred for the help message. That
> explains
> what this is for.
>
> All callbacks that attach to the function tracing have some sort
> of protection against recursion.
On Mon, 1 Apr 2024 22:47:33 -0400
Steven Rostedt wrote:
> On Mon, 1 Apr 2024 19:29:46 -0700
> Andrii Nakryiko wrote:
>
> > On Mon, Apr 1, 2024 at 5:38 PM Masami Hiramatsu wrote:
> > >
> > > On Mon, 1 Apr 2024 12:09:18 -0400
> > > Steven Rostedt wrote:
> > >
> > > > On Mon, 1 Apr 2024
On Mon, 1 Apr 2024 19:29:46 -0700
Andrii Nakryiko wrote:
> On Mon, Apr 1, 2024 at 5:38 PM Masami Hiramatsu wrote:
> >
> > On Mon, 1 Apr 2024 12:09:18 -0400
> > Steven Rostedt wrote:
> >
> > > On Mon, 1 Apr 2024 20:25:52 +0900
> > > Masami Hiramatsu (Google) wrote:
> > >
> > > > > Masami,
On Mon, Apr 1, 2024 at 5:38 PM Masami Hiramatsu wrote:
>
> On Mon, 1 Apr 2024 12:09:18 -0400
> Steven Rostedt wrote:
>
> > On Mon, 1 Apr 2024 20:25:52 +0900
> > Masami Hiramatsu (Google) wrote:
> >
> > > > Masami,
> > > >
> > > > Are you OK with just keeping it set to N.
> > >
> > > OK, if it
On Mon, 1 Apr 2024 12:09:18 -0400
Steven Rostedt wrote:
> On Mon, 1 Apr 2024 20:25:52 +0900
> Masami Hiramatsu (Google) wrote:
>
> > > Masami,
> > >
> > > Are you OK with just keeping it set to N.
> >
> > OK, if it is only for the debugging, I'm OK to set N this.
> >
> > >
> > > We could
On Mon, 1 Apr 2024 20:25:52 +0900
Masami Hiramatsu (Google) wrote:
> > Masami,
> >
> > Are you OK with just keeping it set to N.
>
> OK, if it is only for the debugging, I'm OK to set N this.
>
> >
> > We could have other options like PROVE_LOCKING enable it.
>
> Agreed (but it should
On Tue, 26 Mar 2024 15:01:21 -0400
Steven Rostedt wrote:
> On Tue, 26 Mar 2024 09:16:33 -0700
> Andrii Nakryiko wrote:
>
> > > It's no different than lockdep. Test boxes should have it enabled, but
> > > there's no reason to have this enabled in a production system.
> > >
> >
> > I tend to
On Tue, Mar 26, 2024 at 11:58 AM Steven Rostedt wrote:
>
> On Tue, 26 Mar 2024 09:16:33 -0700
> Andrii Nakryiko wrote:
>
> > > It's no different than lockdep. Test boxes should have it enabled, but
> > > there's no reason to have this enabled in a production system.
> > >
> >
> > I tend to agree
On Tue, 26 Mar 2024 09:16:33 -0700
Andrii Nakryiko wrote:
> > It's no different than lockdep. Test boxes should have it enabled, but
> > there's no reason to have this enabled in a production system.
> >
>
> I tend to agree with Steven here (which is why I sent this patch as it
> is), but I'm
On Mon, Mar 25, 2024 at 3:11 PM Steven Rostedt wrote:
>
> On Mon, 25 Mar 2024 11:38:48 +0900
> Masami Hiramatsu (Google) wrote:
>
> > On Fri, 22 Mar 2024 09:03:23 -0700
> > Andrii Nakryiko wrote:
> >
> > > Introduce CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING config option to
> > > control whether
On Mon, 25 Mar 2024 11:38:48 +0900
Masami Hiramatsu (Google) wrote:
> On Fri, 22 Mar 2024 09:03:23 -0700
> Andrii Nakryiko wrote:
>
> > Introduce CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING config option to
> > control whether ftrace low-level code performs additional
> > rcu_is_watching()-based
On Sun, Mar 24, 2024 at 7:38 PM Masami Hiramatsu wrote:
>
> On Fri, 22 Mar 2024 09:03:23 -0700
> Andrii Nakryiko wrote:
>
> > Introduce CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING config option to
> > control whether ftrace low-level code performs additional
> > rcu_is_watching()-based validation
On Fri, 22 Mar 2024 09:03:23 -0700
Andrii Nakryiko wrote:
> Introduce CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING config option to
> control whether ftrace low-level code performs additional
> rcu_is_watching()-based validation logic in an attempt to catch noinstr
> violations.
>
> This check is
Introduce CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING config option to
control whether ftrace low-level code performs additional
rcu_is_watching()-based validation logic in an attempt to catch noinstr
violations.
This check is expected to never be true in practice and would be best
controlled with
20 matches
Mail list logo
