From owner-freebsd-net@freebsd.org Thu Jul 30 06:28:04 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 707AD9ADF9A for ; Thu, 30 Jul 2015 06:28:04 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 448ABACC; Thu, 30 Jul 2015 06:28:04 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by pdjr16 with SMTP id r16so19364900pdj.3; Wed, 29 Jul 2015 23:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=F0hnjzhRPNwHAhDS8BWvPAbrxgmdm+SufRDYmI+SONE=; b=WTdTsP6a5qmNZ1Uldr62ZKuEkM1BV60cjGlspg30IeZLawrvb71+gOp2pSvh4d7Dp1 cBhhypND3PQeR0ttRx1loUAlH8cBMc4YRzNBczdWZeNOdcXf8+QomS0ys7elcCjhY4O6 e0FojmdFlvN7nzZYtJZvY3k6cVfZiHEER1EMu53sB18+AJVbYjs4rQVHfQT66Iprwb+b fffE6GZIfsx7H4aCGJ5ZKmy9J7g8PdcJ3sYgtUxFXHmB1KKxdRxjVMIwOdJos1vxMrU7 DdOu3UEhruQvpOTW/uZ5Oyyc2xKOjPYPNjex/wsZaIY1ToWZcANmaRT8kEmtQ4fN4DdM 63+g== MIME-Version: 1.0 X-Received: by 10.70.65.38 with SMTP id u6mr100349431pds.99.1438237683601; Wed, 29 Jul 2015 23:28:03 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.66.236.36 with HTTP; Wed, 29 Jul 2015 23:28:03 -0700 (PDT) In-Reply-To: <20150730044603.GQ78154@funkthat.com> References: <20150729232522.GN78154@funkthat.com> <1438217542.41867.YahooMailBasic@web141502.mail.bf1.yahoo.com> <20150730044603.GQ78154@funkthat.com> Date: Wed, 29 Jul 2015 23:28:03 -0700 X-Google-Sender-Auth: whGHqYNhpo8eq_wgDARiQnW_mj0 Message-ID: Subject: Re: Locking Memory Question From: "K. Macy" To: John-Mark Gurney Cc: Laurie Jennings , "freebsd-net@freebsd.org" , John Baldwin Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 06:28:04 -0000 >> >> Im not clear how I'd do that. the data being passed up from the kernel is a variable size. To use copyout I'd have to pass a >> pointer with a static buffer, right? > > Correct, you can pass along the size, and if it's not large enough > try again... Less than ideal... > >> Is there a way to malloc user space memory from within an ioctl call? > > Well, it is possible that you could do the equivalent of mmap, and pass > the address back along w/ a length, and leave it up to the user to > munmap it... This is probably the nicest method if you the size is > really largely variable, and it's expensive if the userland process > allocated too much memory... The down side is that this is more > complex to code... > Mach has the ability to send large "out of line messages". For smaller messages where it doesn't do VM tricks to avoid copying it does exactly this. In the receive path the kernel calls vm_allocate (which is essentially just a wrapper for mmap) then copies the buffer in to the newly allocated address space. The message itself contains the allocated address and size of the allocation. The receiver is expected to call vm_deallocate (munmap) when it's done with the data. The implementation is mixed in with enough other code that it may not be a useful reference. Nonetheless, I wanted to point at that this isn't as strange as it might sound. -K