[lkml]   [2009]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: CONFIG_PREEMPT_RCU in next/mmotm
    On Wed, Aug 12, 2009 at 11:22:50AM +0200, Ingo Molnar wrote:
    > * Paul E. McKenney <> wrote:
    > > Should these tests pass...

    Things are working much better, but I can still cause failures by
    hotplugging CPUs with zero wait time between them while concurrently
    modprobe-ing and rmmod-ing rcutorture repeatedly while running
    CONFIG_PREEMPT_RCU. I increased the kernel's lifespan by an order of
    magnitude or so by simplifying rcupreempt's hotplug code path.

    And I just -know- that I will deeply regret having described my test
    process, given that my life is much easier when my RCU testing is more
    rigorous than anyone else's. ;-)

    The remaining (known) problem appears to be due to a kthread_stop()
    deadlock between the migration threads and a few of rcutorture's kthreads.
    In this deadlock, rcutorture is waiting for one of the fakewriters
    to stop (via kthread_stop()), while the fakewriter is waiting for
    synchronize_rcu() to complete. The migration thread's CPU-hotplug
    notifier is blocked in kthread_stop() because rcutorture holds the
    kthread_stop() mutex.

    I could argue that CPU hotplug should allow RCU grace periods to
    proceed regardless, but I believe that the problem is that some thread
    is preempted in the middle of an RCU read-side critical section, but
    cannot be migrated to a CPU that could run it due to the fact that the
    migration kthread is stuck in its CPU-hotplug notifier. RCU being what
    it is, it seems reasonable for me to instead arrange so that rcutorture
    never invokes kthread_stop() unless it knows that the target thread cannot
    possibly be in the midst of synchronize_rcu(). That said, there is the
    concern that this general pattern might rear its ugly head elsewhere.

    > > Unless someone tells me otherwise, I will make a patch series
    > > intended to replace tip/core/rcu commits 7fe616c5d ("Simplify RCU
    > > CPU-hotplug notification"), 04b06256c ("Fix RCU & CPU hotplug
    > > hang"), and 7256cf0e83b ("Add diagnostic check for a possible
    > > CPU-hotplug race"), re-run all tests on that patchset, and submit
    > > the series. I expect the resulting patch set to have three
    > > patches, one to split out boot-time initialization for RCU_TREE, a
    > > second to create the cpu_notifier() API, and the third to make RCU
    > > use it.

    While thinking this over, I am rebasing as described above, and doing
    full-up testing at each step. No more Mr. Nice Guy!!! ;-)

    In the meantime, can anyone tell me why we only let one kthread stop at
    a time?

    > Sure - we can reasonably rebase portions of that stack of commits:
    > earth4:~/tip> gll linus..core/rcu
    > 7256cf0: rcu: Add diagnostic check for a possible CPU-hotplug race
    > 04b0625: rcu: Fix RCU & CPU hotplug hang
    > 7fe616c: rcu: Simplify RCU CPU-hotplug notification
    > 240ebbf: rcu: Add synchronize_sched_expedited() rcutorture doc + updates
    > 0acc512: rcu: Add synchronize_sched_expedited() torture tests
    > 03b042b: rcu: Add synchronize_sched_expedited() primitive
    > c17ef45: rcu: Remove Classic RCU
    > Please mention the magic words "please reset core/rcu to 240ebbf
    > before applying these patches" in the mail to me, should i forget in
    > the days to come.

    Will do!

    > (hm, what was i supposed to not forget? Weird.)

    I can't remember. ;-)

    Thanx, Paul

     \ /
      Last update: 2009-08-13 02:53    [W:0.024 / U:6.952 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site