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]
Date:	Fri, 15 Oct 2010 01:44:08 +0200
From:	richard -rw- weinberger <richard.weinberger@...il.com>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	penberg@...helsinki.fi, LKML <linux-kernel@...r.kernel.org>,
	user-mode-linux-devel@...ts.sourceforge.net
Subject: Re: [REGRESSION] um: rcu_sched_state detected stall on CPU 0

On Thu, Oct 14, 2010 at 9:50 PM, Arjan van de Ven <arjan@...ux.intel.com> wrote:
>  On 10/14/2010 11:27 AM, richard -rw- weinberger wrote:
>>
>> Hi Arjan!
>>
>> This commit causes some problems on UML.
>>
> that is extremely weird.
>>
>> The kernel freezes after a few seconds until it gets some input.
>> e.g: When I run top it stops refreshing the process list until i press a
>> button.
>
> a slab timer change (to not be as critical) causing global timer issues....
> that's very obviously not a problem with this patch.
> has this been seem anywhere except UML ?

A small update:
It seems that CONFIG_NO_HZ is broken on UML. :-(

CONFIG_NO_HZ + CONFIG_SLAB: works
CONFIG_NO_HZ + CONFIG_SLAB + your patch: broken
CONFIG_NO_HZ + CONFIG_SLUB: broken

CONFIG_SLAB + your patch: works
CONFIG_SLAB: works
CONFIG_SLUB: works

>> Messages like this appear:
>> INFO: rcu_sched_state detected stall on CPU 0 (t=7348 jiffies)
>>
>> After reverting UML works fine again.
>>
>> commit 78b435368fcd615e695a06012cd963a556284e00
>> Author: Arjan van de Ven<arjan@...ux.intel.com>
>> Date:   Mon Jul 19 10:59:42 2010 -0700
>>
>>     slab: use deferable timers for its periodic housekeeping
>>
>>     slab has a "once every 2 second" timer for its housekeeping.
>>     As the number of logical processors is growing, its more and more
>>     common that this 2 second timer becomes the primary wakeup source.
>>
>>     This patch turns this housekeeping timer into a deferable timer,
>>     which means that the timer does not interrupt idle, but just runs
>>     at the next event that wakes the cpu up.
>>
>>     The impact is that the timer likely runs a bit later, but during the
>>     delay no code is running so there's not all that much reason for
>>     a difference in housekeeping to occur because of this delay.
>>
>>     Signed-off-by: Arjan van de Ven<arjan@...ux.intel.com>
>>     Signed-off-by: Pekka Enberg<penberg@...helsinki.fi>
>>
>> diff --git a/mm/slab.c b/mm/slab.c
>> index e49f8f4..29aad44 100644
>> --- a/mm/slab.c
>> +++ b/mm/slab.c
>> @@ -861,7 +861,7 @@ static void __cpuinit start_cpu_timer(int cpu)
>>          */
>>         if (keventd_up()&&  reap_work->work.func == NULL) {
>>                 init_reap_node(cpu);
>> -               INIT_DELAYED_WORK(reap_work, cache_reap);
>> +               INIT_DELAYED_WORK_DEFERRABLE(reap_work, cache_reap);
>>                 schedule_delayed_work_on(cpu, reap_work,
>>                                         __round_jiffies_relative(HZ,
>> cpu));
>>         }
>>
>>
>
>



-- 
Thanks,
//richard
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ