Skip to contentSkip to conversation

Linux 4.4.102-rt117-rc1

PATCH In review Steven Rostedt 2 participants 15 messages Dec 2, 2017 – Dec 11, 2017

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

cover Linux 4.4.102-rt117-rc1

Dear RT Folks,

This is the RT stable review cycle of patch 4.4.102-rt117-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 11/5/2017.

Enjoy,

-- Steve

To build 4.4.102-rt117-rc1 directly, the following patches should be applied:

http://www.kernel.org/pub/linux/kernel/v4.x/linux-4.4.tar.xz

http://www.kernel.org/pub/linux/kernel/v4.x/patch-4.4.102.xz

http://www.kernel.org/pub/linux/kernel/projects/rt/4.4/patch-4.4.102-rt117-rc1.patch.xz

You can also build from 4.4.102-rt116 by applying the incremental patch:

http://www.kernel.org/pub/linux/kernel/projects/rt/4.4/incr/patch-4.4.102-rt116-rt117-rc1.patch.xz

Changes from 4.4.102-rt116:

---

Alex Shi (1):
cpu_pm: replace raw_notifier to atomic_notifier

Mike Galbraith (1):
kernel/hrtimer/hotplug: don't wake ktimersoftd while holding the hrtimer base lock

Sebastian Andrzej Siewior (6):
Revert "fs: jbd2: pull your plug when waiting for space" kernel/hrtimer: migrate deferred timer on CPU down kernel/hrtimer: don't wakeup a process while holding the hrtimer base lock
Bluetooth: avoid recursive locking in hci_send_to_channel() rt/locking: allow recursive local_trylock()
net: use trylock in icmp_sk

Steven Rostedt (VMware) (1):

      Linux 4.4.102-rt117-rc1

----

 fs/jbd2/checkpoint.c      |  2 --
 include/linux/locallock.h |  9 +++++++++
 kernel/cpu_pm.c           | 43 ++++++-------------------------------------
 kernel/time/hrtimer.c     | 35 ++++++++++++++++++++++++++---------
 localversion-rt           |  2 +-
 net/bluetooth/hci_sock.c  | 17 +++++++++++------
 net/ipv4/icmp.c           |  6 +++++-
 7 files changed, 58 insertions(+), 56 deletions(-)
#1 lore raw

PATCH 1/9 Revert "fs: jbd2: pull your plug when waiting for space"

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

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

From: Sebastian Andrzej Siewior <[email protected]>

This reverts commit "fs: jbd2: pull your plug when waiting for space". This was a duct-tape fix which shouldn't be needed since commit "locking/rt-mutex: fix deadlock in device mapper / block-IO".

---
 fs/jbd2/checkpoint.c | 2 --
 1 file changed, 2 deletions(-)
fs/jbd2/checkpoint.c +0 -2
index 6e18a06aaabe..684996c8a3a4 100644
@@ -116,8 +116,6 @@ void __jbd2_log_wait_for_space(journal_t *journal)
 	nblocks = jbd2_space_needed(journal);
 	while (jbd2_log_space_left(journal) < nblocks) {
 		write_unlock(&journal->j_state_lock);
-		if (current->plug)
-			io_schedule();
 		mutex_lock(&journal->j_checkpoint_mutex);
 
 		/*
Signature · 1 line
2.13.2
#2 lore raw

Re: [PATCH RT 1/9] Revert "fs: jbd2: pull your plug when waiting for space"

Quoted 2 lines · Steven Rostedt

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

Same comment as in the 4.9.65-rt57-rc2 review (that you might need locking-rt-mutex-fix-deadlock-in-device-mapper-block.patch).

Sebastian

#3 lore raw

Re: [PATCH RT 1/9] Revert "fs: jbd2: pull your plug when waiting for space"

Quoted 6 lines · On Mon, 4 Dec 2017 09:45:45 +0100 Sebastian Andrzej Siewior…
Quoted 2 lines · Steven Rostedt

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

Same comment as in the 4.9.65-rt57-rc2 review (that you might need locking-rt-mutex-fix-deadlock-in-device-mapper-block.patch).

Now it does appear I'm missing that for 4.4. I wonder why I didn't pull it in there. Perhaps it wasn't needed, which means this isn't needed either.

Thanks!

-- Steve

#4 lore raw

Re: [PATCH RT 1/9] Revert "fs: jbd2: pull your plug when waiting for space"

Quoted 7 lines · Steven Rostedt
Quoted 4 lines · On Mon, 4 Dec 2017 09:45:45 +0100 Sebastian Andrzej Siewior…
Quoted 2 lines · Steven Rostedt

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

Quoted 6 lines
Quoted 2 lines

Same comment as in the 4.9.65-rt57-rc2 review (that you might need locking-rt-mutex-fix-deadlock-in-device-mapper-block.patch).

Now it does appear I'm missing that for 4.4. I wonder why I didn't pull it in there. Perhaps it wasn't needed, which means this isn't needed either.

I strongly suggest to include "locking/rt-mutex: fix deadlock in device mapper / block-IO". We had a workaround in the jbd/ext3 code which then moved into jbd2/ext4 after people complained about the same problem. I wasn't sure about the root-cause back then but now with explanation we have in the fix patch I'm sure this is one of the bugs we have since day one.

Quoted 3 lines

Thanks!

-- Steve

Sebastian

#5 lore raw

Re: [PATCH RT 1/9] Revert "fs: jbd2: pull your plug when waiting for space"

Quoted 10 lines · On Mon, 11 Dec 2017 16:37:09 +0100 Sebastian Andrzej Siewior…
Quoted 3 lines

Now it does appear I'm missing that for 4.4. I wonder why I didn't pull it in there. Perhaps it wasn't needed, which means this isn't needed either.

I strongly suggest to include "locking/rt-mutex: fix deadlock in device mapper / block-IO". We had a workaround in the jbd/ext3 code which then moved into jbd2/ext4 after people complained about the same problem. I wasn't sure about the root-cause back then but now with explanation we have in the fix patch I'm sure this is one of the bugs we have since day one.

Yep. Not sure why I didn't include it in 4.4. I added it to my queue, and started testing it, which is one of the reasons I haven't posted it yet. Also, my internet connectivity has be really poor while traveling this time.

-- Steve

#6 lore raw

Re: [PATCH RT 1/9] Revert "fs: jbd2: pull your plug when waiting for space"

Quoted 5 lines · Steven Rostedt

Yep. Not sure why I didn't include it in 4.4. I added it to my queue, and started testing it, which is one of the reasons I haven't posted it yet. Also, my internet connectivity has be really poor while traveling this time.

Ah okay then. I misunderstood you then as I though that you would skip that patch and the revert (and keep things as they are). Sorry for that.

Quoted 1 line

-- Steve

Sebastian

#7 lore raw

PATCH 2/9 cpu_pm: replace raw_notifier to atomic_notifier

In reply to Steven Rostedt

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

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

From: Alex Shi <[email protected]>

This patch replace a rwlock and raw notifier by atomic notifier which protected by spin_lock and rcu.

The first to reason to have this replace is due to a 'scheduling while
atomic' bug of RT kernel on arm/arm64 platform. On arm/arm64, rwlock
cpu_pm_notifier_lock in cpu_pm cause a potential schedule after irq disable in idle call chain:

cpu_startup_entry
cpu_idle_loop

    local_irq_disable()
    cpuidle_idle_call
      call_cpuidle
        cpuidle_enter
          cpuidle_enter_state
            ->enter :arm_enter_idle_state
              cpu_pm_enter/exit
                CPU_PM_CPU_IDLE_ENTER
                  read_lock(&cpu_pm_notifier_lock); <-- sleep in idle
                     __rt_spin_lock();
                        schedule();

The kernel panic is here:

[    4.609601] BUG: scheduling while atomic: swapper/1/0/0x00000002
[    4.609608] [<ffff0000086fae70>] arm_enter_idle_state+0x18/0x70
[    4.609614] Modules linked in:
[    4.609615] [<ffff0000086f9298>] cpuidle_enter_state+0xf0/0x218
[    4.609620] [<ffff0000086f93f8>] cpuidle_enter+0x18/0x20
[    4.609626] Preemption disabled at:
[    4.609627] [<ffff0000080fa234>] call_cpuidle+0x24/0x40
[    4.609635] [<ffff000008882fa4>] schedule_preempt_disabled+0x1c/0x28
[    4.609639] [<ffff0000080fa49c>] cpu_startup_entry+0x154/0x1f8
[    4.609645] [<ffff00000808e004>] secondary_start_kernel+0x15c/0x1a0

Daniel Lezcano said this notification is needed on arm/arm64 platforms. Sebastian suggested using atomic_notifier instead of rwlock, which is not only removing the sleeping in idle, but also getting better latency improvement.

This patch passed Fengguang's 0day testing.

Cc Sebastian Andrzej Siewior <[email protected]>
Cc Thomas Gleixner <[email protected]>
Cc Anders Roxell <[email protected]>
Cc Rik van Riel <[email protected]>
Cc Steven Rostedt <[email protected]>
Cc Rafael J. Wysocki <[email protected]>
Cc Daniel Lezcano <[email protected]>
Cc linux-rt-users <[email protected]>
---
 kernel/cpu_pm.c | 43 ++++++-------------------------------------
 1 file changed, 6 insertions(+), 37 deletions(-)
kernel/cpu_pm.c +6 -37
index 009cc9a17d95..10f4640f991e 100644
@@ -22,14 +22,13 @@
 #include <linux/spinlock.h>
 #include <linux/syscore_ops.h>
 
-static DEFINE_RWLOCK(cpu_pm_notifier_lock);
-static RAW_NOTIFIER_HEAD(cpu_pm_notifier_chain);
+static ATOMIC_NOTIFIER_HEAD(cpu_pm_notifier_chain);
 
 static int cpu_pm_notify(enum cpu_pm_event event, int nr_to_call, int *nr_calls)
 {
 	int ret;
 
-	ret = __raw_notifier_call_chain(&cpu_pm_notifier_chain, event, NULL,
+	ret = __atomic_notifier_call_chain(&cpu_pm_notifier_chain, event, NULL,
 		nr_to_call, nr_calls);
 
 	return notifier_to_errno(ret);
@@ -47,14 +46,7 @@ static int cpu_pm_notify(enum cpu_pm_event event, int nr_to_call, int *nr_calls)
  */
 int cpu_pm_register_notifier(struct notifier_block *nb)
 {
-	unsigned long flags;
-	int ret;
-
-	write_lock_irqsave(&cpu_pm_notifier_lock, flags);
-	ret = raw_notifier_chain_register(&cpu_pm_notifier_chain, nb);
-	write_unlock_irqrestore(&cpu_pm_notifier_lock, flags);
-
-	return ret;
+	return atomic_notifier_chain_register(&cpu_pm_notifier_chain, nb);
 }
 EXPORT_SYMBOL_GPL(cpu_pm_register_notifier);
 
@@ -69,14 +61,7 @@ EXPORT_SYMBOL_GPL(cpu_pm_register_notifier);
  */
 int cpu_pm_unregister_notifier(struct notifier_block *nb)
 {
-	unsigned long flags;
-	int ret;
-
-	write_lock_irqsave(&cpu_pm_notifier_lock, flags);
-	ret = raw_notifier_chain_unregister(&cpu_pm_notifier_chain, nb);
-	write_unlock_irqrestore(&cpu_pm_notifier_lock, flags);
-
-	return ret;
+	return atomic_notifier_chain_unregister(&cpu_pm_notifier_chain, nb);
 }
 EXPORT_SYMBOL_GPL(cpu_pm_unregister_notifier);
 
@@ -100,7 +85,6 @@ int cpu_pm_enter(void)
 	int nr_calls;
 	int ret = 0;
 
-	read_lock(&cpu_pm_notifier_lock);
 	ret = cpu_pm_notify(CPU_PM_ENTER, -1, &nr_calls);
 	if (ret)
 		/*
@@ -108,7 +92,6 @@ int cpu_pm_enter(void)
 		 * PM entry who are notified earlier to prepare for it.
 		 */
 		cpu_pm_notify(CPU_PM_ENTER_FAILED, nr_calls - 1, NULL);
-	read_unlock(&cpu_pm_notifier_lock);
 
 	return ret;
 }
@@ -128,13 +111,7 @@ EXPORT_SYMBOL_GPL(cpu_pm_enter);
  */
 int cpu_pm_exit(void)
 {
-	int ret;
-
-	read_lock(&cpu_pm_notifier_lock);
-	ret = cpu_pm_notify(CPU_PM_EXIT, -1, NULL);
-	read_unlock(&cpu_pm_notifier_lock);
-
-	return ret;
+	return cpu_pm_notify(CPU_PM_EXIT, -1, NULL);
 }
 EXPORT_SYMBOL_GPL(cpu_pm_exit);
 
@@ -159,7 +136,6 @@ int cpu_cluster_pm_enter(void)
 	int nr_calls;
 	int ret = 0;
 
-	read_lock(&cpu_pm_notifier_lock);
 	ret = cpu_pm_notify(CPU_CLUSTER_PM_ENTER, -1, &nr_calls);
 	if (ret)
 		/*
@@ -167,7 +143,6 @@ int cpu_cluster_pm_enter(void)
 		 * PM entry who are notified earlier to prepare for it.
 		 */
 		cpu_pm_notify(CPU_CLUSTER_PM_ENTER_FAILED, nr_calls - 1, NULL);
-	read_unlock(&cpu_pm_notifier_lock);
 
 	return ret;
 }
@@ -190,13 +165,7 @@ EXPORT_SYMBOL_GPL(cpu_cluster_pm_enter);
  */
 int cpu_cluster_pm_exit(void)
 {
-	int ret;
-
-	read_lock(&cpu_pm_notifier_lock);
-	ret = cpu_pm_notify(CPU_CLUSTER_PM_EXIT, -1, NULL);
-	read_unlock(&cpu_pm_notifier_lock);
-
-	return ret;
+	return cpu_pm_notify(CPU_CLUSTER_PM_EXIT, -1, NULL);
 }
 EXPORT_SYMBOL_GPL(cpu_cluster_pm_exit);
 
Signature · 1 line
2.13.2
#8 lore raw

PATCH 3/9 kernel/hrtimer: migrate deferred timer on CPU down

In reply to Steven Rostedt

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

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

From: Sebastian Andrzej Siewior <[email protected]>

hrtimers, which were deferred to the softirq context, and expire between softirq shutdown and hrtimer migration are dangling around. If the CPU goes back up the list head will be initialized and this corrupts the timer's list. It will remain unnoticed until a hrtimer_cancel(). This moves those timers so they will expire.

---
 kernel/time/hrtimer.c | 5 +++++
 1 file changed, 5 insertions(+)
kernel/time/hrtimer.c +5 -0
index ba3d60144838..759913626eec 100644
@@ -1880,6 +1880,11 @@ static void migrate_hrtimer_list(struct hrtimer_clock_base *old_base,
 		 */
 		enqueue_hrtimer(timer, new_base);
 	}
+#ifdef CONFIG_PREEMPT_RT_BASE
+	list_splice_tail(&old_base->expired, &new_base->expired);
+	if (!list_empty(&new_base->expired))
+		raise_softirq_irqoff(HRTIMER_SOFTIRQ);
+#endif
 }
 
 static void migrate_hrtimers(int scpu)
Signature · 1 line
2.13.2
#9 lore raw

PATCH 4/9 kernel/hrtimer: dont wakeup a process while holding the hrtimer base lock

In reply to Steven Rostedt

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

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

From: Sebastian Andrzej Siewior <[email protected]>

We must not wake any process (and thus acquire the pi->lock) while holding the hrtimer's base lock. This does not happen usually because the hrtimer-callback is invoked in IRQ-context and so raise_softirq_irqoff() does not wakeup a process.
However during CPU-hotplug it might get called from hrtimers_dead_cpu() which would wakeup the thread immediately.

---
 kernel/time/hrtimer.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)
kernel/time/hrtimer.c +10 -5
index 759913626eec..78066f7ea2a2 100644
@@ -1461,7 +1461,7 @@ static inline int hrtimer_rt_defer(struct hrtimer *timer) { return 0; }
 
 static enum hrtimer_restart hrtimer_wakeup(struct hrtimer *timer);
 
-static void __hrtimer_run_queues(struct hrtimer_cpu_base *cpu_base, ktime_t now)
+static int __hrtimer_run_queues(struct hrtimer_cpu_base *cpu_base, ktime_t now)
 {
 	struct hrtimer_clock_base *base = cpu_base->clock_base;
 	unsigned int active = cpu_base->active_bases;
@@ -1511,8 +1511,7 @@ static void __hrtimer_run_queues(struct hrtimer_cpu_base *cpu_base, ktime_t now)
 				raise = 1;
 		}
 	}
-	if (raise)
-		raise_softirq_irqoff(HRTIMER_SOFTIRQ);
+	return raise;
 }
 
 #ifdef CONFIG_HIGH_RES_TIMERS
@@ -1526,6 +1525,7 @@ void hrtimer_interrupt(struct clock_event_device *dev)
 	struct hrtimer_cpu_base *cpu_base = this_cpu_ptr(&hrtimer_bases);
 	ktime_t expires_next, now, entry_time, delta;
 	int retries = 0;
+	int raise;
 
 	BUG_ON(!cpu_base->hres_active);
 	cpu_base->nr_events++;
@@ -1544,7 +1544,7 @@ retry:
 	 */
 	cpu_base->expires_next.tv64 = KTIME_MAX;
 
-	__hrtimer_run_queues(cpu_base, now);
+	raise = __hrtimer_run_queues(cpu_base, now);
 
 	/* Reevaluate the clock bases for the next expiry */
 	expires_next = __hrtimer_get_next_event(cpu_base);
@@ -1555,6 +1555,8 @@ retry:
 	cpu_base->expires_next = expires_next;
 	cpu_base->in_hrtirq = 0;
 	raw_spin_unlock(&cpu_base->lock);
+	if (raise)
+		raise_softirq_irqoff(HRTIMER_SOFTIRQ);
 
 	/* Reprogramming necessary ? */
 	if (!tick_program_event(expires_next, 0)) {
@@ -1634,6 +1636,7 @@ void hrtimer_run_queues(void)
 {
 	struct hrtimer_cpu_base *cpu_base = this_cpu_ptr(&hrtimer_bases);
 	ktime_t now;
+	int raise;
 
 	if (__hrtimer_hres_active(cpu_base))
 		return;
@@ -1652,8 +1655,10 @@ void hrtimer_run_queues(void)
 
 	raw_spin_lock(&cpu_base->lock);
 	now = hrtimer_update_base(cpu_base);
-	__hrtimer_run_queues(cpu_base, now);
+	raise = __hrtimer_run_queues(cpu_base, now);
 	raw_spin_unlock(&cpu_base->lock);
+	if (raise)
+		raise_softirq_irqoff(HRTIMER_SOFTIRQ);
 }
 
 /*
Signature · 1 line
2.13.2
#10 lore raw

PATCH 5/9 kernel/hrtimer/hotplug: dont wake ktimersoftd while holding the hrtimer base lock

In reply to Steven Rostedt

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

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

From: Mike Galbraith <[email protected]>

kernel/hrtimer: don't wakeup a process while holding the hrtimer base lock missed a path, namely hrtimers_dead_cpu() -> migrate_hrtimer_list(). Defer raising softirq until after base lock has been released there as well.

---
 kernel/time/hrtimer.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)
kernel/time/hrtimer.c +13 -6
index 78066f7ea2a2..120fc8932165 100644
@@ -1857,7 +1857,7 @@ static void init_hrtimers_cpu(int cpu)
 
 #ifdef CONFIG_HOTPLUG_CPU
 
-static void migrate_hrtimer_list(struct hrtimer_clock_base *old_base,
+static int migrate_hrtimer_list(struct hrtimer_clock_base *old_base,
 				struct hrtimer_clock_base *new_base)
 {
 	struct hrtimer *timer;
@@ -1887,15 +1887,19 @@ static void migrate_hrtimer_list(struct hrtimer_clock_base *old_base,
 	}
 #ifdef CONFIG_PREEMPT_RT_BASE
 	list_splice_tail(&old_base->expired, &new_base->expired);
-	if (!list_empty(&new_base->expired))
-		raise_softirq_irqoff(HRTIMER_SOFTIRQ);
+	/*
+	 * Tell the caller to raise HRTIMER_SOFTIRQ.  We can't safely
+	 * acquire ktimersoftd->pi_lock while the base lock is held.
+	 */
+	return !list_empty(&new_base->expired);
 #endif
+	return 0;
 }
 
 static void migrate_hrtimers(int scpu)
 {
 	struct hrtimer_cpu_base *old_base, *new_base;
-	int i;
+	int i, raise = 0;
 
 	BUG_ON(cpu_online(scpu));
 	tick_cancel_sched_timer(scpu);
@@ -1911,13 +1915,16 @@ static void migrate_hrtimers(int scpu)
 	raw_spin_lock_nested(&old_base->lock, SINGLE_DEPTH_NESTING);
 
 	for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++) {
-		migrate_hrtimer_list(&old_base->clock_base[i],
-				     &new_base->clock_base[i]);
+		raise |= migrate_hrtimer_list(&old_base->clock_base[i],
+					      &new_base->clock_base[i]);
 	}
 
 	raw_spin_unlock(&old_base->lock);
 	raw_spin_unlock(&new_base->lock);
 
+	if (raise)
+		raise_softirq_irqoff(HRTIMER_SOFTIRQ);
+
 	/* Check, if we got expired work to do */
 	__hrtimer_peek_ahead_timers();
 	local_irq_enable();
Signature · 1 line
2.13.2
#11 lore raw

PATCH 6/9 Bluetooth: avoid recursive locking in hci_send_to_channel()

In reply to Steven Rostedt

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

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

From: Sebastian Andrzej Siewior <[email protected]>

Mart reported a deadlock in -RT in the call path:
hci_send_monitor_ctrl_event() -> hci_send_to_channel()

because both functions acquire the same read lock hci_sk_list.lock. This is also a mainline issue because the qrwlock implementation is writer fair (the traditional rwlock implementation is reader biased).

To avoid the deadlock there is now __hci_send_to_channel() which expects the readlock to be held.

Cc Marcel Holtmann <[email protected]>
Cc Johan Hedberg <[email protected]>
Fixes 38ceaa00d02d ("Bluetooth: Add support for sending MGMT commands and events to monitor")
---
 net/bluetooth/hci_sock.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)
net/bluetooth/hci_sock.c +11 -6
index c842f40c1173..035a5f6e3de9 100644
@@ -213,15 +213,13 @@ void hci_send_to_sock(struct hci_dev *hdev, struct sk_buff *skb)
 }
 
 /* Send frame to sockets with specific channel */
-void hci_send_to_channel(unsigned short channel, struct sk_buff *skb,
-			 int flag, struct sock *skip_sk)
+static void __hci_send_to_channel(unsigned short channel, struct sk_buff *skb,
+				  int flag, struct sock *skip_sk)
 {
 	struct sock *sk;
 
 	BT_DBG("channel %u len %d", channel, skb->len);
 
-	read_lock(&hci_sk_list.lock);
-
 	sk_for_each(sk, &hci_sk_list.head) {
 		struct sk_buff *nskb;
 
@@ -247,6 +245,13 @@ void hci_send_to_channel(unsigned short channel, struct sk_buff *skb,
 			kfree_skb(nskb);
 	}
 
+}
+
+void hci_send_to_channel(unsigned short channel, struct sk_buff *skb,
+			 int flag, struct sock *skip_sk)
+{
+	read_lock(&hci_sk_list.lock);
+	__hci_send_to_channel(channel, skb, flag, skip_sk);
 	read_unlock(&hci_sk_list.lock);
 }
 
@@ -299,8 +304,8 @@ void hci_send_to_monitor(struct hci_dev *hdev, struct sk_buff *skb)
 	hdr->index = cpu_to_le16(hdev->id);
 	hdr->len = cpu_to_le16(skb->len);
 
-	hci_send_to_channel(HCI_CHANNEL_MONITOR, skb_copy,
-			    HCI_SOCK_TRUSTED, NULL);
+	__hci_send_to_channel(HCI_CHANNEL_MONITOR, skb_copy,
+			      HCI_SOCK_TRUSTED, NULL);
 	kfree_skb(skb_copy);
 }
 
Signature · 1 line
2.13.2
#12 lore raw

PATCH 7/9 rt/locking: allow recursive local_trylock()

In reply to Steven Rostedt

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

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

From: Sebastian Andrzej Siewior <[email protected]>

required for following networking patch which does recursive try-lock. While at it, add the !RT version of it because it did not yet exist.

---
 include/linux/locallock.h | 9 +++++++++
 1 file changed, 9 insertions(+)
include/linux/locallock.h +9 -0
index e572a3971631..0baaf28dc4ee 100644
@@ -77,6 +77,9 @@ static inline int __local_trylock(struct local_irq_lock *lv)
 		lv->owner = current;
 		lv->nestcnt = 1;
 		return 1;
+	} else if (lv->owner == current) {
+		lv->nestcnt++;
+		return 1;
 	}
 	return 0;
 }
@@ -250,6 +253,12 @@ static inline int __local_unlock_irqrestore(struct local_irq_lock *lv,
 
 static inline void local_irq_lock_init(int lvar) { }
 
+#define local_trylock(lvar)					\
+	({							\
+		preempt_disable();				\
+		1;						\
+	})
+
 #define local_lock(lvar)			preempt_disable()
 #define local_unlock(lvar)			preempt_enable()
 #define local_lock_irq(lvar)			local_irq_disable()
Signature · 1 line
2.13.2
#13 lore raw

PATCH 8/9 net: use trylock in icmp_sk

In reply to Steven Rostedt

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

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

From: Sebastian Andrzej Siewior <[email protected]>

The locking path can be recursive (same as for sk->sk_lock.slock) and therefore we need a trylock version for the locallock, too.

---
 net/ipv4/icmp.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
net/ipv4/icmp.c +5 -1
index ff2593269089..2c1ce3e80ee4 100644
@@ -219,7 +219,11 @@ static inline struct sock *icmp_xmit_lock(struct net *net)
 
 	local_bh_disable();
 
-	local_lock(icmp_sk_lock);
+	if (!local_trylock(icmp_sk_lock)) {
+		local_bh_enable();
+		return NULL;
+	}
+
 	sk = icmp_sk(net);
 
 	if (unlikely(!spin_trylock(&sk->sk_lock.slock))) {
Signature · 1 line
2.13.2
#14 lore raw

PATCH 9/9 Linux 4.4.102-rt117-rc1

In reply to Steven Rostedt

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

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

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

---
 localversion-rt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
localversion-rt +1 -1
index 34eca4e89203..d5f654342ac4 100644
@@ -1 +1 @@
--rt116
+-rt117-rc1
Signature · 1 line
2.13.2