From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 4 09:00:56 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 2A65F16A468 for ; Wed, 4 Jul 2007 09:00:56 +0000 (UTC) (envelope-from n.cormier@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.freebsd.org (Postfix) with ESMTP id D499613C45B for ; Wed, 4 Jul 2007 09:00:55 +0000 (UTC) (envelope-from n.cormier@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so4204460pyb for ; Wed, 04 Jul 2007 02:00:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iyp3K0rGFrVcsVP+sgZqDG6D8vX+ztnZU5n94dYAV3/Jp8H8ViW3cTghQej/dKGLfB1BsYX41wkhwSr0mLs+AOxZUzR8kZ8NzzlmcWv2QpoMsAjwndnz/6QYU3gn7uY9ShbsZE2daaaSNdTIavxHkuIjQww5UmWjcKUmy/SbrWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=L+Fq8GctS5b5yf0axr3I/zYtqXUf3VDZ09X1wSExSs4Jq8+b/G4YqJJMOUCORrJj9AgbXmMQHcnd0VwAiRdZy1ZDXGDuFbwj2ZNS6z2O8ANVRv/C/+9mNNHnwgIuP0oRarNZv8mJayTgo7qpk56Y6hT6Bu2tHpHghPbILN0Zb3c= Received: by 10.35.39.2 with SMTP id r2mr9387257pyj.1183539654590; Wed, 04 Jul 2007 02:00:54 -0700 (PDT) Received: by 10.35.40.11 with HTTP; Wed, 4 Jul 2007 02:00:54 -0700 (PDT) Message-ID: Date: Wed, 4 Jul 2007 11:00:54 +0200 From: "Nicolas Cormier" To: "Robert Watson" In-Reply-To: <20070704091349.T42421@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070704091349.T42421@fledge.watson.org> Cc: freebsd-hackers@freebsd.org Subject: Re: p_vmspace in syscall 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: Wed, 04 Jul 2007 09:00:56 -0000 On 7/4/07, Robert Watson wrote: > > On Mon, 2 Jul 2007, Nicolas Cormier wrote: > > > I am trying to map some data allocated in kernel to a user process (via a > > syscall). I need the proc's vmspace, but the value of p_vmspace of the input > > proc argument is NULL ... How can I get a valid vmspace ? > > When operating in a system call, the 'td' argument to the system call function > is the current thread pointer. You can follow td->td_proc to get to the > current process (and therefore, its address space). In general, I prefer > mapping user pages into kernel instead of kernel pages into user space, as it > reduces the chances of leakage of kernel data to user space, and there are > some useful primitives for making this easier. For example, take a look at > the sf_buf infrastructure used for things like socket zero-copy send, which > manages a temporary kernel mapping for a page. > Yes Roman told me in private that I'm wrong with the first argument, I thought that it was a proc*... For my module I try to create a simple interface of a network allocator: User code should look like this: unsigned id; void* data = netmalloc(host, size, &id); memcpy(data, "toto", sizeof("toto"); netdetach(data); and later in another process: void* data = netattach(host, id); ... netfree(data); netmalloc syscall does something like that: - query distant host to allocate size - receive an id from distant host - malloc in kernel size - map the buffer to user process (*) netdetach syscall: - send data to distant host netattach syscall: - get data from host - malloc in kernel size - map the buffer to user process (*) * I already watch the function vm_pgmoveco (http://fxr.watson.org/fxr/source/kern/kern_subr.c?v=RELENG62#L78) I used pgmoveco as follow: vm_map_t mapa = &proc->p_vmspace->vm_map, size = round_page(size); void* data = malloc(size, M_NETMALLOC, M_WAITOK); vm_offset_t addr = vm_map_min(mapa); vm_map_find(mapa, NULL, 0, &addr, size, TRUE, VM_PROT_ALL, VM_PROT_ALL, MAP_NOFAULT); vm_pgmoveco(mapa, (vm_offset_t)data, addr); With this I have a panic with vm_page_insert, I am not sure to understand the reason of this panic. I can't have multiple virtual pages on the same physical page ? Thanks! -- Nicolas Cormier