linux-kernel - Re: bisected: 'perf top' causing soft lockups under Xen

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: <20120320152354.GB29135@phenom.dumpdata.com>
Date:	Tue, 20 Mar 2012 11:23:54 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Steven Noonan <steven@...inklabs.net>, Ben Guthro <ben@...hro.net>,
	linux-kernel@...r.kernel.org, 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 Wed, Feb 15, 2012 at 11:17:41AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 15, 2012 at 10:25:44AM +0100, Peter Zijlstra wrote:
> > On Wed, 2012-02-15 at 00:57 -0800, Steven Noonan wrote:
> > > It seems to me that there are two options for fixing this, but I'm
> > > probably lacking the necessary context (or experience with Xen). Either:
> > > 
> > > - The patch provided by Ben needs to have additional work to specially
> > >   handle IRQ_WORK_VECTOR, since it seems to be a special case where
> > >   there's no event channel attached for it. Perhaps adding an event
> > >   channel for this is the fix? Seems high-overhead, but I lack a good
> > >   understanding of how interrupts are handled in Xen.
> > 
> > So that's a self-IPI, is Xen failing to implement this?
> 
> It does have self-IPIs.
> > 
> > > or
> > > 
> > > - Perf needs to be "enlightened" about Xen and avoid sending an IPI in
> > >   the first place.
> > 
> > Uhm, no. If anything Xen should simply not implement
> > arch_irq_work_raise(). The callbacks are then ran from the timer
> > interrupt.
> 
> Looks like that wouldn't be too difficult - meaning implement a similar
> form of IRQ_WORKER that would call
> 
>  inc_irq_stat(apic_irq_work_irqs);
>  irq_work_run();
> 
> .. along with the rest of the stuff from Ben's patch. Let me see if I can
> prep a patch.

Peter,

I am going to start cracking at this to see why the self-IPI don't seem to
work, while the patch that was removed (so the NMI, would just check on its
own CPU whether it was called without doing the NMI).

But in the meantime, are there any good docs to look over to get a good idea
of how the perf code works?

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