From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 22 14:42:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2746106566B for ; Thu, 22 Mar 2012 14:42:54 +0000 (UTC) (envelope-from eric.saintetienne@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2EBBD8FC0A for ; Thu, 22 Mar 2012 14:42:53 +0000 (UTC) Received: by vbmv11 with SMTP id v11so1431097vbm.13 for ; Thu, 22 Mar 2012 07:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=G8rBCFhFISeRMoVFuXwD3NN+Bf7WqpoT5UFSBTvjUYY=; b=Kmw1jjPs8gAlo5QJ8STFGUbZ+5TSSltO/4TC5uNPLErMdZxPpk9d56GrPj2MCkP1Pb wIG8dd7Xi7KfOOLD6X3htq4AYSsHOlALJFLL42GGJ2Sm0HgPJfqoSSjAq4sUFHqp4mi1 t8scXuZeJ5BIs4NpoJkKo5b15sRtNkkJ5xAzhCI0Mmyv/DS49L4DFTwavdwIlls6KtQr Xh7QTdOM4/RUGfNmhvHbNFM7y1TOzoLW9UywtcHWy/x30aVAZE5zx0HkYr+CHb9a4IE9 qMcuHxzioZhGr7oHWkmNU3BVSoA5mrtfEhVgtIYPHD0+VCnq6pTLk3q7+H7olwynJDVJ O9gw== Received: by 10.220.116.68 with SMTP id l4mr3954781vcq.4.1332427373468; Thu, 22 Mar 2012 07:42:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.149.9 with HTTP; Thu, 22 Mar 2012 07:42:22 -0700 (PDT) In-Reply-To: References: From: Eric Saint-Etienne Date: Thu, 22 Mar 2012 14:42:22 +0000 Message-ID: To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: malloc pages map to user space X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 14:42:54 -0000 > By using kernel_map instead of kmem_map, vm_map_lookup() now always > return a vm_object. That's a big progress. > As expected, when this object is kmem_object, the user mapping works > fine (for smaller or larger mallocs.) > > Otherwise that object doesn't match kernel_object. It's an anonymous > object to me. > Using that "anonymous" vm_object for mapping into user map (using > vm_map_find()) doesn't directly fail, > it does provide a virtual address in the user map. However I read > zeros at that address, from within the user process. Actually when using kernel_map, the object returned is NULL! However the the vm_entry_t it returns seems a valid address, its 'object' field is NULL too (that's consistent) That's the reason why I didn't find it in any existing 'puclic' map (such as kernel_map, buffers_map, kmem_map, exec_map or pipe_map) But a NULL object isn't good at anything and I'm not sure what to do with a vm_entry_t only... Any idea how to insert it in the process map?