From owner-freebsd-arch@FreeBSD.ORG Fri Jul 23 15:48:28 2010 Return-Path: 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 D9F4C1065679 for ; Fri, 23 Jul 2010 15:48:28 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7EF528FC14 for ; Fri, 23 Jul 2010 15:48:28 +0000 (UTC) Received: by yxe42 with SMTP id 42so3959388yxe.13 for ; Fri, 23 Jul 2010 08:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ij4tMd8PQ89zDc5bSnfRwmXay8F5vHHn9HEHQsdd2dc=; b=XjHWDXULhD+i2jigojcTeFVyC2lBXf7cD6AQ3OE9d3AP0JxBcOezCAYdceRmvDd+cP Cad9FBGpVg8mS0q1E/Nl9TiUcciKd79Ui2nGogkJcQsgayaiImgUfeZ5DOkIPGq+ogBI 66RmvDiXEs0U1NGDmmaFPIQGUEp72l0U9oKSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IdPv/+rOA5JIUH+99QAHRhjmk9Dc9KKcaU+jB5xXa2r4eys8vu/l02NS1t4xl9XmTp dYChj2IHMB+p1Bu9IURRvb8c6cuS37sGxR0cgCvBn+a8weEJv8C2XXcpagy7BLV7xHFC ULGDaSb/AUFeTpgevK27vHai8EjBZ4vKKmNaE= MIME-Version: 1.0 Received: by 10.151.139.16 with SMTP id r16mr5916863ybn.168.1279900105708; Fri, 23 Jul 2010 08:48:25 -0700 (PDT) Received: by 10.42.6.85 with HTTP; Fri, 23 Jul 2010 08:48:25 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Jul 2010 08:48:25 -0700 Message-ID: From: Matthew Fleming To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 15:48:28 -0000 On Fri, Jul 23, 2010 at 6:47 AM, Ivan Voras wrote: > On 07/22/10 18:54, mdf@FreeBSD.org wrote: >> Occasionally we run into use-after-free and malloc'd buffer overrun >> scenarios. =A0When 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. =A0This means that an >> overflow in M_TEMP will affect M_DEVBUF, etc. =A0Adding 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? It helps in that, with several repros on different hash functions, you now can know exactly which malloc type was doing the trashing, because it's the intersection of all the hash classes from each instance. Assuming you have a core dump, the hash class is listed in the malloc_type_internal hanging off the malloc type, so it's easy to correlate. There's a ddb function in the patch to print all the matching types, and a gdb script would be easy to write as well. > 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). The NUMA effort with malloc/uma is still theoretical so I can't say for sure, but I believe these two issues are orthogonal. Thanks, matthew