| 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
| ||
|
Date: Fri, 10 Feb 2012 11:12:53 -0500 From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> To: Steven Noonan <steven@...inklabs.net>, a.p.zijlstra@...llo.nl Cc: linux-kernel@...r.kernel.org, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>, Arnaldo Carvalho de Melo <acme@...stprotocols.net>, Jeremy Fitzhardinge <jeremy@...p.org> Subject: Re: bisected: 'perf top' causing soft lockups under Xen On Thu, Feb 09, 2012 at 06:32:07PM -0800, Steven Noonan wrote: > This lockup is pretty reliably reproducible (but only under Xen). I've > seen this happen under multiple hardware configurations and multiple > different configs. Hm, during bootup what does perf say about the CPU availability? Is it that it can only do perf via NMI's? .. snip.. > I did a bit of manual bisection (based on tags) and noticed the issue > was introduced sometime between v3.0 and v3.1-rc1. This is where the Whoa, 3.1? Yikes! > bisection took me: > > # bad: [322a8b034003c0d46d39af85bf24fee27b902f48] Linux 3.1-rc1 > # good: [02f8c6aee8df3cdc935e9bdd4f2d020306035dbe] Linux 3.0 > git bisect start 'v3.1-rc1' 'v3.0' > # bad: [0003230e8200699860f0b10af524dc47bf8aecad] Merge branch > 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6 > git bisect bad 0003230e8200699860f0b10af524dc47bf8aecad > # good: [72f96e0e38d7e29ba16dcfd824ecaebe38b8293e] Merge branch > 'for-linus-core' of > git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending > git bisect good 72f96e0e38d7e29ba16dcfd824ecaebe38b8293e > # bad: [f5fc87905ea075a0b14878086fd4fe38be128844] Merge branch > 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap > git bisect bad f5fc87905ea075a0b14878086fd4fe38be128844 > # bad: [f5fc87905ea075a0b14878086fd4fe38be128844] Merge branch > 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap > git bisect bad f5fc87905ea075a0b14878086fd4fe38be128844 > # bad: [bbd9d6f7fbb0305c9a592bf05a32e87eb364a4ff] Merge branch > 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6 > git bisect bad bbd9d6f7fbb0305c9a592bf05a32e87eb364a4ff > # bad: [4d4abdcb1dee03a4f9d6d2021622ed07e14dfd17] Merge branch > 'perf-core-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip > git bisect bad 4d4abdcb1dee03a4f9d6d2021622ed07e14dfd17 > # bad: [190b57fcb9c5fed5414935a174094f534fc510bc] perf probe: Add > probed module in front of function > git bisect bad 190b57fcb9c5fed5414935a174094f534fc510bc > # bad: [26ca5c11fb45ae2b2ac7e3574b8db6b3a3c7d350] perf: export > perf_event_refresh() to modules > git bisect bad 26ca5c11fb45ae2b2ac7e3574b8db6b3a3c7d350 > # bad: [26ca5c11fb45ae2b2ac7e3574b8db6b3a3c7d350] perf: export > perf_event_refresh() to modules > git bisect bad 26ca5c11fb45ae2b2ac7e3574b8db6b3a3c7d350 > # good: [b0af8dfdd67699e25083478c63eedef2e72ebd85] Linux 3.0-rc5 > git bisect good b0af8dfdd67699e25083478c63eedef2e72ebd85 > # good: [b0af8dfdd67699e25083478c63eedef2e72ebd85] Linux 3.0-rc5 > git bisect good b0af8dfdd67699e25083478c63eedef2e72ebd85 > # good: [af07ce3e77d3b24ab1d71fcc5833d41800f23b2b] Merge branch > 'tip/perf/core-2' of > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace > into perf/core > git bisect good af07ce3e77d3b24ab1d71fcc5833d41800f23b2b > # good: [af07ce3e77d3b24ab1d71fcc5833d41800f23b2b] Merge branch > 'tip/perf/core-2' of > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace > into perf/core > git bisect good af07ce3e77d3b24ab1d71fcc5833d41800f23b2b > # good: [1880c4ae182afb5650c5678949ecfe7ff66a724e] perf, x86: Add > hw_watchdog_set_attr() in a sake of nmi-watchdog on P4 > git bisect good 1880c4ae182afb5650c5678949ecfe7ff66a724e > # bad: [ee89cbc2d48150c7c0e9f2aaac00afde99af098c] perf_events: Add > Intel Sandy Bridge offcore_response low-level support > git bisect bad ee89cbc2d48150c7c0e9f2aaac00afde99af098c > # bad: [a7ac67ea021b4603095d2aa458bc41641238f22c] perf: Remove the > perf_output_begin(.sample) argument > git bisect bad a7ac67ea021b4603095d2aa458bc41641238f22c > # bad: [a8b0ca17b80e92faab46ee7179ba9e99ccb61233] perf: Remove the nmi > parameter from the swevent and overflow interface > git bisect bad a8b0ca17b80e92faab46ee7179ba9e99ccb61233 > > > So, it looks like somehow this broke things: Hm, Peter any thoughts? Is there a need to introduce some new code to utilize this? > > commit a8b0ca17b80e92faab46ee7179ba9e99ccb61233 > Author: Peter Zijlstra <a.p.zijlstra@...llo.nl> > Date: Mon Jun 27 14:41:57 2011 +0200 > > perf: Remove the nmi parameter from the swevent and overflow interface > > The nmi parameter indicated if we could do wakeups from the current > context, if not, we would set some state and self-IPI and let the > resulting interrupt do the wakeup. > > For the various event classes: > > - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from > the PMI-tail (ARM etc.) > - tracepoint: nmi=0; since tracepoint could be from NMI context. > - software: nmi=[0,1]; some, like the schedule thing cannot > perform wakeups, and hence need 0. > > As one can see, there is very little nmi=1 usage, and the down-side of > not using it is that on some platforms some software events can have a > jiffy delay in wakeup (when arch_irq_work_raise isn't implemented). > > The up-side however is that we can remove the nmi parameter and save a > bunch of conditionals in fast paths. > > Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl> > Cc: Michael Cree <mcree@...on.net.nz> > Cc: Will Deacon <will.deacon@....com> > Cc: Deng-Cheng Zhu <dengcheng.zhu@...il.com> > Cc: Anton Blanchard <anton@...ba.org> > Cc: Eric B Munson <emunson@...bm.net> > Cc: Heiko Carstens <heiko.carstens@...ibm.com> > Cc: Paul Mundt <lethal@...ux-sh.org> > Cc: David S. Miller <davem@...emloft.net> > Cc: Frederic Weisbecker <fweisbec@...il.com> > Cc: Jason Wessel <jason.wessel@...driver.com> > Cc: Don Zickus <dzickus@...hat.com> > Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.org > Signed-off-by: Ingo Molnar <mingo@...e.hu> > > > Relevant maintainers CC'd. Any ideas, folks? > -- > 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/ -- 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