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: <CA+55aFwq2gash0+scfR_aefxyGfHeNT4CgNopgVMO-RA7dkiLQ@mail.gmail.com>
Date:	Sun, 16 Nov 2014 12:03:04 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Fabian Frederick <fabf@...net.be>
Cc:	Dave Jones <davej@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	"the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: frequent lockups in 3.18rc4: revert suggestion

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?

                     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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ