Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 28 Mar 2020 10:06:35 -0400
From:   Joel Fernandes <joel@joelfernandes.org>
To:     "Paul E. McKenney" <paulmck@kernel.org>
Cc:     Steven Rostedt <rostedt@goodmis.org>, rcu@vger.kernel.org,
        linux-kernel@vger.kernel.org, kernel-team@fb.com, mingo@kernel.org,
        jiangshanlai@gmail.com, dipankar@in.ibm.com,
        akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
        josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org,
        dhowells@redhat.com, edumazet@google.com, fweisbec@gmail.com,
        oleg@redhat.com, Alexei Starovoitov <alexei.starovoitov@gmail.com>,
        Andrii Nakryiko <andriin@fb.com>
Subject: Re: [PATCH RFC v2 tip/core/rcu 14/22] rcu-tasks: Add an RCU Tasks
 Trace to simplify protection of tracing hooks
Message-ID: <20200328140635.GA201808@google.com>
References: <20200319001024.GA28798@paulmck-ThinkPad-P72>
 <20200319001100.24917-14-paulmck@kernel.org>
 <20200319154239.6d67877d@gandalf.local.home>
 <20200320002813.GL3199@paulmck-ThinkPad-P72>
 <20200319204838.1f78152a@gandalf.local.home>
 <20200320024152.GM3199@paulmck-ThinkPad-P72>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200320024152.GM3199@paulmck-ThinkPad-P72>
User-Agent: Mutt/1.12.2 (2019-09-21)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Mar 19, 2020 at 07:41:53PM -0700, Paul E. McKenney wrote:
> On Thu, Mar 19, 2020 at 08:48:38PM -0400, Steven Rostedt wrote:
> > On Thu, 19 Mar 2020 17:28:13 -0700
> > "Paul E. McKenney" <paulmck@kernel.org> wrote:
> > 
> > > Good point.  If interrupts are disabled, it will need to use some
> > > other mechanism.  One approach is irqwork.  Another is a timer.
> > > 
> > > Suggestions?
> > 
> > Ftrace and perf use irq_work, I would think that should work here too.
> 
> Sounds good, will give it a go!  And thank you for catching this!

Since the the Tasks-RCU holdout thread is supposed to wake up periodically to
scan holdout tasks anyway, can it not detect the end of the Trace-RCU grace
period on its next wake up? Sorry if I missed something.

thanks,

 - Joel