[PATCH RT 0/4] [ANNOUNCE] 3.0.75-rt103-rc1

[PATCH RT 0/4] [ANNOUNCE] 3.0.75-rt103-rc1

[Steven Rostedt]

Dear RT Folks,

This is the RT stable review cycle of patch 3.0.75-rt103-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 5/7/2013.

Enjoy,

-- Steve


To build 3.0.75-rt103-rc1 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.75.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.75-rt103-rc1.patch.xz

You can also build from 3.0.75-rt102 by applying the incremental patch:

http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/incr/patch-3.0.75-rt102-rt103-rc1.patch.xz


Changes from 3.0.75-rt102:

---


Eric Dumazet (1):
      tcp: force a dst refcount when prequeue packet

Steven Rostedt (2):
      x86/mce: Defer mce wakeups to threads for PREEMPT_RT
      swap: Use unique local lock name for swap_lock

Steven Rostedt (Red Hat) (1):
      Linux 3.0.75-rt103-rc1

----
 arch/x86/kernel/cpu/mcheck/mce.c |   76 ++++++++++++++++++++++++++++++--------
 include/net/tcp.h                |    1 +
 localversion-rt                  |    2 +-
 mm/swap.c                        |   20 +++++-----
 4 files changed, 72 insertions(+), 27 deletions(-)

[PATCH RT 1/4] tcp: force a dst refcount when prequeue packet

[Steven Rostedt]

[-- Attachment #1: 0001-tcp-force-a-dst-refcount-when-prequeue-packet.patch --]
[-- Type: text/plain, Size: 901 bytes --]

From: Eric Dumazet <edumazet@google.com>

Before escaping RCU protected section and adding packet into
prequeue, make sure the dst is refcounted.

Cc: stable-rt@vger.kernel.org
Reported-by: Mike Galbraith <bitbucket@online.de>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 include/net/tcp.h |    1 +
 1 file changed, 1 insertion(+)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index b28a49f..4881cb6 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -902,6 +902,7 @@ static inline int tcp_prequeue(struct sock *sk, struct sk_buff *skb)
 	if (sysctl_tcp_low_latency || !tp->ucopy.task)
 		return 0;
 
+	skb_dst_force(skb);
 	__skb_queue_tail(&tp->ucopy.prequeue, skb);
 	tp->ucopy.memory += skb->truesize;
 	if (tp->ucopy.memory > sk->sk_rcvbuf) {
-- 
1.7.10.4

[PATCH RT 2/4] x86/mce: Defer mce wakeups to threads for PREEMPT_RT

[Steven Rostedt]

[-- Attachment #1: 0002-x86-mce-Defer-mce-wakeups-to-threads-for-PREEMPT_RT.patch --]
[-- Type: text/plain, Size: 5372 bytes --]

From: Steven Rostedt <rostedt@goodmis.org>

We had a customer report a lockup on a 3.0-rt kernel that had the
following backtrace:

[ffff88107fca3e80] rt_spin_lock_slowlock at ffffffff81499113
[ffff88107fca3f40] rt_spin_lock at ffffffff81499a56
[ffff88107fca3f50] __wake_up at ffffffff81043379
[ffff88107fca3f80] mce_notify_irq at ffffffff81017328
[ffff88107fca3f90] intel_threshold_interrupt at ffffffff81019508
[ffff88107fca3fa0] smp_threshold_interrupt at ffffffff81019fc1
[ffff88107fca3fb0] threshold_interrupt at ffffffff814a1853

It actually bugged because the lock was taken by the same owner that
already had that lock. What happened was the thread that was setting
itself on a wait queue had the lock when an MCE triggered. The MCE
interrupt does a wake up on its wait list and grabs the same lock.

NOTE: THIS IS NOT A BUG ON MAINLINE

Sorry for yelling, but as I Cc'd mainline maintainers I want them to
know that this is an PREEMPT_RT bug only. I only Cc'd them for advice.

On PREEMPT_RT the wait queue locks are converted from normal
"spin_locks" into an rt_mutex (see the rt_spin_lock_slowlock above).
These are not to be taken by hard interrupt context. This usually isn't
a problem as most all interrupts in PREEMPT_RT are converted into
schedulable threads. Unfortunately that's not the case with the MCE irq.

As wait queue locks are notorious for long hold times, we can not
convert them to raw_spin_locks without causing issues with -rt. But
Thomas has created a "simple-wait" structure that uses raw spin locks
which may have been a good fit.

Unfortunately, wait queues are not the only issue, as the mce_notify_irq
also does a schedule_work(), which grabs the workqueue spin locks that
have the exact same issue.

Thus, this patch I'm proposing is to move the actual work of the MCE
interrupt into a helper thread that gets woken up on the MCE interrupt
and does the work in a schedulable context.

NOTE: THIS PATCH ONLY CHANGES THE BEHAVIOR WHEN PREEMPT_RT IS SET

Oops, sorry for yelling again, but I want to stress that I keep the same
behavior of mainline when PREEMPT_RT is not set. Thus, this only changes
the MCE behavior when PREEMPT_RT is configured.

Cc: stable-rt@vger.kernel.org
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
[bigeasy@linutronix: make mce_notify_work() a proper prototype, use
		     kthread_run()]
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 arch/x86/kernel/cpu/mcheck/mce.c |   76 ++++++++++++++++++++++++++++++--------
 1 file changed, 60 insertions(+), 16 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 3d38e73..c859bb4 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -16,6 +16,7 @@
 #include <linux/rcupdate.h>
 #include <linux/kobject.h>
 #include <linux/uaccess.h>
+#include <linux/kthread.h>
 #include <linux/kdebug.h>
 #include <linux/kernel.h>
 #include <linux/percpu.h>
@@ -1181,6 +1182,62 @@ static void mce_do_trigger(struct work_struct *work)
 
 static DECLARE_WORK(mce_trigger_work, mce_do_trigger);
 
+static void __mce_notify_work(void)
+{
+	/* Not more than two messages every minute */
+	static DEFINE_RATELIMIT_STATE(ratelimit, 60*HZ, 2);
+
+	wake_up_interruptible(&mce_wait);
+
+	/*
+	 * There is no risk of missing notifications because
+	 * work_pending is always cleared before the function is
+	 * executed.
+	 */
+	if (mce_helper[0] && !work_pending(&mce_trigger_work))
+		schedule_work(&mce_trigger_work);
+
+	if (__ratelimit(&ratelimit))
+		pr_info(HW_ERR "Machine check events logged\n");
+}
+
+#ifdef CONFIG_PREEMPT_RT_FULL
+struct task_struct *mce_notify_helper;
+
+static int mce_notify_helper_thread(void *unused)
+{
+	while (1) {
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule();
+		if (kthread_should_stop())
+			break;
+		__mce_notify_work();
+	}
+	return 0;
+}
+
+static int mce_notify_work_init(void)
+{
+	mce_notify_helper = kthread_run(mce_notify_helper_thread, NULL,
+					   "mce-notify");
+	if (!mce_notify_helper)
+		return -ENOMEM;
+
+	return 0;
+}
+
+static void mce_notify_work(void)
+{
+	wake_up_process(mce_notify_helper);
+}
+#else
+static void mce_notify_work(void)
+{
+	__mce_notify_work();
+}
+static inline int mce_notify_work_init(void) { return 0; }
+#endif
+
 /*
  * Notify the user(s) about new machine check events.
  * Can be called from interrupt context, but not from machine check/NMI
@@ -1188,25 +1245,10 @@ static DECLARE_WORK(mce_trigger_work, mce_do_trigger);
  */
 int mce_notify_irq(void)
 {
-	/* Not more than two messages every minute */
-	static DEFINE_RATELIMIT_STATE(ratelimit, 60*HZ, 2);
-
 	clear_thread_flag(TIF_MCE_NOTIFY);
 
 	if (test_and_clear_bit(0, &mce_need_notify)) {
-		wake_up_interruptible(&mce_wait);
-
-		/*
-		 * There is no risk of missing notifications because
-		 * work_pending is always cleared before the function is
-		 * executed.
-		 */
-		if (mce_helper[0] && !work_pending(&mce_trigger_work))
-			schedule_work(&mce_trigger_work);
-
-		if (__ratelimit(&ratelimit))
-			pr_info(HW_ERR "Machine check events logged\n");
-
+		mce_notify_work();
 		return 1;
 	}
 	return 0;
@@ -2136,6 +2178,8 @@ static __init int mcheck_init_device(void)
 	register_hotcpu_notifier(&mce_cpu_notifier);
 	misc_register(&mce_log_device);
 
+	err = mce_notify_work_init();
+
 	return err;
 }
 
-- 
1.7.10.4

[PATCH RT 3/4] swap: Use unique local lock name for swap_lock

[Steven Rostedt]

[-- Attachment #1: 0003-swap-Use-unique-local-lock-name-for-swap_lock.patch --]
[-- Type: text/plain, Size: 3521 bytes --]

From: Steven Rostedt <rostedt@goodmis.org>

>From lib/Kconfig.debug on CONFIG_FORCE_WEAK_PER_CPU:

----
s390 and alpha require percpu variables in modules to be
defined weak to work around addressing range issue which
puts the following two restrictions on percpu variable
definitions.

1. percpu symbols must be unique whether static or not
2. percpu variables can't be defined inside a function

To ensure that generic code follows the above rules, this
option forces all percpu variables to be defined as weak.
----

The addition of the local IRQ swap_lock in mm/swap.c broke this config
as the name "swap_lock" is used through out the kernel. Just do a "git
grep swap_lock" to see, and the new swap_lock is a local lock which
defines the swap_lock for per_cpu.

The fix was to rename swap_lock to swapvec_lock which keeps it unique.

Reported-by: Mike Galbraith <bitbucket@online.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 mm/swap.c |   20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/mm/swap.c b/mm/swap.c
index 662972f..ccf04d2 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -43,7 +43,7 @@ static DEFINE_PER_CPU(struct pagevec, lru_rotate_pvecs);
 static DEFINE_PER_CPU(struct pagevec, lru_deactivate_pvecs);
 
 static DEFINE_LOCAL_IRQ_LOCK(rotate_lock);
-static DEFINE_LOCAL_IRQ_LOCK(swap_lock);
+static DEFINE_LOCAL_IRQ_LOCK(swapvec_lock);
 
 /*
  * This path almost never happens for VM activity - pages are normally
@@ -331,13 +331,13 @@ static void activate_page_drain(int cpu)
 void activate_page(struct page *page)
 {
 	if (PageLRU(page) && !PageActive(page) && !PageUnevictable(page)) {
-		struct pagevec *pvec = &get_locked_var(swap_lock,
+		struct pagevec *pvec = &get_locked_var(swapvec_lock,
 						       activate_page_pvecs);
 
 		page_cache_get(page);
 		if (!pagevec_add(pvec, page))
 			pagevec_lru_move_fn(pvec, __activate_page, NULL);
-		put_locked_var(swap_lock, activate_page_pvecs);
+		put_locked_var(swapvec_lock, activate_page_pvecs);
 	}
 }
 
@@ -378,12 +378,12 @@ EXPORT_SYMBOL(mark_page_accessed);
 
 void __lru_cache_add(struct page *page, enum lru_list lru)
 {
-	struct pagevec *pvec = &get_locked_var(swap_lock, lru_add_pvecs)[lru];
+	struct pagevec *pvec = &get_locked_var(swapvec_lock, lru_add_pvecs)[lru];
 
 	page_cache_get(page);
 	if (!pagevec_add(pvec, page))
 		____pagevec_lru_add(pvec, lru);
-	put_locked_var(swap_lock, lru_add_pvecs);
+	put_locked_var(swapvec_lock, lru_add_pvecs);
 }
 EXPORT_SYMBOL(__lru_cache_add);
 
@@ -547,19 +547,19 @@ void deactivate_page(struct page *page)
 		return;
 
 	if (likely(get_page_unless_zero(page))) {
-		struct pagevec *pvec = &get_locked_var(swap_lock,
+		struct pagevec *pvec = &get_locked_var(swapvec_lock,
 						       lru_deactivate_pvecs);
 
 		if (!pagevec_add(pvec, page))
 			pagevec_lru_move_fn(pvec, lru_deactivate_fn, NULL);
-		put_locked_var(swap_lock, lru_deactivate_pvecs);
+		put_locked_var(swapvec_lock, lru_deactivate_pvecs);
 	}
 }
 
 void lru_add_drain(void)
 {
-	drain_cpu_pagevecs(local_lock_cpu(swap_lock));
-	local_unlock_cpu(swap_lock);
+	drain_cpu_pagevecs(local_lock_cpu(swapvec_lock));
+	local_unlock_cpu(swapvec_lock);
 }
 
 static void lru_add_drain_per_cpu(struct work_struct *dummy)
@@ -776,7 +776,7 @@ EXPORT_SYMBOL(pagevec_lookup);
 static int __init swap_init_locks(void)
 {
 	local_irq_lock_init(rotate_lock);
-	local_irq_lock_init(swap_lock);
+	local_irq_lock_init(swapvec_lock);
 	return 1;
 }
 early_initcall(swap_init_locks);
-- 
1.7.10.4

[PATCH RT 4/4] Linux 3.0.75-rt103-rc1

[Steven Rostedt]

[-- Attachment #1: 0004-Linux-3.0.75-rt103-rc1.patch --]
[-- Type: text/plain, Size: 301 bytes --]

From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>

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

diff --git a/localversion-rt b/localversion-rt
index 33017cd..b809d7b 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt102
+-rt103-rc1
-- 
1.7.10.4

Unsubscribing

[Damien Moody]

I'm sorry to post this, but things have been a little crazy lately and I
don't know where I kept the relevant info. How do I unsubscribe?

Re: Unsubscribing

[Mark Knecht]

On Sat, May 4, 2013 at 12:57 PM, Damien Moody <mailinglists@audiodef.com> wrote:
> I'm sorry to post this, but things have been a little crazy lately and I
> don't know where I kept the relevant info. How do I unsubscribe?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Possibly read the footer added to the email you sent? :-)

unsubscribing

[Aman Agarwal]

unsubscribe git agaraman0@gmail.com

Re: unsubscribing

[Philip Oakley]

Hi the unsubscribe should go to the majordomo, see
http://vger.kernel.org/vger-lists.html#git

The Git list can always be reviewed at https://lore.kernel.org/git/

On 14/03/2023 06:52, Aman Agarwal wrote:
> unsubscribe git agaraman0@gmail.com
 --
Philip

unsubscribing

[Michał Zegan]

Hello. I wanted to unsubscribe from this list, sent a line "subscribe
linux-kernel" to majordomo@vger.kernel.org, but it does not reply at
all. what is/may be the problem?
I wanted to switch to more specific lists to track things I am
specifically interested in

Unsubscribing

[S S Dhawale]

[-- Attachment #1: Type: text/plain, Size: 148 bytes --]

remove this email id from your list.
-- 
Regards
Mr S S Dhawale
Assistant Professor,
CSE Department,
SSPM's COE,
Kankavli, Sindhudurg,
Maharashtra.

[-- Attachment #2: Type: text/html, Size: 263 bytes --]

Re: Unsubscribing

[Patrick K., ITF]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

Mr S S Dhawale,

You can unsubscribe from selinux mailing list by sending email to
selinux-leave@tycho.nsa.gov.  You can unsubscribe from seandroid-list
mailing list by sending email toseandroid-list-leave@tycho.nsa.gov.

-- 

  Patrick

On 6/29/2015 4:39 AM, S S Dhawale wrote:
> remove this email id from your list.
> -- 
> Regards
> Mr S S Dhawale
> Assistant Professor,
> CSE Department,
> SSPM's COE,
> Kankavli, Sindhudurg,
> Maharashtra.
>
>
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.


[-- Attachment #2: Type: text/html, Size: 1834 bytes --]

Unsubscribing.

[Pete Barnard]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

I am getting swamped by e-mail messages from the daily alsa-devel.  Whilst this group has helped me in the past with alsa development I would like to either "unsubscribe" from the list or stop the e-mail messages.  I tried unsubscribing a couple of months ago by following the unsubscribe instructions but am still getting swamped by the daily messages. 
Regards,

Pete



[-- Attachment #2: Type: text/html, Size: 975 bytes --]

unsubscribing

[Pete Barnard]

[-- Attachment #1: Type: text/plain, Size: 165 bytes --]

Does anybody know how I go about either unsubscribing to alsa-devel or making it so that every single message isn't e-mailed directly to me?   

Regards,

Pete

[-- Attachment #2: Type: text/html, Size: 667 bytes --]

Unsubscribing.

[Mikael Backman]

[OT]
How do I unsubscribe to this mailing list?

/Mikael


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Unsubscribing.

[Joerg Mayer]

On Wed, May 29, 2002 at 04:06:45AM +0200, Mikael Backman wrote:
> How do I unsubscribe to this mailing list?

Have you ever noted, that each and every mail sent via this list
has a footer? Have you tried following the URL given there? Also,
you may try to have a look at the *complete* header of your mail,
it also contains the information you  are looking for.

> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

 ciao
      Jörg

--
Joerg Mayer                                          <jmayer@loplof.de>
I found out that "pro" means "instead of" (as in proconsul). Now I know
what proactive means.


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm