On August 8, 2018 6:47:16 PM EDT, "Paul E. McKenney"
wrote:
>On Wed, Aug 08, 2018 at 03:15:31PM -0700, Joel Fernandes wrote:
>> On Wed, Aug 8, 2018 at 1:18 PM, Paul E. McKenney
>> wrote:
>> [...]
>> >> >> >> It does start to seem like a show stopper :-(
>> >> >> >
>> >> >> > I suppose that
On August 8, 2018 6:47:16 PM EDT, "Paul E. McKenney"
wrote:
>On Wed, Aug 08, 2018 at 03:15:31PM -0700, Joel Fernandes wrote:
>> On Wed, Aug 8, 2018 at 1:18 PM, Paul E. McKenney
>> wrote:
>> [...]
>> >> >> >> It does start to seem like a show stopper :-(
>> >> >> >
>> >> >> > I suppose that
On Wed, Aug 08, 2018 at 03:15:31PM -0700, Joel Fernandes wrote:
> On Wed, Aug 8, 2018 at 1:18 PM, Paul E. McKenney
> wrote:
> [...]
> >> >> >> It does start to seem like a show stopper :-(
> >> >> >
> >> >> > I suppose that an srcu_read_lock_nmi() and srcu_read_unlock_nmi()
> >> >> > could
> >>
On Wed, Aug 08, 2018 at 03:15:31PM -0700, Joel Fernandes wrote:
> On Wed, Aug 8, 2018 at 1:18 PM, Paul E. McKenney
> wrote:
> [...]
> >> >> >> It does start to seem like a show stopper :-(
> >> >> >
> >> >> > I suppose that an srcu_read_lock_nmi() and srcu_read_unlock_nmi()
> >> >> > could
> >>
On Wed, Aug 8, 2018 at 1:18 PM, Paul E. McKenney
wrote:
[...]
>> >> >> It does start to seem like a show stopper :-(
>> >> >
>> >> > I suppose that an srcu_read_lock_nmi() and srcu_read_unlock_nmi() could
>> >> > be added, which would do atomic ops on sp->sda->srcu_lock_count. Not
>> >> > sure
On Wed, Aug 8, 2018 at 1:18 PM, Paul E. McKenney
wrote:
[...]
>> >> >> It does start to seem like a show stopper :-(
>> >> >
>> >> > I suppose that an srcu_read_lock_nmi() and srcu_read_unlock_nmi() could
>> >> > be added, which would do atomic ops on sp->sda->srcu_lock_count. Not
>> >> > sure
On Wed, Aug 08, 2018 at 12:24:20PM -0700, Joel Fernandes wrote:
> On Wed, Aug 8, 2018 at 7:49 AM, Paul E. McKenney
> wrote:
> [...]
> >
> >> In that case based on what you're saying, the patch I sent to using
> >> different srcu_struct for NMI is still good I guess...
> >
> > As long as you wait
On Wed, Aug 08, 2018 at 12:24:20PM -0700, Joel Fernandes wrote:
> On Wed, Aug 8, 2018 at 7:49 AM, Paul E. McKenney
> wrote:
> [...]
> >
> >> In that case based on what you're saying, the patch I sent to using
> >> different srcu_struct for NMI is still good I guess...
> >
> > As long as you wait
On Wed, Aug 8, 2018 at 7:49 AM, Paul E. McKenney
wrote:
[...]
>
>> In that case based on what you're saying, the patch I sent to using
>> different srcu_struct for NMI is still good I guess...
>
> As long as you wait for both SRCU grace periods. Hmmm... Maybe that means
> that there is still a
On Wed, Aug 8, 2018 at 7:49 AM, Paul E. McKenney
wrote:
[...]
>
>> In that case based on what you're saying, the patch I sent to using
>> different srcu_struct for NMI is still good I guess...
>
> As long as you wait for both SRCU grace periods. Hmmm... Maybe that means
> that there is still a
On Wed, Aug 08, 2018 at 12:24:04PM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 09:02:43 -0700
> "Paul E. McKenney" wrote:
>
> > > Which leaves us with sparc, arm, mips, sh and powerpc.
> > >
> > > sh is almost dead, and powerpc can be fixed, which I guess leaves us
> > > with sparc, arm
On Wed, Aug 08, 2018 at 12:24:04PM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 09:02:43 -0700
> "Paul E. McKenney" wrote:
>
> > > Which leaves us with sparc, arm, mips, sh and powerpc.
> > >
> > > sh is almost dead, and powerpc can be fixed, which I guess leaves us
> > > with sparc, arm
On Wed, 8 Aug 2018 09:02:43 -0700
"Paul E. McKenney" wrote:
> > Which leaves us with sparc, arm, mips, sh and powerpc.
> >
> > sh is almost dead, and powerpc can be fixed, which I guess leaves us
> > with sparc, arm and mips.
>
> If we want to stick with the current srcu_read_lock() and
On Wed, 8 Aug 2018 09:02:43 -0700
"Paul E. McKenney" wrote:
> > Which leaves us with sparc, arm, mips, sh and powerpc.
> >
> > sh is almost dead, and powerpc can be fixed, which I guess leaves us
> > with sparc, arm and mips.
>
> If we want to stick with the current srcu_read_lock() and
On Wed, Aug 08, 2018 at 11:27:05AM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 07:42:00 -0700
> "Paul E. McKenney" wrote:
>
> > > There's also a local_inc() if you are using per cpu pointers, that is
> > > suppose to guarantee atomicity for single cpu operations. That's what
> > > the
On Wed, Aug 08, 2018 at 11:27:05AM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 07:42:00 -0700
> "Paul E. McKenney" wrote:
>
> > > There's also a local_inc() if you are using per cpu pointers, that is
> > > suppose to guarantee atomicity for single cpu operations. That's what
> > > the
On Wed, Aug 08, 2018 at 11:23:09AM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 08:05:58 -0700
> "Paul E. McKenney" wrote:
>
> > On Wed, Aug 08, 2018 at 10:49:10AM -0400, Steven Rostedt wrote:
> > > On Wed, 8 Aug 2018 07:33:10 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > > On Wed,
On Wed, Aug 08, 2018 at 11:23:09AM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 08:05:58 -0700
> "Paul E. McKenney" wrote:
>
> > On Wed, Aug 08, 2018 at 10:49:10AM -0400, Steven Rostedt wrote:
> > > On Wed, 8 Aug 2018 07:33:10 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > > On Wed,
On Wed, 8 Aug 2018 07:42:00 -0700
"Paul E. McKenney" wrote:
> > There's also a local_inc() if you are using per cpu pointers, that is
> > suppose to guarantee atomicity for single cpu operations. That's what
> > the ftrace ring buffer uses.
>
> Good point, that becomes atomic_long_inc() or
On Wed, 8 Aug 2018 07:42:00 -0700
"Paul E. McKenney" wrote:
> > There's also a local_inc() if you are using per cpu pointers, that is
> > suppose to guarantee atomicity for single cpu operations. That's what
> > the ftrace ring buffer uses.
>
> Good point, that becomes atomic_long_inc() or
On Wed, 8 Aug 2018 08:05:58 -0700
"Paul E. McKenney" wrote:
> On Wed, Aug 08, 2018 at 10:49:10AM -0400, Steven Rostedt wrote:
> > On Wed, 8 Aug 2018 07:33:10 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Wed, Aug 08, 2018 at 09:07:24AM -0400, Steven Rostedt wrote:
> > > > On Wed, 8 Aug
On Wed, 8 Aug 2018 08:05:58 -0700
"Paul E. McKenney" wrote:
> On Wed, Aug 08, 2018 at 10:49:10AM -0400, Steven Rostedt wrote:
> > On Wed, 8 Aug 2018 07:33:10 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Wed, Aug 08, 2018 at 09:07:24AM -0400, Steven Rostedt wrote:
> > > > On Wed, 8 Aug
On Wed, Aug 08, 2018 at 10:49:10AM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 07:33:10 -0700
> "Paul E. McKenney" wrote:
>
> > On Wed, Aug 08, 2018 at 09:07:24AM -0400, Steven Rostedt wrote:
> > > On Wed, 8 Aug 2018 06:03:02 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > > What's
On Wed, Aug 08, 2018 at 10:49:10AM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 07:33:10 -0700
> "Paul E. McKenney" wrote:
>
> > On Wed, Aug 08, 2018 at 09:07:24AM -0400, Steven Rostedt wrote:
> > > On Wed, 8 Aug 2018 06:03:02 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > > What's
On Wed, Aug 08, 2018 at 07:10:53AM -0700, Joel Fernandes wrote:
> On Wed, Aug 8, 2018 at 6:00 AM, Paul E. McKenney
> wrote:
> > On Tue, Aug 07, 2018 at 08:53:54PM -0700, Joel Fernandes wrote:
> >> On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote:
> >> > Hi Steve,
> >> >
> >> > On Tue, Aug 7,
On Wed, Aug 08, 2018 at 07:10:53AM -0700, Joel Fernandes wrote:
> On Wed, Aug 8, 2018 at 6:00 AM, Paul E. McKenney
> wrote:
> > On Tue, Aug 07, 2018 at 08:53:54PM -0700, Joel Fernandes wrote:
> >> On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote:
> >> > Hi Steve,
> >> >
> >> > On Tue, Aug 7,
On Wed, 8 Aug 2018 07:33:10 -0700
"Paul E. McKenney" wrote:
> On Wed, Aug 08, 2018 at 09:07:24AM -0400, Steven Rostedt wrote:
> > On Wed, 8 Aug 2018 06:03:02 -0700
> > "Paul E. McKenney" wrote:
> >
> > > What's wrong with a this_cpu_inc()? It's atomic for the CPU. Although
> > > > it wont
On Wed, 8 Aug 2018 07:33:10 -0700
"Paul E. McKenney" wrote:
> On Wed, Aug 08, 2018 at 09:07:24AM -0400, Steven Rostedt wrote:
> > On Wed, 8 Aug 2018 06:03:02 -0700
> > "Paul E. McKenney" wrote:
> >
> > > What's wrong with a this_cpu_inc()? It's atomic for the CPU. Although
> > > > it wont
On Wed, Aug 08, 2018 at 10:27:00AM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 06:00:41 -0700
> "Paul E. McKenney" wrote:
> >
> > I suppose that an srcu_read_lock_nmi() and srcu_read_unlock_nmi() could
> > be added, which would do atomic ops on sp->sda->srcu_lock_count. Not sure
> >
On Wed, Aug 08, 2018 at 10:27:00AM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 06:00:41 -0700
> "Paul E. McKenney" wrote:
> >
> > I suppose that an srcu_read_lock_nmi() and srcu_read_unlock_nmi() could
> > be added, which would do atomic ops on sp->sda->srcu_lock_count. Not sure
> >
On Wed, Aug 08, 2018 at 09:07:24AM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 06:03:02 -0700
> "Paul E. McKenney" wrote:
>
> > What's wrong with a this_cpu_inc()? It's atomic for the CPU. Although
> > > it wont be atomic for the capture of the idx. But I also don't see
> > > interrupts
On Wed, Aug 08, 2018 at 09:07:24AM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 06:03:02 -0700
> "Paul E. McKenney" wrote:
>
> > What's wrong with a this_cpu_inc()? It's atomic for the CPU. Although
> > > it wont be atomic for the capture of the idx. But I also don't see
> > > interrupts
On Wed, 8 Aug 2018 06:00:41 -0700
"Paul E. McKenney" wrote:
>
> I suppose that an srcu_read_lock_nmi() and srcu_read_unlock_nmi() could
> be added, which would do atomic ops on sp->sda->srcu_lock_count. Not sure
> whether this would be fast enough to be useful, but easy to provide:
>
> int
On Wed, 8 Aug 2018 06:00:41 -0700
"Paul E. McKenney" wrote:
>
> I suppose that an srcu_read_lock_nmi() and srcu_read_unlock_nmi() could
> be added, which would do atomic ops on sp->sda->srcu_lock_count. Not sure
> whether this would be fast enough to be useful, but easy to provide:
>
> int
On Wed, Aug 8, 2018 at 6:00 AM, Paul E. McKenney
wrote:
> On Tue, Aug 07, 2018 at 08:53:54PM -0700, Joel Fernandes wrote:
>> On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote:
>> > Hi Steve,
>> >
>> > On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
>> [...]
>> >>> @@ -171,8 +174,7 @@
On Wed, Aug 8, 2018 at 6:00 AM, Paul E. McKenney
wrote:
> On Tue, Aug 07, 2018 at 08:53:54PM -0700, Joel Fernandes wrote:
>> On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote:
>> > Hi Steve,
>> >
>> > On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
>> [...]
>> >>> @@ -171,8 +174,7 @@
On Wed, 8 Aug 2018 06:03:02 -0700
"Paul E. McKenney" wrote:
> What's wrong with a this_cpu_inc()? It's atomic for the CPU. Although
> > it wont be atomic for the capture of the idx. But I also don't see
> > interrupts being disabled, thus an NMI is no different than any
> > interrupt doing the
On Wed, 8 Aug 2018 06:03:02 -0700
"Paul E. McKenney" wrote:
> What's wrong with a this_cpu_inc()? It's atomic for the CPU. Although
> > it wont be atomic for the capture of the idx. But I also don't see
> > interrupts being disabled, thus an NMI is no different than any
> > interrupt doing the
On Wed, Aug 08, 2018 at 08:46:29AM -0400, Steven Rostedt wrote:
> On Tue, 7 Aug 2018 20:53:54 -0700
> Joel Fernandes wrote:
>
>
> > > When I talked to Paul few months ago about SRCU from NMI context, he
> > > mentioned the per-cpu memory operations during srcu_read_lock can be
> > > NMI
On Wed, Aug 08, 2018 at 08:46:29AM -0400, Steven Rostedt wrote:
> On Tue, 7 Aug 2018 20:53:54 -0700
> Joel Fernandes wrote:
>
>
> > > When I talked to Paul few months ago about SRCU from NMI context, he
> > > mentioned the per-cpu memory operations during srcu_read_lock can be
> > > NMI
On Tue, Aug 07, 2018 at 08:53:54PM -0700, Joel Fernandes wrote:
> On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote:
> > Hi Steve,
> >
> > On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
> [...]
> >>> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
> >>> }
On Tue, Aug 07, 2018 at 08:53:54PM -0700, Joel Fernandes wrote:
> On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote:
> > Hi Steve,
> >
> > On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
> [...]
> >>> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
> >>> }
On Tue, 7 Aug 2018 20:53:54 -0700
Joel Fernandes wrote:
> > When I talked to Paul few months ago about SRCU from NMI context, he
> > mentioned the per-cpu memory operations during srcu_read_lock can be
> > NMI interrupted, that's why we added that warning.
>
> So I looked more closely,
On Tue, 7 Aug 2018 20:53:54 -0700
Joel Fernandes wrote:
> > When I talked to Paul few months ago about SRCU from NMI context, he
> > mentioned the per-cpu memory operations during srcu_read_lock can be
> > NMI interrupted, that's why we added that warning.
>
> So I looked more closely,
On Tue, Aug 7, 2018 at 8:53 PM, Joel Fernandes wrote:
> On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote:
>> Hi Steve,
>>
>> On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
> [...]
@@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
} while
On Tue, Aug 7, 2018 at 8:53 PM, Joel Fernandes wrote:
> On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote:
>> Hi Steve,
>>
>> On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
> [...]
@@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
} while
On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote:
> Hi Steve,
>
> On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
[...]
>>> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
>>> } while ((++it_func_ptr)->func);\
>>> }
On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote:
> Hi Steve,
>
> On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
[...]
>>> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
>>> } while ((++it_func_ptr)->func);\
>>> }
Hi Steve,
On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
> On Tue, 7 Aug 2018 19:13:32 -0700
> Joel Fernandes wrote:
>> >
>> >> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
>> >> From: "Joel Fernandes (Google)"
>> >> Date: Sun, 5 Aug 2018 20:17:41 -0700
>> >>
Hi Steve,
On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
> On Tue, 7 Aug 2018 19:13:32 -0700
> Joel Fernandes wrote:
>> >
>> >> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
>> >> From: "Joel Fernandes (Google)"
>> >> Date: Sun, 5 Aug 2018 20:17:41 -0700
>> >>
On Tue, 7 Aug 2018 19:13:32 -0700
Joel Fernandes wrote:
> On Tue, Aug 7, 2018 at 6:55 PM, Steven Rostedt wrote:
> > On Tue, 7 Aug 2018 18:17:42 -0700
> > Joel Fernandes wrote:
> >
> >> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
> >> From: "Joel Fernandes (Google)"
On Tue, 7 Aug 2018 19:13:32 -0700
Joel Fernandes wrote:
> On Tue, Aug 7, 2018 at 6:55 PM, Steven Rostedt wrote:
> > On Tue, 7 Aug 2018 18:17:42 -0700
> > Joel Fernandes wrote:
> >
> >> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
> >> From: "Joel Fernandes (Google)"
On Tue, Aug 7, 2018 at 6:55 PM, Steven Rostedt wrote:
> On Tue, 7 Aug 2018 18:17:42 -0700
> Joel Fernandes wrote:
>
>> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
>> From: "Joel Fernandes (Google)"
>> Date: Sun, 5 Aug 2018 20:17:41 -0700
>> Subject: [PATCH]
On Tue, Aug 7, 2018 at 6:55 PM, Steven Rostedt wrote:
> On Tue, 7 Aug 2018 18:17:42 -0700
> Joel Fernandes wrote:
>
>> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
>> From: "Joel Fernandes (Google)"
>> Date: Sun, 5 Aug 2018 20:17:41 -0700
>> Subject: [PATCH]
On Tue, 7 Aug 2018 18:17:42 -0700
Joel Fernandes wrote:
> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
> From: "Joel Fernandes (Google)"
> Date: Sun, 5 Aug 2018 20:17:41 -0700
> Subject: [PATCH] tracepoint: Run tracepoints even after CPU is offline
>
> Commit
On Tue, 7 Aug 2018 18:17:42 -0700
Joel Fernandes wrote:
> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
> From: "Joel Fernandes (Google)"
> Date: Sun, 5 Aug 2018 20:17:41 -0700
> Subject: [PATCH] tracepoint: Run tracepoints even after CPU is offline
>
> Commit
On Tue, Aug 7, 2018 at 5:48 PM, Steven Rostedt wrote:
> On Tue, 07 Aug 2018 19:54:13 -0400
> Joel Fernandes wrote:
>
>
>> >OK, I hit this bug, but it's not because of the partial revert. This
>> >bug seems it needs to be another partial revert. I like you movement of
>> >the code, but I'm
On Tue, Aug 7, 2018 at 5:48 PM, Steven Rostedt wrote:
> On Tue, 07 Aug 2018 19:54:13 -0400
> Joel Fernandes wrote:
>
>
>> >OK, I hit this bug, but it's not because of the partial revert. This
>> >bug seems it needs to be another partial revert. I like you movement of
>> >the code, but I'm
On Tue, 07 Aug 2018 19:54:13 -0400
Joel Fernandes wrote:
> >OK, I hit this bug, but it's not because of the partial revert. This
> >bug seems it needs to be another partial revert. I like you movement of
> >the code, but I'm starting to doubt that we can use a trace event as a
> >hook for
On Tue, 07 Aug 2018 19:54:13 -0400
Joel Fernandes wrote:
> >OK, I hit this bug, but it's not because of the partial revert. This
> >bug seems it needs to be another partial revert. I like you movement of
> >the code, but I'm starting to doubt that we can use a trace event as a
> >hook for
On August 7, 2018 7:45:15 PM EDT, Steven Rostedt wrote:
>On Tue, 07 Aug 2018 11:24:13 -0400
>Joel Fernandes wrote:
>
>> On August 7, 2018 11:09:06 AM EDT, Steven Rostedt
> wrote:
>> >On Tue, 07 Aug 2018 10:48:05 -0400
>> >Joel Fernandes wrote:
>> >
>> >> >You mean if someone add a
On August 7, 2018 7:45:15 PM EDT, Steven Rostedt wrote:
>On Tue, 07 Aug 2018 11:24:13 -0400
>Joel Fernandes wrote:
>
>> On August 7, 2018 11:09:06 AM EDT, Steven Rostedt
> wrote:
>> >On Tue, 07 Aug 2018 10:48:05 -0400
>> >Joel Fernandes wrote:
>> >
>> >> >You mean if someone add a
On Tue, 07 Aug 2018 11:24:13 -0400
Joel Fernandes wrote:
> On August 7, 2018 11:09:06 AM EDT, Steven Rostedt wrote:
> >On Tue, 07 Aug 2018 10:48:05 -0400
> >Joel Fernandes wrote:
> >
> >> >You mean if someone add a tracepoint callback to the irq disable
> >> >tracepoint, and did a lockdep
On Tue, 07 Aug 2018 11:24:13 -0400
Joel Fernandes wrote:
> On August 7, 2018 11:09:06 AM EDT, Steven Rostedt wrote:
> >On Tue, 07 Aug 2018 10:48:05 -0400
> >Joel Fernandes wrote:
> >
> >> >You mean if someone add a tracepoint callback to the irq disable
> >> >tracepoint, and did a lockdep
On August 7, 2018 11:09:06 AM EDT, Steven Rostedt wrote:
>On Tue, 07 Aug 2018 10:48:05 -0400
>Joel Fernandes wrote:
>
>> >You mean if someone add a tracepoint callback to the irq disable
>> >tracepoint, and did a lockdep assert to make sure interrupts are
>> >disabled?
>>
>> Yes that's
On August 7, 2018 11:09:06 AM EDT, Steven Rostedt wrote:
>On Tue, 07 Aug 2018 10:48:05 -0400
>Joel Fernandes wrote:
>
>> >You mean if someone add a tracepoint callback to the irq disable
>> >tracepoint, and did a lockdep assert to make sure interrupts are
>> >disabled?
>>
>> Yes that's
On Tue, 07 Aug 2018 10:48:05 -0400
Joel Fernandes wrote:
> >You mean if someone add a tracepoint callback to the irq disable
> >tracepoint, and did a lockdep assert to make sure interrupts are
> >disabled?
>
> Yes that's what I meant.
That sounds like a "Doctor, it hurts me when I do this"
On Tue, 07 Aug 2018 10:48:05 -0400
Joel Fernandes wrote:
> >You mean if someone add a tracepoint callback to the irq disable
> >tracepoint, and did a lockdep assert to make sure interrupts are
> >disabled?
>
> Yes that's what I meant.
That sounds like a "Doctor, it hurts me when I do this"
On August 7, 2018 10:34:10 AM EDT, Steven Rostedt wrote:
>On Tue, 07 Aug 2018 10:10:59 -0400
>Joel Fernandes wrote:
>
>> On August 7, 2018 9:49:54 AM EDT, Steven Rostedt
> wrote:
>> >On Tue, 7 Aug 2018 06:33:35 -0700
>> >Joel Fernandes wrote:
>> >
>> >> Thanks, also one more thing I
On August 7, 2018 10:34:10 AM EDT, Steven Rostedt wrote:
>On Tue, 07 Aug 2018 10:10:59 -0400
>Joel Fernandes wrote:
>
>> On August 7, 2018 9:49:54 AM EDT, Steven Rostedt
> wrote:
>> >On Tue, 7 Aug 2018 06:33:35 -0700
>> >Joel Fernandes wrote:
>> >
>> >> Thanks, also one more thing I
On Tue, 07 Aug 2018 10:10:59 -0400
Joel Fernandes wrote:
> On August 7, 2018 9:49:54 AM EDT, Steven Rostedt wrote:
> >On Tue, 7 Aug 2018 06:33:35 -0700
> >Joel Fernandes wrote:
> >
> >> Thanks, also one more thing I noticed in your patch,
> >> lockdep_hardirqs_off needs to be called before
On Tue, 07 Aug 2018 10:10:59 -0400
Joel Fernandes wrote:
> On August 7, 2018 9:49:54 AM EDT, Steven Rostedt wrote:
> >On Tue, 7 Aug 2018 06:33:35 -0700
> >Joel Fernandes wrote:
> >
> >> Thanks, also one more thing I noticed in your patch,
> >> lockdep_hardirqs_off needs to be called before
On August 7, 2018 9:49:54 AM EDT, Steven Rostedt wrote:
>On Tue, 7 Aug 2018 06:33:35 -0700
>Joel Fernandes wrote:
>
>> Thanks, also one more thing I noticed in your patch,
>> lockdep_hardirqs_off needs to be called before all other probes but
>> you're calling it after. This is why I
On August 7, 2018 9:49:54 AM EDT, Steven Rostedt wrote:
>On Tue, 7 Aug 2018 06:33:35 -0700
>Joel Fernandes wrote:
>
>> Thanks, also one more thing I noticed in your patch,
>> lockdep_hardirqs_off needs to be called before all other probes but
>> you're calling it after. This is why I
On Tue, 7 Aug 2018 06:33:35 -0700
Joel Fernandes wrote:
> Thanks, also one more thing I noticed in your patch,
> lockdep_hardirqs_off needs to be called before all other probes but
> you're calling it after. This is why I registered it with INT_MAX:
>
>
On Tue, 7 Aug 2018 06:33:35 -0700
Joel Fernandes wrote:
> Thanks, also one more thing I noticed in your patch,
> lockdep_hardirqs_off needs to be called before all other probes but
> you're calling it after. This is why I registered it with INT_MAX:
>
>
On Mon, Aug 6, 2018 at 6:43 PM, Steven Rostedt wrote:
> On Mon, 6 Aug 2018 17:43:19 -0700
> Joel Fernandes wrote:
>
>> On Mon, Aug 6, 2018 at 12:50 PM, Steven Rostedt wrote:
>> >
>> > With this patch applied, I'm constantly getting lockdep errors. Instead
>> > of doing a full revert of the
On Mon, Aug 6, 2018 at 6:43 PM, Steven Rostedt wrote:
> On Mon, 6 Aug 2018 17:43:19 -0700
> Joel Fernandes wrote:
>
>> On Mon, Aug 6, 2018 at 12:50 PM, Steven Rostedt wrote:
>> >
>> > With this patch applied, I'm constantly getting lockdep errors. Instead
>> > of doing a full revert of the
On Mon, 6 Aug 2018 17:43:19 -0700
Joel Fernandes wrote:
> On Mon, Aug 6, 2018 at 12:50 PM, Steven Rostedt wrote:
> >
> > With this patch applied, I'm constantly getting lockdep errors. Instead
> > of doing a full revert of the patch, I did this, which makes all those
> > errors go away. I may
On Mon, 6 Aug 2018 17:43:19 -0700
Joel Fernandes wrote:
> On Mon, Aug 6, 2018 at 12:50 PM, Steven Rostedt wrote:
> >
> > With this patch applied, I'm constantly getting lockdep errors. Instead
> > of doing a full revert of the patch, I did this, which makes all those
> > errors go away. I may
On Mon, Aug 6, 2018 at 12:50 PM, Steven Rostedt wrote:
>
> With this patch applied, I'm constantly getting lockdep errors. Instead
> of doing a full revert of the patch, I did this, which makes all those
> errors go away. I may apply this for now, and we can revisit having
> lockdep use the
On Mon, Aug 6, 2018 at 12:50 PM, Steven Rostedt wrote:
>
> With this patch applied, I'm constantly getting lockdep errors. Instead
> of doing a full revert of the patch, I did this, which makes all those
> errors go away. I may apply this for now, and we can revisit having
> lockdep use the
With this patch applied, I'm constantly getting lockdep errors. Instead
of doing a full revert of the patch, I did this, which makes all those
errors go away. I may apply this for now, and we can revisit having
lockdep use the tracepoint code. But since it's currently always
enabled, I'm
With this patch applied, I'm constantly getting lockdep errors. Instead
of doing a full revert of the patch, I did this, which makes all those
errors go away. I may apply this for now, and we can revisit having
lockdep use the tracepoint code. But since it's currently always
enabled, I'm
From: "Joel Fernandes (Google)"
This patch detaches the preemptirq tracepoints from the tracers and
keeps it separate.
Advantages:
* Lockdep and irqsoff event can now run in parallel since they no longer
have their own calls.
* This unifies the usecase of adding hooks to an irqsoff and irqson
From: "Joel Fernandes (Google)"
This patch detaches the preemptirq tracepoints from the tracers and
keeps it separate.
Advantages:
* Lockdep and irqsoff event can now run in parallel since they no longer
have their own calls.
* This unifies the usecase of adding hooks to an irqsoff and irqson
86 matches
Mail list logo
