From owner-freebsd-arch@FreeBSD.ORG  Fri Jul 23 13:47:30 2010
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 602171065672
	for <freebsd-arch@freebsd.org>; Fri, 23 Jul 2010 13:47:30 +0000 (UTC)
	(envelope-from freebsd-arch@m.gmane.org)
Received: from lo.gmane.org (lo.gmane.org [80.91.229.12])
	by mx1.freebsd.org (Postfix) with ESMTP id 1AA258FC08
	for <freebsd-arch@freebsd.org>; Fri, 23 Jul 2010 13:47:29 +0000 (UTC)
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <freebsd-arch@m.gmane.org>) id 1OcIb0-0004N4-GK
	for freebsd-arch@freebsd.org; Fri, 23 Jul 2010 15:47:26 +0200
Received: from lara.cc.fer.hr ([161.53.72.113])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <freebsd-arch@freebsd.org>; Fri, 23 Jul 2010 15:47:26 +0200
Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <freebsd-arch@freebsd.org>; Fri, 23 Jul 2010 15:47:26 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: freebsd-arch@freebsd.org
From: Ivan Voras <ivoras@freebsd.org>
Date: Fri, 23 Jul 2010 15:47:41 +0200
Lines: 19
Message-ID: <i2c6h5$3cv$1@dough.gmane.org>
References: <AANLkTikoY8CuAF3DThBAXH_mu1QAuUWyRMtkaIomaoi7@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US;
	rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4
In-Reply-To: <AANLkTikoY8CuAF3DThBAXH_mu1QAuUWyRMtkaIomaoi7@mail.gmail.com>
X-Enigmail-Version: 1.0.1
Subject: Re: Multi-zone malloc(9)
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jul 2010 13:47:30 -0000

On 07/22/10 18:54, mdf@FreeBSD.org wrote:
> Occasionally we run into use-after-free and malloc'd buffer overrun
> scenarios.  When this happens it can be rather difficult to determine
> what code is at fault, since e.g. every 64 byte allocation, regardless
> of malloc type, comes from the same UMA zone.  This means that an
> overflow in M_TEMP will affect M_DEVBUF, etc.  Adding multiple uma
> zones for each bucket size means that we can hash on the malloc type's
> shortdesc field so that there are fewer collisions and misused memory
> from one malloc type only affects a subset of other malloc types.

To what extent does something like this help? As I read it, you still
have the problem of overflows from one allocation trashing data in some
other random allocation, but now you also have to track which hash
bucket is it in while debugging?

And would this interfere with possible NUMA efforts? (because it sort of
looks similar - hashing allocations to "zones", which in NUMA case would
be per-CPU).