Linux 3.4.97-rt121-rc1

Dear RT Folks,

This is the RT stable review cycle of patch 3.4.97-rt121-rc1.

Please scream at me if I messed something up. Please test the patches too.

The -rc release will be uploaded to kernel.org and will be deleted when the final release is out. This is just a review release (or release candidate).

The pre-releases will not be pushed to the git repository, only the final release is.

If all goes well, this patch will be converted to the next main release on 7/17/2014.

Enjoy,

-- Steve

To build 3.4.97-rt121-rc1 directly, the following patches should be applied:

http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.tar.xz

http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.4.97.xz

http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.97-rt121-rc1.patch.xz

You can also build from 3.4.97-rt120 by applying the incremental patch:

http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/incr/patch-3.4.97-rt120-rt121-rc1.patch.xz

Changes from 3.4.97-rt120:

---

Steven Rostedt (1):
sched: Do not clear PF_NO_SETAFFINITY flag in select_fallback_rq()

Steven Rostedt (Red Hat) (1):

      Linux 3.4.97-rt121-rc1

Thomas Gleixner (1):
workqueue: Prevent deadlock/stall on RT

Zhao Hongjiang (1):
hrtimer:fix the miss of hrtimer_peek_ahead_timers in nort code

----

 kernel/hrtimer.c    |  6 +++++-
 kernel/sched/core.c | 13 +++++--------
 kernel/workqueue.c  | 41 +++++++++++++++++++++++++++++++++++------
 localversion-rt     |  2 +-
 4 files changed, 46 insertions(+), 16 deletions(-)

3.4.97-rt121-rc1 stable review patch.
If anyone has any objections, please let me know.

------------------

From: Steven Rostedt <[email protected]>

I talked with Peter Zijlstra about this, and he told me that the clearing of the PF_NO_SETAFFINITY flag was to deal with the optimization of migrate_disable/enable() that ignores tasks that have that flag set. But that optimization was removed when I did a rework of the cpu hotplug code.

I found that ignoring tasks that had that flag set would cause those tasks to not sync with the hotplug code and cause the kernel to crash. Thus it needed to not treat them special and those tasks had to go though the same work as tasks without that flag set.

Now that those tasks are not treated special, there's no reason to clear the flag.

May still need to be tested as the migrate_me() code does not ignore those flags.

---
 kernel/sched/core.c | 6 ------
 1 file changed, 6 deletions(-)

index 1199054adb2e..2b2863972dd1 100644
@@ -1325,12 +1325,6 @@ out:
 		}
 	}
 
-	/*
-	 * Clear PF_THREAD_BOUND, otherwise we wreckage
-	 * migrate_disable/enable. See optimization for
-	 * PF_THREAD_BOUND tasks there.
-	 */
-	p->flags &= ~PF_THREAD_BOUND;
 	return dest_cpu;
 }
 

2.0.0

3.4.97-rt121-rc1 stable review patch.
If anyone has any objections, please let me know.

------------------

From: Thomas Gleixner <[email protected]>

Austin reported a XFS deadlock/stall on RT where scheduled work gets never exececuted and tasks are waiting for each other for ever.

The underlying problem is the modification of the RT code to the handling of workers which are about to go to sleep. In mainline a worker thread which goes to sleep wakes an idle worker if there is more work to do. This happens from the guts of the schedule() function. On RT this must be outside and the accessed data structures are not protected against scheduling due to the spinlock to rtmutex conversion. So the naive solution to this was to move the code outside of the scheduler and protect the data structures by the pool lock. That approach turned out to be a little naive as we cannot call into that code when the thread blocks on a lock, as it is not allowed to block on two locks in parallel. So we dont call into the worker wakeup magic when the worker is blocked on a lock, which causes the deadlock/stall observed by Austin and Mike.

Looking deeper into that worker code it turns out that the only relevant data structure which needs to be protected is the list of idle workers which can be woken up.

So the solution is to protect the list manipulation operations with preempt_enable/disable pairs on RT and call unconditionally into the worker code even when the worker is blocked on a lock. The preemption protection is safe as there is nothing which can fiddle with the list outside of thread context.

---
 kernel/sched/core.c |  7 +++++--
 kernel/workqueue.c  | 41 +++++++++++++++++++++++++++++++++++------
 2 files changed, 40 insertions(+), 8 deletions(-)

index 2b2863972dd1..5ba55a8b26e0 100644
@@ -3574,9 +3574,8 @@ need_resched:
 
 static inline void sched_submit_work(struct task_struct *tsk)
 {
-	if (!tsk->state || tsk_is_pi_blocked(tsk))
+	if (!tsk->state)
 		return;
-
 	/*
 	 * If a worker went to sleep, notify and ask workqueue whether
 	 * it wants to wake up a task to maintain concurrency.

@@ -3586,6 +3585,10 @@ static inline void sched_submit_work(struct task_struct *tsk)
 	if (tsk->flags & PF_WQ_WORKER && !tsk->saved_state)
 		wq_worker_sleeping(tsk);
 
+
+	if (tsk_is_pi_blocked(tsk))
+		return;
+
 	/*
 	 * If we are going to sleep and we have plugged IO queued,
 	 * make sure to submit it to avoid deadlocks.

2.0.0

3.4.97-rt121-rc1 stable review patch.
If anyone has any objections, please let me know.

------------------

From: Zhao Hongjiang <[email protected]>

When we run the test "taskset -c 1 stress -m 1 --vm-bytes 50M" and "taskset -c 1 cyclictest -t 1 -p 80 -n -m -v" with rt closed 3.4.26-rt38 kernel, the cyclictest's result is anomalous as follow:

       0:     278:       1
       0:     279:       2
       0:     280:      17
       0:     281:    1657
       0:     282:    1680
       0:     283:    4678
       0:     284:    7026
       0:     285:    6678
       0:     286:    9677
       0:     287:   12678
       0:     288:   13090
       0:     289:   14678
       0:     290:   17677
       0:     291:   20155
       0:     292:   19678
       0:     293:   22679
       0:     294:   25676
       0:     295:   26218
       0:     296:   27679
       0:     297:   30677
       0:     298:   33283
       0:     299:   32677
       0:     300:   35676

and the result is increase continuously forever. We find that the patch ("hrtimer: fixup hrtimer callback changes for preempt-rt") has missed hrtimer_peek_ahead_timers() in hrtimer_rt_run_pending() fuction in nort code. We fix this and the test result isn't increase continuously as same as the result with nort 3.4.26 kernel as follow:

       0:     636:       8
       0:     637:       7
       0:     638:       8
       0:     639:       9
       0:     640:       7
       0:     641:       9
       0:     642:       8
       0:     643:       8
       0:     644:       8
       0:     645:      32
       0:     646:    8683
       0:     647:    7760
       0:     648:    6784
       0:     649:    5797
       0:     650:    4810
       0:     651:    3823
       0:     652:    2836
       0:     653:    1849
       0:     654:     862
       0:     655:       7
       0:     656:       7
       0:     657:       7
       0:     658:       6
       0:     659:       8
       0:     660:       7

---
 kernel/hrtimer.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

index 3f7d3b5b0717..afb62c7cc494 100644
@@ -1457,7 +1457,11 @@ static int hrtimer_rt_defer(struct hrtimer *timer)
 
 #else
 
-static inline void hrtimer_rt_run_pending(void) { }
+static inline void hrtimer_rt_run_pending(void)
+{
+	hrtimer_peek_ahead_timers();
+}
+
 static inline int hrtimer_rt_defer(struct hrtimer *timer) { return 0; }
 
 #endif

2.0.0

3.4.97-rt121-rc1 stable review patch.
If anyone has any objections, please let me know.

------------------

From: "Steven Rostedt (Red Hat)" <[email protected]>

---
 localversion-rt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index fff72aad59ab..6096ce5ed673 100644
@@ -1 +1 @@
--rt120
+-rt121-rc1

2.0.0