linux-kernel - Re: [REGRESSION] um: rcu_sched

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:	Thu, 14 Oct 2010 12:50:29 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	richard -rw- weinberger <richard.weinberger@...il.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 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 ?

> 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));
>          }
>
>

--
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/