linux-kernel - Re: [ANNOUNCE] 3.0.14-rt31

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201201131042.08323.tim.sander@hbm.com>
Date:	Fri, 13 Jan 2012 10:42:08 +0100
From:	Tim Sander <tim.sander@....com>
To:	"Steven Rostedt" <rostedt@...dmis.org>
Cc:	"LKML" <linux-kernel@...r.kernel.org>,
	"RT" <linux-rt-users@...r.kernel.org>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Clark Williams" <williams@...hat.com>,
	"John Kacur" <jkacur@...hat.com>
Subject: Re: [ANNOUNCE] 3.0.14-rt31

Hi 

I was thinking about this ksoftirq0 running on max cpu. The context:
> > > and the running wild ksoftirqd0 most probably after the kernel message:
> > > "sched: RT throttling activated"
> > 
> > Hmm, that's not good. It means that an RT task is spinning too much.
> 
> Mh, sorry i was to terse on that. This only happens after first boot on
> UBIFS update, but it shows that somehow there seems to be a corner case
> when throtteling is activated. Since this seems to be the reason for
> ksoftirq0 running as much cpu as it gets. I just patched out switch to rt
> throtteling and i will ask the mtd guys about the work they presumably do
> in interrupt context which causes this throtteling in the first place.
I just patched out the toggle of the rt-throttle. When this throttle is disabled then
the system hangs on boot but can be rebooted with a sysrq-b. So it might be
cought with rt overload? This hang which does not occur after every update now triggers
the throttle (when not patched out). Then the system runs along with the realtime
throttle activated and now we are going to switch the clocksource with our driver to a
cyclic clock (to fight irq latency). So there might be an error sleeping there in this 
codepath which seems unlikely enought that nearly no one else sees this error?

Best regards
Tim

The patch to remove toggle to realtime (only for reference)
diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
index 53525cb..e5f4290 100644
--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -642,8 +642,8 @@ static int sched_rt_runtime_exceeded(struct rt_rq *rt_rq)
                 * but accrue some time due to boosting.
                 */
                if (likely(rt_b->rt_runtime)) {
-                       rt_rq->rt_throttled = 1;
-                       printk_once(KERN_WARNING "sched: RT throttling activated\n");
+                       //rt_rq->rt_throttled = 1;
+                       printk_once(KERN_WARNING "sched: RT throttling would have been activated, but has been disabled.");
                } else {
                        /*
                         * In case we did anyway, make it go away,



Please ignore:

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/