linux-kernel - RE: [discuss] BTS overflow handling, was: [PATCH] perf_counter: Fix a race on perf_counter

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1251815745.7547.33.camel@twins>
Date:	Tue, 01 Sep 2009 16:35:45 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	"Metzger, Markus T" <markus.t.metzger@...el.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"hpa@...or.com" <hpa@...or.com>,
	"markus.t.metzger@...il.com" <markus.t.metzger@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Paul Mackerras <paulus@...ba.org>
Subject: RE: [discuss] BTS overflow handling, was: [PATCH] perf_counter:
 Fix a race on perf_counter_ctx

On Tue, 2009-09-01 at 15:27 +0100, Metzger, Markus T wrote:

> >> >> I do need 3 buffers of 2048 entries = 3x48 pages per cpu, though.
> >> >
> >> >And those pages have to be contiguous too, right? That's an order-6
> >> >alloc, painful.
> >>
> >>
> >> According to an earlier discussion with Roland, they don't have to.
> >> They still need to be locked, though.
> >> According to some other discussion with Andrew and Ingo, I still use
> >> kmalloc to allocate those buffers.
> >
> >Section 18.18.5 of book 3B says the DS buffer base is a linear address.
> >This suggests each buffer does need contiguous pages.
> >
> >48 contiguous pages constitutes an order-6 allocation (64 pages), which
> >is unreliable at best.
> 
> Roland argued that this means virtually contiguous, not physically.

Sure it does, but either you use the linear kernel map, or use vmap.

vmap doesn't sound like very good idea.

> >> When I use schedule_work() instead, how would I ensure that the work is done
> >> before the traced (or tracing) task is rescheduled?
> >
> >No, basically the only thing left is softirqs, which can be preempted by
> >hardirqs, but that's a horrid hack too, esp since processing the BTS
> >outside of the handler will basically result in the BTS tracing its own
> >processing, generating even more data to process.
> 
> I would have disabled perf on that cpu; it won't work, otherwise,
> since the draining code alone would generate more trace than fits into
> a buffer. I would need to disable preemption, though.
> 
> Are you saying that schedule_work() won't work? It will quite likely be very
> lossy, but why won't it work at all?
> 
> How would that softirq approach work? Could you point me to some reference
> code?

Look at the tasklet stuff I guess. Look at tasklet_hi_schedule() and co.

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