Linux 4.4.102-rt117-rc1
Subsystems (5)
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(-)
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
@@ -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
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
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
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
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
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
PATCH 2/9 cpu_pm: replace raw_notifier to atomic_notifier
In reply to Steven Rostedt4.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, rwlockcpu_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.
--- kernel/cpu_pm.c | 43 ++++++------------------------------------- 1 file changed, 6 insertions(+), 37 deletions(-)
kernel/cpu_pm.c +6 -37
@@ -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
PATCH 3/9 kernel/hrtimer: migrate deferred timer on CPU down
In reply to Steven Rostedt4.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
@@ -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
PATCH 4/9 kernel/hrtimer: dont wakeup a process while holding the hrtimer base lock
In reply to Steven Rostedt4.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
@@ -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
PATCH 5/9 kernel/hrtimer/hotplug: dont wake ktimersoftd while holding the hrtimer base lock
In reply to Steven Rostedt4.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
@@ -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
PATCH 6/9 Bluetooth: avoid recursive locking in hci_send_to_channel()
In reply to Steven Rostedt4.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.
--- net/bluetooth/hci_sock.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)
net/bluetooth/hci_sock.c +11 -6
@@ -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
PATCH 7/9 rt/locking: allow recursive local_trylock()
In reply to Steven Rostedt4.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
@@ -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
PATCH 8/9 net: use trylock in icmp_sk
In reply to Steven Rostedt4.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
@@ -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
PATCH 9/9 Linux 4.4.102-rt117-rc1
In reply to Steven Rostedt4.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
@@ -1 +1 @@ --rt116 +-rt117-rc1
Signature · 1 line
2.13.2