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;
MIME-Version: 1.0
References: <20190711164818.GA260447@google.com> <20190711195839.GA163275@google.com>
 <20190712063240.GD7702@X58A-UD3R> <20190712125116.GB92297@google.com>
 <CANrsvRMh6L_sEmoF_K3Mx=1VcuGSwQAT8CZHep69aSZUTBvwpA@mail.gmail.com>
 <CAEXW_YTeAUuVqViBfiOTQhckMDH229oQdPXG6SNqGK0xYm-yzA@mail.gmail.com>
 <20190713151330.GE26519@linux.ibm.com> <20190713154257.GE133650@google.com>
 <20190713174111.GG26519@linux.ibm.com> <CAEXW_YTcL-nOfJXkChGhvQtqqfSLpAYr327PLu1SmGEEADCevw@mail.gmail.com>
 <20190719003942.GA28226@X58A-UD3R>
In-Reply-To: <20190719003942.GA28226@X58A-UD3R>
From:   Joel Fernandes <joel@joelfernandes.org>
Date:   Thu, 18 Jul 2019 20:52:52 -0400
Message-ID: <CAEXW_YQij-N2-NFjUQtsmYxVLtWxcQk_Kb16fGBzzPAZtWg+sg@mail.gmail.com>
Subject: Re: [PATCH] rcu: Make jiffies_till_sched_qs writable
To:     Byungchul Park <byungchul.park@lge.com>
Cc:     "Paul E. McKenney" <paulmck@linux.ibm.com>,
        Byungchul Park <max.byungchul.park@gmail.com>,
        rcu <rcu@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
        kernel-team@lge.com
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jul 18, 2019 at 8:40 PM Byungchul Park <byungchul.park@lge.com> wrote:
[snip]
> > - There is a bug in the CPU stopper machinery itself preventing it
> > from scheduling the stopper on Y. Even though Y is not holding up the
> > grace period.
>
> Or any thread on Y is busy with preemption/irq disabled preventing the
> stopper from being scheduled on Y.
>
> Or something is stuck in ttwu() to wake up the stopper on Y due to any
> scheduler locks such as pi_lock or rq->lock or something.
>
> I think what you mentioned can happen easily.
>
> Basically we would need information about preemption/irq disabled
> sections on Y and scheduler's current activity on every cpu at that time.

I think all that's needed is an NMI backtrace on all CPUs. An ARM we
don't have NMI solutions and only IPI or interrupt based backtrace
works which should at least catch and the preempt disable and softirq
disable cases.

But yeah I don't see why just the stacks of those CPUs that are
blocking the CPU X would not suffice for the trivial cases where a
piece of misbehaving code disable interrupts / preemption and
prevented the stopper thread from executing.

May be once the test case is ready (no rush!) , then it will be more
clear what can help.

J.