SLAB leaks filep in 3.4.13-rt21 with PREEMPT_RT_FULL

SLAB leaks filep in 3.4.13-rt21 with PREEMPT_RT_FULL

[Stanislav Meduna]

Hi,

compiling a current (a few days back) linux-stable-rt.git
with PREEMPT_RT_FULL results in a significant memory leak.
Just repeating

  cat /proc/meminfo  | grep Unreclaim

shows the unreclaimable memory jumping in 4 - 12 kB steps.
  sync ; echo 3 > /proc/sys/vm/drop_caches
does not help either, this is for sure a real leak.

Looking at the slabtop output the "filp" is responsible for
most of the allocations, but there are more, even the "pid"
is rising although the number of threads in the system stays
the same.

PREEMPT_LL and selecting the SLUB (which is the preferred
allocator but not available with PREEMPT_RT_FULL) solves the
problem. I did not test with LL and SLAB (yet - I think that
it is hardly improbable that the SLAB allocator is the reason).

I can't test with PREEMPT_RTB as this option looks even more
broken on my setup and oopses at root filesystem (ext3)
mounting so I do not have the logs and the beginning rolls
out of the console so I can't even photograph it :(

The machine is an industrial embedded PC running a Geode LX.
I did not change the kernel in any way except adding an own
module that was not loaded during the tests.

I am new to linux-rt and this list - is it OK to attach
full .config files?

Thanks
-- 
                               Stano

Re: SLAB leaks filep in 3.4.13-rt21 with PREEMPT_RT_FULL

[Thomas Gleixner]

On Sat, 20 Oct 2012, Stanislav Meduna wrote:
> Looking at the slabtop output the "filp" is responsible for
> most of the allocations, but there are more, even the "pid"
> is rising although the number of threads in the system stays
> the same.

It's a UP problem in tiny RCU. Fix is below.

Thanks,

	tglx

-------------------------->
Subject: rcu: rcutiny: Prevent RCU stall
From: Thomas Gleixner <tglx@linutronix.de>
Date: Tue, 16 Oct 2012 18:36:51 +0200

rcu_read_unlock_special() checks in_serving_softirq() and leaves early
when true. On RT this is obviously wrong as softirq processing context
can be preempted and therefor such a task can be on the gp_tasks
list. Leaving early here will leave the task on the list and therefor
block RCU processing forever.

This cannot happen on mainline because softirq processing context
cannot be preempted and therefor this can never happen at all.

In fact this check looks quite questionable in general. Neither irq
context nor softirq processing context in mainline can ever be
preempted in mainline so the special unlock case should not ever be
invoked in such context. Now the only explanation might be a
rcu_read_unlock() being interrupted and therefor leave the rcu nest
count at 0 before the special unlock bit has been cleared. That looks
fragile. At least it's missing a big fat comment. Paul ????

See mainline commits: ec433f0c5 and 8762705a for further enlightment.

Reported-by: Kristian Lehmann <krleit00@hs-esslingen.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable-rt@vger.kernel.org

---
 kernel/rcutiny_plugin.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-stable/kernel/rcutiny_plugin.h
===================================================================
--- linux-stable.orig/kernel/rcutiny_plugin.h
+++ linux-stable/kernel/rcutiny_plugin.h
@@ -560,7 +560,7 @@ void rcu_read_unlock_special(struct task
 		rcu_preempt_cpu_qs();
 
 	/* Hardware IRQ handlers cannot block. */
-	if (in_irq() || in_serving_softirq()) {
+	if (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_OFFSET)) {
 		local_irq_restore(flags);
 		return;
 	}

Re: SLAB leaks filep in 3.4.13-rt21 with PREEMPT_RT_FULL

[Stanislav Meduna]

On 20.10.2012 21:30, Thomas Gleixner wrote:

>> Looking at the slabtop output the "filp" is responsible for
>> most of the allocations, but there are more, even the "pid"
>> is rising although the number of threads in the system stays
>> the same.
> 
> It's a UP problem in tiny RCU. Fix is below.

Many thanks, the fix helped.

Best regards
-- 
                                       Stano