linux-kernel - Re: frequent lockups in 3.18rc4: revert suggestion

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]

Message-ID: <2103975015.146682.1416170523484.open-xchange@webmail.nmp.skynet.be>
Date:	Sun, 16 Nov 2014 21:42:03 +0100 (CET)
From:	Fabian Frederick <fabf@...net.be>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Dave Jones <davej@...hat.com>, Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	the arch/x86 maintainers <x86@...nel.org>
Subject: Re: frequent lockups in 3.18rc4: revert suggestion



> On 16 November 2014 at 21:03 Linus Torvalds <torvalds@...ux-foundation.org>
> wrote:
>
>
> On Sun, Nov 16, 2014 at 12:33 AM, Fabian Frederick <fabf@...net.be> wrote:
> >
> >         Have you tried reverting the following patches (all from rc1) ?
>
> Hmm. Any particular reason you're looking at those?
>
> >         c6f4459 v3.18-rc1 smp: Add new wake_up_all_idle_cpus() function
> >         bb964a9 v3.18-rc1 kernel misc: Replace __get_cpu_var uses
> >         2ed903c v3.18-rc1 cpuidle: Use wake_up_all_idle_cpus() to wake up
> >all idle cpus
>
> It does strike me that the reschedule IPI is somewhat special in that
> we don't try to serialize it at all, on the grounds that a lost IPI is
> ok (ie smp_send_reschedule() is very much a special case of IPI). Or
> am I mis-remembering? Does that series end up adding a lot more of
> those things, rather than using the normal smp_call_function().
>
> The normal smp_function_mask() thing tries to make sure only one entry
> is ever active at a time (even a non-blocking one will use the whole
> "queue it on a llist, only send the IPI if the llist was empty", so
> this is not about the IPI's being synchronous).  The rescheduling
> thing is rather special, isn't it.
>
> The softlockup thing *did* look like some IPI got lost. Could an IPI
> overflow on the RESCHEDULE_VECTOR end up affecting other vectors? It's
> been too long since I worked with the APIC (and by "too long", I
> obviously mean "thank God I haven't had to" ;^) but there used to be
> grouping of the vectors..
>
> Maybe that is all barking up the wrong tree, but I'm wondering why
> Fabian picked that particular set of commits. Fabian?

Thomas talked about csd_lock and the last reliable stack function
being smp_call_function_single, I thought it could be interesting
to bisect directly in smp.c as I only read about reverting mm/memory.c
stuff ... Maybe not too much original but who knows ? :)
 
Regards,
Fabian

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