Skip to contentSkip to conversation

Linux v4.19.127-rt55-rc1

PATCH In review [email protected] 2 participants 6 messages Jun 11, 2020 – Jun 12, 2020

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

cover Linux v4.19.127-rt55-rc1

From: Tom Zanussi <[email protected]>

Dear RT Folks,

This is the RT stable review cycle of patch 4.19.127-rt55-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 2020-06-18.

To build 4.19.127-rt55-rc1 directly, the following patches should be applied:

https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.19.tar.xz

https://www.kernel.org/pub/linux/kernel/v4.x/patch-4.19.127.xz

https://www.kernel.org/pub/linux/kernel/projects/rt/4.19/patch-4.19.127-rt55-rc1.patch.xz

You can also build from 4.19.127-rt54 by applying the incremental patch:

https://www.kernel.org/pub/linux/kernel/projects/rt/4.19/incr/patch-4.19.127-rt54-rt55-rc1.patch.xz

Enjoy,

-- Tom

Kevin Hao (1):
mm: slub: Always flush the delayed empty slubs in flush_all()

Sebastian Andrzej Siewior (1):
fs/dcache: Include swait.h header

Tom Zanussi (2):
tasklet: Fix UP case for tasklet CHAINED state
Linux 4.19.127-rt55-rc1

 fs/proc/base.c   | 1 +
 kernel/softirq.c | 6 ++++++
 localversion-rt  | 2 +-
 mm/slub.c        | 3 ---
 4 files changed, 8 insertions(+), 4 deletions(-)
Signature · 1 line
2.17.1
#1 lore raw

PATCH 1/4 fs/dcache: Include swait.h header

From: Sebastian Andrzej Siewior <[email protected]>

v4.19.127-rt55-rc1 stable review patch.
If anyone has any objections, please let me know.

-----------

[ Upstream commit 279f90ddf53cd6bd3c203fbbf488d642ea2603de ]

Include the swait.h header so it compiles even if not all patches are applied.

Conflicts:
fs/proc/base.c

---
 fs/proc/base.c | 1 +
 1 file changed, 1 insertion(+)
fs/proc/base.c +1 -0
index a45d4d640f01..56b1c4f1e8c0 100644
@@ -95,6 +95,7 @@
 #include <linux/flex_array.h>
 #include <linux/posix-timers.h>
 #include <trace/events/oom.h>
+#include <linux/swait.h>
 #include "internal.h"
 #include "fd.h"
 
Signature · 1 line
2.17.1
#3 lore raw

PATCH 3/4 tasklet: Fix UP case for tasklet CHAINED state

In reply to [email protected]

From: Tom Zanussi <[email protected]>

v4.19.127-rt55-rc1 stable review patch.
If anyone has any objections, please let me know.

-----------

commit 62d0a2a30cd0 (tasklet: Address a race resulting in double-enqueue) addresses a problem that can result in a tasklet being enqueued on two cpus at the same time by combining the RUN flag with a new CHAINED flag, and relies on the combination to be present in order to zero it out, which can never happen on (!SMP and !PREEMPT_RT_FULL) because the RUN flag is SMP/PREEMPT_RT_FULL-only.

So make sure the above commit is only applied for the SMP || PREEMPT_RT_FULL case.

Fixes 62d0a2a30cd0 ("tasklet: Address a race resulting in double-enqueue")
---
 kernel/softirq.c | 6 ++++++
 1 file changed, 6 insertions(+)
kernel/softirq.c +6 -0
index 73dae64bfc9c..9bad7a16dc61 100644
@@ -947,10 +947,12 @@ static void __tasklet_schedule_common(struct tasklet_struct *t,
 	 * is locked before adding it to the list.
 	 */
 	if (test_bit(TASKLET_STATE_SCHED, &t->state)) {
+#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT_RT_FULL)
 		if (test_and_set_bit(TASKLET_STATE_CHAINED, &t->state)) {
 			tasklet_unlock(t);
 			return;
 		}
+#endif
 		t->next = NULL;
 		*head->tail = t;
 		head->tail = &(t->next);
@@ -1044,7 +1046,11 @@ static void tasklet_action_common(struct softirq_action *a,
 again:
 		t->func(t->data);
 
+#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT_RT_FULL)
 		while (cmpxchg(&t->state, TASKLET_STATEF_RC, 0) != TASKLET_STATEF_RC) {
+#else
+		while (!tasklet_tryunlock(t)) {
+#endif
 			/*
 			 * If it got disabled meanwhile, bail out:
 			 */
Signature · 1 line
2.17.1
#2 lore raw

PATCH 2/4 mm: slub: Always flush the delayed empty slubs in flush_all()

In reply to [email protected]

From: Kevin Hao <[email protected]>

v4.19.127-rt55-rc1 stable review patch.
If anyone has any objections, please let me know.

-----------

[ Upstream commit 23a2c31b19e99beaf5107071b0f32a596202cdae ]

After commit f0b231101c94 ("mm/SLUB: delay giving back empty slubs to IRQ enabled regions"), when the free_slab() is invoked with the IRQ disabled, the empty slubs are moved to a per-CPU list and will be freed after IRQ enabled later. But in the current codes, there is a check to see if there really has the cpu slub on a specific cpu before flushing the delayed empty slubs, this may cause a reference of already released kmem_cache in a scenario like below:

	cpu 0				cpu 1
  kmem_cache_destroy()
    flush_all()
                         --->IPI       flush_cpu_slab()
                                         flush_slab()
                                           deactivate_slab()
                                             discard_slab()
                                               free_slab()
                                             c->page = NULL;
      for_each_online_cpu(cpu)
        if (!has_cpu_slab(1, s))
          continue
        this skip to flush the delayed
        empty slub released by cpu1
    kmem_cache_free(kmem_cache, s)

                                       kmalloc()
                                         __slab_alloc()
                                            free_delayed()
                                            __free_slab()
                                            reference to released kmem_cache
Fixes f0b231101c94 ("mm/SLUB: delay giving back empty slubs to IRQ enabled regions")
---
 mm/slub.c | 3 ---
 1 file changed, 3 deletions(-)
mm/slub.c +0 -3
index d243c6ef7fc9..a9473bbb1338 100644
@@ -2341,9 +2341,6 @@ static void flush_all(struct kmem_cache *s)
 	for_each_online_cpu(cpu) {
 		struct slub_free_list *f;
 
-		if (!has_cpu_slab(cpu, s))
-			continue;
-
 		f = &per_cpu(slub_free_list, cpu);
 		raw_spin_lock_irq(&f->lock);
 		list_splice_init(&f->list, &tofree);
Signature · 1 line
2.17.1
Acked-by on v1 3/4
#4 lore raw

Re: [PATCH RT 3/4] tasklet: Fix UP case for tasklet CHAINED state

In reply to [email protected]
Quoted 7 lines · On 2020-06-11 13:10:16 [-0500], [email protected] wrote:

commit 62d0a2a30cd0 (tasklet: Address a race resulting in double-enqueue) addresses a problem that can result in a tasklet being enqueued on two cpus at the same time by combining the RUN flag with a new CHAINED flag, and relies on the combination to be present in order to zero it out, which can never happen on (!SMP and !PREEMPT_RT_FULL) because the RUN flag is SMP/PREEMPT_RT_FULL-only.

Quoted 7 lines

So make sure the above commit is only applied for the SMP || PREEMPT_RT_FULL case.

Fixes 62d0a2a30cd0 ("tasklet: Address a race resulting in double-enqueue")

Sebastian