On Mon, Jul 01, 2019 at 04:00:53PM +0200, Peter Zijlstra wrote:
> On Mon, Jul 01, 2019 at 05:23:05AM -0700, Paul E. McKenney wrote:
> > On Mon, Jul 01, 2019 at 12:24:42PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2019-07-01 11:42:15 [+0200], Peter Zijlstra wrote:
> > > > I'm not sure if smp_
On Mon, Jul 01, 2019 at 05:23:05AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 01, 2019 at 12:24:42PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2019-07-01 11:42:15 [+0200], Peter Zijlstra wrote:
> > > I'm not sure if smp_send_reschedule() can be used as self-IPI, some
> > > hardware doesn't p
On Mon, Jul 01, 2019 at 12:24:42PM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-07-01 11:42:15 [+0200], Peter Zijlstra wrote:
> > I'm not sure if smp_send_reschedule() can be used as self-IPI, some
> > hardware doesn't particularly like that IIRC. That is, hardware might
> > only have interfac
On 2019-07-01 11:42:15 [+0200], Peter Zijlstra wrote:
> I'm not sure if smp_send_reschedule() can be used as self-IPI, some
> hardware doesn't particularly like that IIRC. That is, hardware might
> only have interfaces to IPI _other_ CPUs, but not self.
>
> The normal scheduler code takes care to
On Fri, Jun 28, 2019 at 03:01:36PM -0500, Scott Wood wrote:
> On Fri, 2019-06-28 at 16:15 +0200, Peter Zijlstra wrote:
> > On Thu, Jun 27, 2019 at 01:36:12PM -0700, Paul E. McKenney wrote:
> > > On Thu, Jun 27, 2019 at 03:17:27PM -0500, Scott Wood wrote:
> > > > On Thu, 2019-06-27 at 11:41 -0700, P
On Fri, Jun 28, 2019 at 10:20:56AM -0700, Paul E. McKenney wrote:
> On Fri, Jun 28, 2019 at 06:04:08PM +0200, Peter Zijlstra wrote:
> > On Fri, Jun 28, 2019 at 08:54:04AM -0700, Paul E. McKenney wrote:
> > > Thank you! Plus it looks like scheduler_ipi() takes an early exit if
> > > ->wake_list is
On Fri, Jun 28, 2019 at 08:20:45PM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-06-28 14:07:27 [-0400], Joel Fernandes wrote:
> > On Fri, Jun 28, 2019 at 07:45:45PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2019-06-28 10:30:11 [-0700], Paul E. McKenney wrote:
> > > > > I believe the .bl
On Fri, Jun 28, 2019 at 11:44:11AM -0400, Steven Rostedt wrote:
> On Fri, 28 Jun 2019 19:40:45 +0900
> Byungchul Park wrote:
>
> > Wait.. I got a little bit confused on recordering.
> >
> > This 'STORE rcu_read_lock_nesting = 0' can happen before
> > 'STORE rcu_read_unlock_special.b.exp_hint = f
On Sat, Jun 29, 2019 at 12:15:15PM -0700, Paul E. McKenney wrote:
> On Sat, Jun 29, 2019 at 08:09:10PM +0200, Andrea Parri wrote:
> > On Sat, Jun 29, 2019 at 09:55:33AM -0700, Paul E. McKenney wrote:
> > > On Sat, Jun 29, 2019 at 05:12:36PM +0200, Andrea Parri wrote:
> > > > Hi Steve,
> > > >
> >
On Sat, Jun 29, 2019 at 08:09:10PM +0200, Andrea Parri wrote:
> On Sat, Jun 29, 2019 at 09:55:33AM -0700, Paul E. McKenney wrote:
> > On Sat, Jun 29, 2019 at 05:12:36PM +0200, Andrea Parri wrote:
> > > Hi Steve,
> > >
> > > > As Paul stated, interrupts are synchronization points. Archs can only
>
> Remark: we do have code which (while acknowledging that "interrupts are
> synchronization points") doesn't quite seem to "believe it", c.f., e.g.,
> kernel/sched/membarrier.c:ipi_mb(). So, I guess the follow-up question
> would be "Would we better be (more) paranoid? ..."
should have been "IPIs
On Sat, Jun 29, 2019 at 09:55:33AM -0700, Paul E. McKenney wrote:
> On Sat, Jun 29, 2019 at 05:12:36PM +0200, Andrea Parri wrote:
> > Hi Steve,
> >
> > > As Paul stated, interrupts are synchronization points. Archs can only
> > > play games with ordering when dealing with entities outside the CPU
On Sat, Jun 29, 2019 at 05:12:36PM +0200, Andrea Parri wrote:
> Hi Steve,
>
> > As Paul stated, interrupts are synchronization points. Archs can only
> > play games with ordering when dealing with entities outside the CPU
> > (devices and other CPUs). But if you have assembly that has two stores,
Hi Steve,
> As Paul stated, interrupts are synchronization points. Archs can only
> play games with ordering when dealing with entities outside the CPU
> (devices and other CPUs). But if you have assembly that has two stores,
> and an interrupt comes in, the arch must guarantee that the stores are
On Fri, Jun 28, 2019 at 07:12:41PM -0400, Joel Fernandes wrote:
> On Fri, Jun 28, 2019 at 03:25:47PM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 28, 2019 at 05:40:18PM -0400, Joel Fernandes wrote:
> > > Hi Paul,
> > >
> > > On Fri, Jun 28, 2019 at 01:04:23PM -0700, Paul E. McKenney wrote:
> > >
On Fri, Jun 28, 2019 at 03:25:47PM -0700, Paul E. McKenney wrote:
> On Fri, Jun 28, 2019 at 05:40:18PM -0400, Joel Fernandes wrote:
> > Hi Paul,
> >
> > On Fri, Jun 28, 2019 at 01:04:23PM -0700, Paul E. McKenney wrote:
> > [snip]
> > > > > > Commit
> > > > > > - 23634ebc1d946 ("rcu: Check for wake
On Fri, Jun 28, 2019 at 05:40:18PM -0400, Joel Fernandes wrote:
> Hi Paul,
>
> On Fri, Jun 28, 2019 at 01:04:23PM -0700, Paul E. McKenney wrote:
> [snip]
> > > > > Commit
> > > > > - 23634ebc1d946 ("rcu: Check for wakeup-safe conditions in
> > > > >rcu_read_unlock_special()") does not trigger
Hi Paul,
On Fri, Jun 28, 2019 at 01:04:23PM -0700, Paul E. McKenney wrote:
[snip]
> > > > Commit
> > > > - 23634ebc1d946 ("rcu: Check for wakeup-safe conditions in
> > > >rcu_read_unlock_special()") does not trigger the bug within 94
> > > >attempts.
> > > >
> > > > - 48d07c04b4cc1 ("rcu:
On Fri, Jun 28, 2019 at 03:29:23PM -0400, Joel Fernandes wrote:
> On Fri, Jun 28, 2019 at 11:22:16AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 28, 2019 at 07:45:45PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2019-06-28 10:30:11 [-0700], Paul E. McKenney wrote:
> > > > > I believe the .b
On Fri, Jun 28, 2019 at 03:24:07PM -0400, Joel Fernandes wrote:
> On Fri, Jun 28, 2019 at 11:52:19AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 28, 2019 at 08:40:26PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2019-06-28 08:30:50 [-0700], Paul E. McKenney wrote:
> > > > On Fri, Jun 28, 20
On Fri, 2019-06-28 at 16:15 +0200, Peter Zijlstra wrote:
> On Thu, Jun 27, 2019 at 01:36:12PM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 27, 2019 at 03:17:27PM -0500, Scott Wood wrote:
> > > On Thu, 2019-06-27 at 11:41 -0700, Paul E. McKenney wrote:
> > > > Of course, unconditionally refusing t
On Fri, Jun 28, 2019 at 11:22:16AM -0700, Paul E. McKenney wrote:
> On Fri, Jun 28, 2019 at 07:45:45PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2019-06-28 10:30:11 [-0700], Paul E. McKenney wrote:
> > > > I believe the .blocked field remains set even though we are not any
> > > > more in a
>
On Fri, Jun 28, 2019 at 11:52:19AM -0700, Paul E. McKenney wrote:
> On Fri, Jun 28, 2019 at 08:40:26PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2019-06-28 08:30:50 [-0700], Paul E. McKenney wrote:
> > > On Fri, Jun 28, 2019 at 03:54:33PM +0200, Peter Zijlstra wrote:
> > > > On Thu, Jun 27, 20
On Fri, Jun 28, 2019 at 08:40:26PM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-06-28 08:30:50 [-0700], Paul E. McKenney wrote:
> > On Fri, Jun 28, 2019 at 03:54:33PM +0200, Peter Zijlstra wrote:
> > > On Thu, Jun 27, 2019 at 11:41:07AM -0700, Paul E. McKenney wrote:
> > > > Or just don't do t
On 2019-06-28 08:30:50 [-0700], Paul E. McKenney wrote:
> On Fri, Jun 28, 2019 at 03:54:33PM +0200, Peter Zijlstra wrote:
> > On Thu, Jun 27, 2019 at 11:41:07AM -0700, Paul E. McKenney wrote:
> > > Or just don't do the wakeup at all, if it comes to that. I don't know
> > > of any way to determine
On Fri, Jun 28, 2019 at 02:05:37PM -0400, Joel Fernandes wrote:
> On Fri, Jun 28, 2019 at 10:30:11AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 28, 2019 at 12:45:59PM -0400, Joel Fernandes wrote:
> > > On Fri, Jun 28, 2019 at 12:40:08PM -0400, Joel Fernandes wrote:
> > > > On Thu, Jun 27, 2019
On Fri, Jun 28, 2019 at 07:45:45PM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-06-28 10:30:11 [-0700], Paul E. McKenney wrote:
> > > I believe the .blocked field remains set even though we are not any more
> > > in a
> > > reader section because of deferred processing of the blocked lists th
On 2019-06-28 14:07:27 [-0400], Joel Fernandes wrote:
> On Fri, Jun 28, 2019 at 07:45:45PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2019-06-28 10:30:11 [-0700], Paul E. McKenney wrote:
> > > > I believe the .blocked field remains set even though we are not any
> > > > more in a
> > > > reade
On Fri, Jun 28, 2019 at 07:45:45PM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-06-28 10:30:11 [-0700], Paul E. McKenney wrote:
> > > I believe the .blocked field remains set even though we are not any more
> > > in a
> > > reader section because of deferred processing of the blocked lists th
On Fri, Jun 28, 2019 at 10:30:11AM -0700, Paul E. McKenney wrote:
> On Fri, Jun 28, 2019 at 12:45:59PM -0400, Joel Fernandes wrote:
> > On Fri, Jun 28, 2019 at 12:40:08PM -0400, Joel Fernandes wrote:
> > > On Thu, Jun 27, 2019 at 11:41:07AM -0700, Paul E. McKenney wrote:
> > > [snip]
> > > > > > >
On 2019-06-28 10:30:11 [-0700], Paul E. McKenney wrote:
> > I believe the .blocked field remains set even though we are not any more in
> > a
> > reader section because of deferred processing of the blocked lists that you
> > mentioned yesterday.
>
> That can indeed happen. However, in current -
On Fri, Jun 28, 2019 at 10:30:11AM -0700, Paul E. McKenney wrote:
> On Fri, Jun 28, 2019 at 12:45:59PM -0400, Joel Fernandes wrote:
> > On Fri, Jun 28, 2019 at 12:40:08PM -0400, Joel Fernandes wrote:
> > > On Thu, Jun 27, 2019 at 11:41:07AM -0700, Paul E. McKenney wrote:
> > > [snip]
> > > > > > >
On Fri, Jun 28, 2019 at 12:45:59PM -0400, Joel Fernandes wrote:
> On Fri, Jun 28, 2019 at 12:40:08PM -0400, Joel Fernandes wrote:
> > On Thu, Jun 27, 2019 at 11:41:07AM -0700, Paul E. McKenney wrote:
> > [snip]
> > > > > > And we should document this somewhere for future sanity preservation
> > > >
On Fri, Jun 28, 2019 at 06:04:08PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 28, 2019 at 08:54:04AM -0700, Paul E. McKenney wrote:
> > Thank you! Plus it looks like scheduler_ipi() takes an early exit if
> > ->wake_list is empty, regardless of TIF_NEED_RESCHED, right?
>
> Yes, TIF_NEED_RESCHED i
On Fri, Jun 28, 2019 at 12:40:08PM -0400, Joel Fernandes wrote:
> On Thu, Jun 27, 2019 at 11:41:07AM -0700, Paul E. McKenney wrote:
> [snip]
> > > > > And we should document this somewhere for future sanity preservation
> > > > > :-D
> > > >
> > > > Or adjust the code and requirements to make it m
On Thu, Jun 27, 2019 at 11:41:07AM -0700, Paul E. McKenney wrote:
[snip]
> > > > And we should document this somewhere for future sanity preservation
> > > > :-D
> > >
> > > Or adjust the code and requirements to make it more sane, if feasible.
> > >
> > > My current (probably wildly unreliable)
On Fri, Jun 28, 2019 at 08:54:04AM -0700, Paul E. McKenney wrote:
> Thank you! Plus it looks like scheduler_ipi() takes an early exit if
> ->wake_list is empty, regardless of TIF_NEED_RESCHED, right?
Yes, TIF_NEED_RESCHED is checked in the interrupt return path.
On Fri, Jun 28, 2019 at 04:15:22PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 27, 2019 at 01:36:12PM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 27, 2019 at 03:17:27PM -0500, Scott Wood wrote:
> > > On Thu, 2019-06-27 at 11:41 -0700, Paul E. McKenney wrote:
> > > > On Thu, Jun 27, 2019 at 02:16:
On Fri, 28 Jun 2019 19:40:45 +0900
Byungchul Park wrote:
> Wait.. I got a little bit confused on recordering.
>
> This 'STORE rcu_read_lock_nesting = 0' can happen before
> 'STORE rcu_read_unlock_special.b.exp_hint = false' regardless of the
> order a compiler generated to by the barrier(), beca
On Fri, Jun 28, 2019 at 03:54:33PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 27, 2019 at 11:41:07AM -0700, Paul E. McKenney wrote:
> > Or just don't do the wakeup at all, if it comes to that. I don't know
> > of any way to determine whether rcu_read_unlock() is being called from
> > the scheduler
On Thu, Jun 27, 2019 at 01:36:12PM -0700, Paul E. McKenney wrote:
> On Thu, Jun 27, 2019 at 03:17:27PM -0500, Scott Wood wrote:
> > On Thu, 2019-06-27 at 11:41 -0700, Paul E. McKenney wrote:
> > > On Thu, Jun 27, 2019 at 02:16:38PM -0400, Joel Fernandes wrote:
> > > >
> > > > I think the fix shoul
On Thu, Jun 27, 2019 at 11:41:07AM -0700, Paul E. McKenney wrote:
> Or just don't do the wakeup at all, if it comes to that. I don't know
> of any way to determine whether rcu_read_unlock() is being called from
> the scheduler, but it has been some time since I asked Peter Zijlstra
> about that.
On Fri, Jun 28, 2019 at 07:40:45PM +0900, Byungchul Park wrote:
> On Fri, Jun 28, 2019 at 04:31:38PM +0900, Byungchul Park wrote:
> > On Thu, Jun 27, 2019 at 01:36:12PM -0700, Paul E. McKenney wrote:
> > > On Thu, Jun 27, 2019 at 03:17:27PM -0500, Scott Wood wrote:
> > > > On Thu, 2019-06-27 at 11:
On Fri, Jun 28, 2019 at 05:24:38PM +0900, Byungchul Park wrote:
> On Fri, Jun 28, 2019 at 05:14:32PM +0900, Byungchul Park wrote:
> > On Fri, Jun 28, 2019 at 04:43:50PM +0900, Byungchul Park wrote:
> > > On Fri, Jun 28, 2019 at 04:31:38PM +0900, Byungchul Park wrote:
> > > > On Thu, Jun 27, 2019 at
On Fri, Jun 28, 2019 at 04:43:50PM +0900, Byungchul Park wrote:
> On Fri, Jun 28, 2019 at 04:31:38PM +0900, Byungchul Park wrote:
> > On Thu, Jun 27, 2019 at 01:36:12PM -0700, Paul E. McKenney wrote:
> > > On Thu, Jun 27, 2019 at 03:17:27PM -0500, Scott Wood wrote:
> > > > On Thu, 2019-06-27 at 11:
On Fri, Jun 28, 2019 at 04:31:38PM +0900, Byungchul Park wrote:
> On Thu, Jun 27, 2019 at 01:36:12PM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 27, 2019 at 03:17:27PM -0500, Scott Wood wrote:
> > > On Thu, 2019-06-27 at 11:41 -0700, Paul E. McKenney wrote:
> > > > On Thu, Jun 27, 2019 at 02:16:
On Fri, Jun 28, 2019 at 06:10:42PM +0900, Byungchul Park wrote:
> On Fri, Jun 28, 2019 at 04:43:50PM +0900, Byungchul Park wrote:
> > On Fri, Jun 28, 2019 at 04:31:38PM +0900, Byungchul Park wrote:
> > > On Thu, Jun 27, 2019 at 01:36:12PM -0700, Paul E. McKenney wrote:
> > > > On Thu, Jun 27, 2019
On Fri, Jun 28, 2019 at 04:43:50PM +0900, Byungchul Park wrote:
> On Fri, Jun 28, 2019 at 04:31:38PM +0900, Byungchul Park wrote:
> > On Thu, Jun 27, 2019 at 01:36:12PM -0700, Paul E. McKenney wrote:
> > > On Thu, Jun 27, 2019 at 03:17:27PM -0500, Scott Wood wrote:
> > > > On Thu, 2019-06-27 at 11:
On Fri, Jun 28, 2019 at 05:14:32PM +0900, Byungchul Park wrote:
> On Fri, Jun 28, 2019 at 04:43:50PM +0900, Byungchul Park wrote:
> > On Fri, Jun 28, 2019 at 04:31:38PM +0900, Byungchul Park wrote:
> > > On Thu, Jun 27, 2019 at 01:36:12PM -0700, Paul E. McKenney wrote:
> > > > On Thu, Jun 27, 2019
On Fri, Jun 28, 2019 at 04:43:50PM +0900, Byungchul Park wrote:
> On Fri, Jun 28, 2019 at 04:31:38PM +0900, Byungchul Park wrote:
> > On Thu, Jun 27, 2019 at 01:36:12PM -0700, Paul E. McKenney wrote:
> > > On Thu, Jun 27, 2019 at 03:17:27PM -0500, Scott Wood wrote:
> > > > On Thu, 2019-06-27 at 11:
On Fri, Jun 28, 2019 at 04:31:38PM +0900, Byungchul Park wrote:
> On Thu, Jun 27, 2019 at 01:36:12PM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 27, 2019 at 03:17:27PM -0500, Scott Wood wrote:
> > > On Thu, 2019-06-27 at 11:41 -0700, Paul E. McKenney wrote:
> > > > On Thu, Jun 27, 2019 at 02:16:
On Thu, Jun 27, 2019 at 01:36:12PM -0700, Paul E. McKenney wrote:
> On Thu, Jun 27, 2019 at 03:17:27PM -0500, Scott Wood wrote:
> > On Thu, 2019-06-27 at 11:41 -0700, Paul E. McKenney wrote:
> > > On Thu, Jun 27, 2019 at 02:16:38PM -0400, Joel Fernandes wrote:
> > > >
> > > > I think the fix shoul
On Thu, Jun 27, 2019 at 11:30:22AM -0700, Paul E. McKenney wrote:
> On Thu, Jun 27, 2019 at 11:11:12AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 27, 2019 at 01:46:27PM -0400, Joel Fernandes wrote:
> > > On Thu, Jun 27, 2019 at 1:43 PM Joel Fernandes
> > > wrote:
> > > >
> > > > On Thu, Jun 2
On Thu, Jun 27, 2019 at 03:17:27PM -0500, Scott Wood wrote:
> On Thu, 2019-06-27 at 11:41 -0700, Paul E. McKenney wrote:
> > On Thu, Jun 27, 2019 at 02:16:38PM -0400, Joel Fernandes wrote:
> > >
> > > I think the fix should be to prevent the wake-up not based on whether we
> > > are
> > > in hard/
On Thu, 2019-06-27 at 11:41 -0700, Paul E. McKenney wrote:
> On Thu, Jun 27, 2019 at 02:16:38PM -0400, Joel Fernandes wrote:
> >
> > I think the fix should be to prevent the wake-up not based on whether we
> > are
> > in hard/soft-interrupt mode but that we are doing the rcu_read_unlock()
> > from
On Thu, Jun 27, 2019 at 02:27:22PM -0400, Joel Fernandes wrote:
> On Thu, Jun 27, 2019 at 11:11:12AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 27, 2019 at 01:46:27PM -0400, Joel Fernandes wrote:
> > > On Thu, Jun 27, 2019 at 1:43 PM Joel Fernandes
> > > wrote:
> > > >
> > > > On Thu, Jun 27,
On Thu, Jun 27, 2019 at 02:51:03PM -0400, Joel Fernandes wrote:
> On Thu, Jun 27, 2019 at 02:27:22PM -0400, Joel Fernandes wrote:
> > On Thu, Jun 27, 2019 at 11:11:12AM -0700, Paul E. McKenney wrote:
> > > On Thu, Jun 27, 2019 at 01:46:27PM -0400, Joel Fernandes wrote:
> > > > On Thu, Jun 27, 2019
On Thu, Jun 27, 2019 at 02:27:22PM -0400, Joel Fernandes wrote:
> On Thu, Jun 27, 2019 at 11:11:12AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 27, 2019 at 01:46:27PM -0400, Joel Fernandes wrote:
> > > On Thu, Jun 27, 2019 at 1:43 PM Joel Fernandes
> > > wrote:
> > > >
> > > > On Thu, Jun 27,
On Thu, Jun 27, 2019 at 02:16:38PM -0400, Joel Fernandes wrote:
> On Thu, Jun 27, 2019 at 10:38:31AM -0700, Paul E. McKenney wrote:
> > On Thu, Jun 27, 2019 at 12:47:24PM -0400, Joel Fernandes wrote:
> > > On Thu, Jun 27, 2019 at 11:55 AM Paul E. McKenney
> > > wrote:
> > > >
> > > > On Thu, Jun
On Thu, Jun 27, 2019 at 11:11:12AM -0700, Paul E. McKenney wrote:
> On Thu, Jun 27, 2019 at 01:46:27PM -0400, Joel Fernandes wrote:
> > On Thu, Jun 27, 2019 at 1:43 PM Joel Fernandes
> > wrote:
> > >
> > > On Thu, Jun 27, 2019 at 11:40 AM Sebastian Andrzej Siewior
> > > wrote:
> > > >
> > > > On
On Thu, Jun 27, 2019 at 11:11:12AM -0700, Paul E. McKenney wrote:
> On Thu, Jun 27, 2019 at 01:46:27PM -0400, Joel Fernandes wrote:
> > On Thu, Jun 27, 2019 at 1:43 PM Joel Fernandes
> > wrote:
> > >
> > > On Thu, Jun 27, 2019 at 11:40 AM Sebastian Andrzej Siewior
> > > wrote:
> > > >
> > > > On
On Thu, Jun 27, 2019 at 10:38:31AM -0700, Paul E. McKenney wrote:
> On Thu, Jun 27, 2019 at 12:47:24PM -0400, Joel Fernandes wrote:
> > On Thu, Jun 27, 2019 at 11:55 AM Paul E. McKenney
> > wrote:
> > >
> > > On Thu, Jun 27, 2019 at 11:30:31AM -0400, Joel Fernandes wrote:
> > > > On Thu, Jun 27,
On Thu, Jun 27, 2019 at 01:46:27PM -0400, Joel Fernandes wrote:
> On Thu, Jun 27, 2019 at 1:43 PM Joel Fernandes wrote:
> >
> > On Thu, Jun 27, 2019 at 11:40 AM Sebastian Andrzej Siewior
> > wrote:
> > >
> > > On 2019-06-27 11:37:10 [-0400], Joel Fernandes wrote:
> > > > Sebastian it would be nic
On Thu, Jun 27, 2019 at 1:43 PM Joel Fernandes wrote:
>
> On Thu, Jun 27, 2019 at 11:40 AM Sebastian Andrzej Siewior
> wrote:
> >
> > On 2019-06-27 11:37:10 [-0400], Joel Fernandes wrote:
> > > Sebastian it would be nice if possible to trace where the
> > > t->rcu_read_unlock_special is set for t
On Thu, Jun 27, 2019 at 11:40 AM Sebastian Andrzej Siewior
wrote:
>
> On 2019-06-27 11:37:10 [-0400], Joel Fernandes wrote:
> > Sebastian it would be nice if possible to trace where the
> > t->rcu_read_unlock_special is set for this scenario of calling
> > rcu_read_unlock_special, to give a clear
On Thu, Jun 27, 2019 at 12:47:24PM -0400, Joel Fernandes wrote:
> On Thu, Jun 27, 2019 at 11:55 AM Paul E. McKenney
> wrote:
> >
> > On Thu, Jun 27, 2019 at 11:30:31AM -0400, Joel Fernandes wrote:
> > > On Thu, Jun 27, 2019 at 10:34:55AM -0400, Steven Rostedt wrote:
> > > > On Thu, 27 Jun 2019 10
On Thu, Jun 27, 2019 at 11:55 AM Paul E. McKenney wrote:
>
> On Thu, Jun 27, 2019 at 11:30:31AM -0400, Joel Fernandes wrote:
> > On Thu, Jun 27, 2019 at 10:34:55AM -0400, Steven Rostedt wrote:
> > > On Thu, 27 Jun 2019 10:24:36 -0400
> > > Joel Fernandes wrote:
> > >
> > > > > What am I missing h
On Thu, Jun 27, 2019 at 11:30:31AM -0400, Joel Fernandes wrote:
> On Thu, Jun 27, 2019 at 10:34:55AM -0400, Steven Rostedt wrote:
> > On Thu, 27 Jun 2019 10:24:36 -0400
> > Joel Fernandes wrote:
> >
> > > > What am I missing here?
> > >
> > > This issue I think is
> > >
> > > (in normal proce
On Thu, Jun 27, 2019 at 09:47:05AM +0200, Sebastian Andrzej Siewior wrote:
> On 2019-06-26 09:25:58 [-0700], Paul E. McKenney wrote:
> > On Wed, Jun 26, 2019 at 03:54:47PM +0200, Sebastian Andrzej Siewior wrote:
> > > one of my boxes boots with "threadirqs" and since commit 05f415715ce45
> > > ("rc
On Thu, Jun 27, 2019 at 11:40 AM Sebastian Andrzej Siewior
wrote:
>
> On 2019-06-27 11:37:10 [-0400], Joel Fernandes wrote:
> > Sebastian it would be nice if possible to trace where the
> > t->rcu_read_unlock_special is set for this scenario of calling
> > rcu_read_unlock_special, to give a clear
On 2019-06-27 11:37:10 [-0400], Joel Fernandes wrote:
> Sebastian it would be nice if possible to trace where the
> t->rcu_read_unlock_special is set for this scenario of calling
> rcu_read_unlock_special, to give a clear idea about whether it was
> really because of an IPI. I guess we could also a
On Thu, Jun 27, 2019 at 11:30 AM Joel Fernandes wrote:
>
> On Thu, Jun 27, 2019 at 10:34:55AM -0400, Steven Rostedt wrote:
> > On Thu, 27 Jun 2019 10:24:36 -0400
> > Joel Fernandes wrote:
> >
> > > > What am I missing here?
> > >
> > > This issue I think is
> > >
> > > (in normal process context)
On Thu, Jun 27, 2019 at 10:34:55AM -0400, Steven Rostedt wrote:
> On Thu, 27 Jun 2019 10:24:36 -0400
> Joel Fernandes wrote:
>
> > > What am I missing here?
> >
> > This issue I think is
> >
> > (in normal process context)
> > spin_lock_irqsave(rq_lock); // which disables both preemption and
On Thu, 27 Jun 2019 10:24:36 -0400
Joel Fernandes wrote:
> > What am I missing here?
>
> This issue I think is
>
> (in normal process context)
> spin_lock_irqsave(rq_lock); // which disables both preemption and interrupt
> // but this was done in normal process contex
On Wed, Jun 26, 2019 at 09:25:58AM -0700, Paul E. McKenney wrote:
> On Wed, Jun 26, 2019 at 03:54:47PM +0200, Sebastian Andrzej Siewior wrote:
> > one of my boxes boots with "threadirqs" and since commit 05f415715ce45
> > ("rcu: Speed up expedited GPs when interrupting RCU reader") I run
> > reliab
On 2019-06-26 09:25:58 [-0700], Paul E. McKenney wrote:
> On Wed, Jun 26, 2019 at 03:54:47PM +0200, Sebastian Andrzej Siewior wrote:
> > one of my boxes boots with "threadirqs" and since commit 05f415715ce45
> > ("rcu: Speed up expedited GPs when interrupting RCU reader") I run
> > reliably into th
On Wed, Jun 26, 2019 at 03:54:47PM +0200, Sebastian Andrzej Siewior wrote:
> one of my boxes boots with "threadirqs" and since commit 05f415715ce45
> ("rcu: Speed up expedited GPs when interrupting RCU reader") I run
> reliably into the following deadlock:
>
> | ===
one of my boxes boots with "threadirqs" and since commit 05f415715ce45
("rcu: Speed up expedited GPs when interrupting RCU reader") I run
reliably into the following deadlock:
|
| WARNING: possible recursive locking detected
| 5.2.0-rc6 #279 Not tainted
78 matches
Mail list logo
