linux-kernel - Re: [tip:timers/urgent] tick: Cleanup NOHZ per cpu data on cpu down

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 21:10:51 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Prarit Bhargava <prarit@...hat.com>
cc:	mingo@...nel.org, hpa@...or.com, linux-kernel@...r.kernel.org,
	bitbucket@...ine.de,
	tip-bot for Thomas Gleixner <tipbot@...or.com>,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:timers/urgent] tick: Cleanup NOHZ per cpu data on cpu
 down

On Mon, 13 May 2013, Prarit Bhargava wrote:
> Thomas, while this does fix up the NULL pointer issue, I think you've introduced
> a new bug in the schedule timer code.

I don't think that I introduced a new bug. I'm quite sure that change
unearthed another issue which was papered over by the stale data.

That memset is putting the data structure into the same state as we
have on boot. From tick-sched perspective cpu onlining is not
different between boot and an offline/online cycle

> While doing up and downs on the same CPU, I now occasionally see long delays in
> the up and down...

> [   81.744565] smpboot: Booting Node 1 Processor 19 APIC 0x28
> [   82.848591] smpboot: CPU 19 is now offline
> 
> Long delay in bringing CPU "up"
> 
> [   89.826533] smpboot: Booting Node 1 Processor 19 APIC 0x28
> [   84.905358] smpboot: CPU 19 is now offline
> [   87.565274] smpboot: Booting Node 1 Processor 19 APIC 0x28

Errm, the timestamps are random. -ENOTUSEFUL
 
> Also, if the system is in this state I cannot reboot -- the system appears to
> hang while bringing down CPUs...
> 
> Oddly, if I do
> 
> +       memset(ts, 0, sizeof(*ts));
> +       ts->tick_stopped = 1;
> 
> instead of your memset, everything works.  I'm looking at the tick-sched.c code
> to see why setting tick_stopped = 1 seems to fix the problem.

That doesn't make any sense. So instead of changing random values in
ts, could you please fire up the tracer and gather evidence, so we can
see what the system does when these long delays happen. You can start
and stop the tracer from your script and terminate if one of the
operations takes too long.

Thanks,

	tglx






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