Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760707AbYBHHtR (ORCPT ); Fri, 8 Feb 2008 02:49:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753246AbYBHHtE (ORCPT ); Fri, 8 Feb 2008 02:49:04 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]:20110 "EHLO rv-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753122AbYBHHtB (ORCPT ); Fri, 8 Feb 2008 02:49:01 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=KPE8Qse+5x6sxCqS61p6ZGIMO9IWImZaoYrI9glGPTE/4MFrpZXBtsIAY4/8OzWOHA6T/9/irPT0QsnFIfjR/N6GfwV5YAD9fIoO8VI2zjgW3EPXJrnyCw57NCroi8Q4kXZpj4cqsvgpSdI2AkR8YTkxqVi7UjMd48MkSrx4UzY= Message-ID: <84144f020802072348p2f9bda73m52fcc07e272dd68c@mail.gmail.com> Date: Fri, 8 Feb 2008 09:48:58 +0200 From: "Pekka Enberg" To: "Christoph Lameter" Subject: Re: [PATCH 1/2] kmemcheck v3 Cc: "Vegard Nossum" , "Linux Kernel Mailing List" , "Ingo Molnar" , "Andi Kleen" , "Richard Knutsson" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47AB79D4.2070605@gmail.com> X-Google-Sender-Auth: 14d4db9369e0dc1d Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1332 Lines: 26 Hi Christoph, On Thu, 7 Feb 2008, Vegard Nossum wrote: > > - DMA can be a problem since there's generally no way for kmemcheck to > > determine when/if a chunk of memory is used for DMA. Ideally, DMA should be > > allocated with untracked caches, but this requires annotation of the > > drivers in question. On Feb 8, 2008 9:10 AM, Christoph Lameter wrote: > There is a fundamental misunderstanding here: GFP_DMA allocations have > nothing to do with DMA. Rather GFP_DMA means allocate memory in a special > range of physical memory that is required by legacy devices that cannot > use the high address bits for one or the other reason. Any regular > memory can be used for DMA. No there isn't and we've been over this with Vegard many times :-). Christoph, can you actually see this in the patch? There shouldn't be any __GFP_DMA confusion there. What we have is per-object __GFP_NOTRACK which can be used to suppress false positives for DMA-filled objects and SLAB_NOTRACK for whole _caches_ that contains objects which we must not take page faults at all. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/