Linux 3.18.129-rt111-rc1
Subsystems (10)
cover Linux 3.18.129-rt111-rc1
From: Tom Zanussi <[email protected]>
Hello RT Folks!
This is the RT stable review cycle of patch 3.18.129-rt111-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 12/24/2018.
To build 3.18.129-rt111-rc1 directly, the following patches should be applied:
http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.18.tar.xz
http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.18.129.xz
http://www.kernel.org/pub/linux/kernel/projects/rt/3.18/patch-3.18.129-rt111-rc1.patch.xz
You can also build from 3.18.129-rt110 by applying the incremental patch:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.18/incr/patch-3.18.129-rt110-rt111-rc1.patch.xz
Enjoy!
Tom
Changes from v3.18.129-rt110:
---
Daniel Bristot de Oliveira (1):
sched/core: Avoid __schedule() being called twice in a row
Kurt Kanzenbach (1):
tty: serial: pl011: explicitly initialize the flags variable
Lukas Wunner (1):
pinctrl: bcm2835: Use raw spinlock for RT compatibility
Sebastian Andrzej Siewior (5):
efi: Allow efi=runtime
efi: Disable runtime services on RT
crypto: cryptd - add a lock instead preempt_disable/local_bh_disable
work-simple: drop a shit statement in SWORK_EVENT_PENDING drm/i915: disable tracing on -RT
Tom Zanussi (1):
Linux 3.18.129-rt111-rc1
crypto/cryptd.c | 18 ++++++++---------- drivers/firmware/efi/efi.c | 5 ++++- drivers/gpu/drm/i915/i915_trace.h | 4 ++++ drivers/pinctrl/pinctrl-bcm2835.c | 16 ++++++++-------- drivers/tty/serial/amba-pl011.c | 2 +- kernel/sched/core.c | 9 +++++++-- kernel/sched/work-simple.c | 2 +- localversion-rt | 2 +- 8 files changed, 34 insertions(+), 24 deletions(-)
Signature · 1 line
2.14.1
PATCH 1/9 efi: Allow efi=runtime
v3.18.129-rt111 rt-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <[email protected]>
[ Upstream commit 71bef7da4112ed2677d4f10a58202a5a4638fb90 ]
In case the option "efi=noruntime" is default at built-time, the user could overwrite its sate by `efi=runtime' and allow it again.
--- drivers/firmware/efi/efi.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/firmware/efi/efi.c +3 -0
@@ -59,6 +59,9 @@ static int __init parse_efi_cmdline(char *str)if (parse_option_str (str,"noruntime" )) disable_runtime = true; +if (parse_option_str (str,"runtime" )) + disable_runtime = false; +return 0 ; }early_param ("efi" , parse_efi_cmdline);
Signature · 1 line
2.14.1
PATCH 2/9 efi: Disable runtime services on RT
In reply to Tom Zanussiv3.18.129-rt111 rt-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <[email protected]>
[ Upstream commit 55544e1d5eb0d7608e2b41452729649c8ea1607a ]
Based on meassurements the EFI functions get_variable / get_next_variable take up to 2us which looks okay.
The functions get_time, set_time take around 10ms. Those 10ms are too much. Even one ms would be too much.
Ard mentioned that SetVariable might even trigger larger latencies if the firware will erase flash blocks on NOR.
The time-functions are used by efi-rtc and can be triggered during runtimed (either via explicit read/write or ntp sync).
The variable write could be used by pstore.
These functions can be disabled without much of a loss. The poweroff / reboot hooks may be provided by PSCI.
Disable EFI's runtime wrappers.
This was observed on "EFI v2.60 by SoftIron Overdrive 1000".
Conflicts:
drivers/firmware/efi/efi.c
--- drivers/firmware/efi/efi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/firmware/efi/efi.c +1 -1
@@ -41,7 +41,7 @@ struct efi __read_mostly efi = { };EXPORT_SYMBOL (efi); -static bool disable_runtime; +static bool disable_runtime =IS_ENABLED (CONFIG_PREEMPT_RT_BASE );static int __init setup_noefi (char *arg) { disable_runtime = true;
Signature · 1 line
2.14.1
PATCH 3/9 crypto: cryptd - add a lock instead preempt_disable/local_bh_disable
In reply to Tom Zanussiv3.18.129-rt111 rt-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <[email protected]>
[ Upstream commit 21aedb30d85979697f79a72a084e5d781e323663 ]
cryptd has a per-CPU lock which protected with local_bh_disable() and preempt_disable().
Add an explicit spin_lock to make the locking context more obvious and visible to lockdep. Since it is a per-CPU lock, there should be no lock contention on the actual spinlock.
There is a small race-window where we could be migrated to another CPU after the cpu_queue has been obtain. This is not a problem because the actual ressource is protected by the spinlock.
Conflicts:
crypto/cryptd.c
--- crypto/cryptd.c | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-)
crypto/cryptd.c +8 -10
@@ -36,6 +36,7 @@struct cryptd_cpu_queue {struct crypto_queue queue;struct work_struct work; +spinlock_t qlock; };struct cryptd_queue {
@@ -97,6 +98,7 @@ static int cryptd_init_queue(struct cryptd_queue *queue, cpu_queue =per_cpu_ptr (queue->cpu_queue, cpu);crypto_init_queue (&cpu_queue->queue, max_cpu_qlen);INIT_WORK (&cpu_queue->work, cryptd_queue_worker); +spin_lock_init (&cpu_queue->qlock); }return 0 ; }
@@ -119,11 +121,12 @@ static int cryptd_enqueue_request(struct cryptd_queue *queue,int cpu, err;struct cryptd_cpu_queue *cpu_queue; - cpu =get_cpu (); - cpu_queue =this_cpu_ptr (queue->cpu_queue); + cpu_queue =raw_cpu_ptr (queue->cpu_queue); +spin_lock_bh (&cpu_queue->qlock); + cpu =smp_processor_id (); err =crypto_enqueue_request (&cpu_queue->queue, request);queue_work_on (cpu, kcrypto_wq, &cpu_queue->work); -put_cpu (); +spin_unlock_bh (&cpu_queue->qlock);return err; }
@@ -139,16 +142,11 @@ static void cryptd_queue_worker(struct work_struct *work) cpu_queue = container_of(work, struct cryptd_cpu_queue, work);/* * Only handle one request at a time to avoid hogging crypto workqueue. -* preempt_disable/enable is used to prevent being preempted by -* cryptd_enqueue_request(). local_bh_disable/enable is used to prevent -* cryptd_enqueue_request() being accessed from software interrupts. */ -local_bh_disable (); -preempt_disable (); +spin_lock_bh (&cpu_queue->qlock); backlog =crypto_get_backlog (&cpu_queue->queue); req =crypto_dequeue_request (&cpu_queue->queue); -preempt_enable (); -local_bh_enable (); +spin_unlock_bh (&cpu_queue->qlock);if (!req)return ;
Signature · 1 line
2.14.1
PATCH 4/9 sched/core: Avoid __schedule() being called twice in a row
In reply to Tom Zanussiv3.18.129-rt111 rt-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Bristot de Oliveira <[email protected]>
[ Upstream commit 2bb94c48b2ffaabf8c15a51e5cc1b4c541988cab ]
If a worker invokes schedule() then we may have the call chain:
schedule()
-> sched_submit_work()
-> wq_worker_sleeping()
-> wake_up_worker()
-> wake_up_process().The last wakeup may cause a schedule which is unnecessary because we are already in schedule() and do it anyway.
Add a preempt_disable() + preempt_enable_no_resched() around wq_worker_sleeping() so the context switch could be delayed until __schedule().
--- kernel/sched/core.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
kernel/sched/core.c +7 -2
@@ -3114,10 +3114,15 @@ static inline void sched_submit_work(struct task_struct *tsk)/* * If a worker went to sleep, notify and ask workqueue whether * it wants to wake up a task to maintain concurrency. +* As this function is called inside the schedule() context, +* we disable preemption to avoid it calling schedule() again +* in the possible wakeup of a kworker. */ -if (tsk->flags &PF_WQ_WORKER ) +if (tsk->flags &PF_WQ_WORKER ) { +preempt_disable ();wq_worker_sleeping (tsk); - +preempt_enable_no_resched (); + }if (tsk_is_pi_blocked (tsk))return ;
Signature · 1 line
2.14.1
PATCH 5/9 work-simple: drop a shit statement in SWORK_EVENT_PENDING
In reply to Tom Zanussiv3.18.129-rt111 rt-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <[email protected]>
[ Upstream commit 22f41ebe5579cc847a7bb6c71916be92c8926216 ]
Dan Carpenter reported
| smatch warnings:
|kernel/sched/swork.c:63 swork_kthread() warn: test_bit() takes a bit number
This is not a bug because we shift by zero (and use the same value in both places).
Nevertheless I'm dropping that shift by zero to keep smatch quiet.
--- kernel/sched/work-simple.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/sched/work-simple.c +1 -1
@@ -11,7 +11,7 @@#include <linux/slab.h> #include <linux/spinlock.h> -#define SWORK_EVENT_PENDING (1 << 0) +#define SWORK_EVENT_PENDING 1static DEFINE_MUTEX (worker_mutex);static struct sworker *glob_worker;
Signature · 1 line
2.14.1
PATCH 6/9 tty: serial: pl011: explicitly initialize the flags variable
In reply to Tom Zanussiv3.18.129-rt111 rt-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kurt Kanzenbach <[email protected]>
[ Upstream commit 3260983a587d528811a15fc00fa2a9e4473c4453 ]
Silence the following gcc warning:
drivers/tty/serial/amba-pl011.c: In function ‘pl011_console_write’:./include/linux/spinlock.h:260:3: warning: ‘flags’ may be used uninitialized in this function [-Wmaybe-uninitialized]
_raw_spin_unlock_irqrestore(lock, flags); \
^~~~~~~~~~~~~~~~~~~~~~~~~~~drivers/tty/serial/amba-pl011.c:2214:16: note: ‘flags’ was declared here
unsigned long flags;
^~~~~The code is correct. Thus, initializing flags to zero doesn't change the behavior and resolves the warning.
--- drivers/tty/serial/amba-pl011.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/tty/serial/amba-pl011.c +1 -1
@@ -1930,7 +1930,7 @@ pl011_console_write(struct console *co, const char *s, unsigned int count) {struct uart_amba_port *uap = amba_ports[co->index];unsigned int status, old_cr, new_cr; -unsigned long flags; +unsigned long flags =0 ;int locked =1 ;clk_enable (uap->clk);
Signature · 1 line
2.14.1
PATCH 7/9 pinctrl: bcm2835: Use raw spinlock for RT compatibility
In reply to Tom Zanussiv3.18.129-rt111 rt-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukas Wunner <[email protected]>
[Upstream rt-devel commit 55016fa934eb0d4e037beef2b2f503012dfebeac]
[Upstream commit 71dfaa749f2f7c1722ebf6716d3f797a04528cba]
The BCM2835 pinctrl driver acquires a spinlock in its ->irq_enable, ->irq_disable and ->irq_set_type callbacks. Spinlocks become sleeping locks with CONFIG_PREEMPT_RT_FULL=y, therefore invocation of one of the callbacks in atomic context may cause a hard lockup if at least two GPIO pins in the same bank are used as interrupts. The issue doesn't occur with just a single interrupt pin per bank because the lock is never contended. I'm experiencing such lockups with GPIO 8 and 28 used as level-triggered interrupts, i.e. with ->irq_disable being invoked on reception of every IRQ.
The critical section protected by the spinlock is very small (one bitop and one RMW of an MMIO register), hence converting to a raw spinlock seems a better trade-off than converting the driver to threaded IRQ handling (which would increase latency to handle an interrupt).
Conflicts:
drivers/pinctrl/bcm/pinctrl-bcm2835.c
--- drivers/pinctrl/pinctrl-bcm2835.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
drivers/pinctrl/pinctrl-bcm2835.c +8 -8
@@ -106,7 +106,7 @@ struct bcm2835_pinctrl {struct pinctrl_gpio_range gpio_range;struct bcm2835_gpio_irqdata irq_data[BCM2835_NUM_BANKS ]; -spinlock_t irq_lock[BCM2835_NUM_BANKS ]; +raw_spinlock_t irq_lock[BCM2835_NUM_BANKS ]; };static struct lock_class_key gpio_lock_class;
@@ -465,10 +465,10 @@ static void bcm2835_gpio_irq_enable(struct irq_data *data)unsigned bank =GPIO_REG_OFFSET (gpio);unsigned long flags; -spin_lock_irqsave (&pc->irq_lock[bank], flags); +raw_spin_lock_irqsave (&pc->irq_lock[bank], flags);set_bit (offset, &pc->enabled_irq_map[bank]);bcm2835_gpio_irq_config (pc, gpio, true); -spin_unlock_irqrestore (&pc->irq_lock[bank], flags); +raw_spin_unlock_irqrestore (&pc->irq_lock[bank], flags); }static void bcm2835_gpio_irq_disable (struct irq_data *data)
@@ -479,10 +479,10 @@ static void bcm2835_gpio_irq_disable(struct irq_data *data)unsigned bank =GPIO_REG_OFFSET (gpio);unsigned long flags; -spin_lock_irqsave (&pc->irq_lock[bank], flags); +raw_spin_lock_irqsave (&pc->irq_lock[bank], flags);bcm2835_gpio_irq_config (pc, gpio, false);clear_bit (offset, &pc->enabled_irq_map[bank]); -spin_unlock_irqrestore (&pc->irq_lock[bank], flags); +raw_spin_unlock_irqrestore (&pc->irq_lock[bank], flags); } static int __bcm2835_gpio_irq_set_type_disabled(struct bcm2835_pinctrl *pc,
@@ -584,14 +584,14 @@ static int bcm2835_gpio_irq_set_type(struct irq_data *data, unsigned int type)unsigned long flags;int ret; -spin_lock_irqsave (&pc->irq_lock[bank], flags); +raw_spin_lock_irqsave (&pc->irq_lock[bank], flags);if (test_bit (offset, &pc->enabled_irq_map[bank])) ret =__bcm2835_gpio_irq_set_type_enabled (pc, gpio, type);else ret =__bcm2835_gpio_irq_set_type_disabled (pc, gpio, type); -spin_unlock_irqrestore (&pc->irq_lock[bank], flags); +raw_spin_unlock_irqrestore (&pc->irq_lock[bank], flags);return ret; }
@@ -1004,7 +1004,7 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev) pc->irq[i] =irq_of_parse_and_map (np, i); pc->irq_data[i].pc = pc; pc->irq_data[i].bank = i; -spin_lock_init (&pc->irq_lock[i]); +raw_spin_lock_init (&pc->irq_lock[i]); len =strlen (dev_name (pc->dev)) +16 ; name =devm_kzalloc (pc->dev, len,GFP_KERNEL );
Signature · 1 line
2.14.1
PATCH 8/9 drm/i915: disable tracing on -RT
In reply to Tom Zanussiv3.18.129-rt111 rt-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <[email protected]>
[Upstream commit 05cebb309b156646e61b898e92acc8e46c47ba75]
Luca Abeni reported this:
| BUG: scheduling while atomic: kworker/u8:2/15203/0x00000003 | CPU: 1 PID: 15203 Comm: kworker/u8:2 Not tainted 4.19.1-rt3 #10 | Call Trace: | rt_spin_lock+0x3f/0x50 | gen6_read32+0x45/0x1d0 [i915] | g4x_get_vblank_counter+0x36/0x40 [i915] | trace_event_raw_event_i915_pipe_update_start+0x7d/0xf0 [i915]
The tracing events use trace_i915_pipe_update_start() among other events use functions acquire spin locks. A few trace points use intel_get_crtc_scanline(), others use ->get_vblank_counter() wich also might acquire a sleeping lock.
Based on this I don't see any other way than disable trace points on RT.
--- drivers/gpu/drm/i915/i915_trace.h | 4 ++++ 1 file changed, 4 insertions(+)
drivers/gpu/drm/i915/i915_trace.h +4 -0
@@ -1,6 +1,10 @@#if !defined(_I915_TRACE_H_) || defined(TRACE_HEADER_MULTI_READ )#define _I915_TRACE_H_ +#ifdef CONFIG_PREEMPT_RT_BASE +#define NOTRACE +#endif +#include <linux/stringify.h> #include <linux/types.h> #include <linux/tracepoint.h>
Signature · 1 line
2.14.1
PATCH 9/9 Linux 3.18.129-rt111-rc1
In reply to Tom Zanussiv3.18.129-rt111 rt-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tom Zanussi <[email protected]>
--- localversion-rt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
localversion-rt +1 -1
@@ -1 +1 @@ --rt110 +-rt111-rc1
Signature · 1 line
2.14.1