linux-kernel - RE: [patch 03/20] x86, ptrace, bts: defer branch trace stopping

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]

Date:	Sat, 04 Apr 2009 13:12:31 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	"Metzger, Markus T" <markus.t.metzger@...el.com>
Cc:	"mingo@...e.hu" <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>,
	"roland@...hat.com" <roland@...hat.com>,
	"eranian@...glemail.com" <eranian@...glemail.com>,
	"oleg@...hat.com" <oleg@...hat.com>,
	"Villacis, Juan" <juan.villacis@...el.com>,
	"ak@...ux.jf.intel.com" <ak@...ux.jf.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: RE: [patch 03/20] x86, ptrace, bts: defer branch trace stopping

On Sat, 2009-04-04 at 08:17 +0100, Metzger, Markus T wrote:
> >-----Original Message-----
> >From: Peter Zijlstra [mailto:a.p.zijlstra@...llo.nl]
> >Sent: Friday, April 03, 2009 5:01 PM
> >To: Metzger, Markus T
> 
> 
> >Also, I can't say I like the name, what about something like:
> >
> >void account_locked_buffer(struct mm_struct *mm, long pages)
> >{
> >	down_write(&mm->mmap_sem);
> >
> >	mm->total_vm += pages;
> >	mm->locked_vm += pages;
> >
> >	up_write(&mm->mmap_sem);
> >}
> >
> >but looking more closely at that alloc_locked_buffer() stuff, I really
> >hate it, who in his right mind does a multi-page kmalloc() -- that's
> >crazy.
> 
> I need a non-pageable chunk of memory to give to the cpu to store branch
> trace data in. Kmalloc() is easy to use and gives me what I need.
> 
> How would I do this correctly?

Well, how large should this buffer be and must it be physically
contiguous?

Apparently its large enough to account in pages, that would suggest you
should use the page allocator to get memory.

Furthermore, if it needs to be physically contiguous and its more than
say 8 pages worth, you're basically up shit creek.

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