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:	Mon, 13 May 2013 22:01:12 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Borislav Petkov <bp@...en8.de>,
	Tony Luck <tony.luck@...el.com>, linux-kernel@...r.kernel.org,
	x86@...nel.org
Subject: Re: NOHZ: WARNING: at arch/x86/kernel/smp.c:123
 native_smp_send_reschedule

On Mon, 13 May 2013, Thomas Gleixner wrote:

> > > --- a/kernel/time/tick-sched.c
> > > +++ b/kernel/time/tick-sched.c
> > > @@ -650,6 +650,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
> > >  
> > >  			ts->last_tick = hrtimer_get_expires(&ts->sched_timer);
> > >  			ts->tick_stopped = 1;
> > > +			WARN_ON_ONCE(!cpu_online(cpu));
> 
> So that warning triggers.
> 
> >  WARNING: at kernel/time/tick-sched.c:653 tick_nohz_stop_sched_tick+0x38e/0x3a0()
> 
> The pre full dyntick idle code bailed out when a cpu was offline. The
> new fangled can_stop_idle_tick() function dropped that.
> 
> Does the patch below fix the issue?
> 
> Thanks,
> 
> 	tglx
> 
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index bc67d42..00a9a97 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -717,6 +717,7 @@ static bool can_stop_idle_tick(int cpu, struct tick_sched *ts)
>  	if (unlikely(!cpu_online(cpu))) {
>  		if (cpu == tick_do_timer_cpu)
>  			tick_do_timer_cpu = TICK_DO_TIMER_NONE;
> +		return false;
>  	}
>  
>  	if (unlikely(ts->nohz_mode == NOHZ_MODE_INACTIVE))

The warning is gone, so it definitely looks like you found a culprit, 
Thomas, thanks.

But I am not going to provide my Tested-by: yet, as one of the four 
suspend-resume cycles I have done during testing of this patch ended up 
with segfaults when trying to start any userspace binary after resume 
(i.e. clear memory corruption). The remaining three suspend-resume 
cycles were fine.

Will be looking into this a little bit more.

-- 
Jiri Kosina
SUSE Labs
--
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