From owner-freebsd-net@freebsd.org Thu Jul 30 04:46:05 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 5C88F9AEFD0 for ; Thu, 30 Jul 2015 04:46:05 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 12D661B61; Thu, 30 Jul 2015 04:46:04 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t6U4k3Aj022059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2015 21:46:03 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t6U4k3Uh022058; Wed, 29 Jul 2015 21:46:03 -0700 (PDT) (envelope-from jmg) Date: Wed, 29 Jul 2015 21:46:03 -0700 From: John-Mark Gurney To: Laurie Jennings Cc: John Baldwin , freebsd-net@freebsd.org Subject: Re: Locking Memory Question Message-ID: <20150730044603.GQ78154@funkthat.com> References: <20150729232522.GN78154@funkthat.com> <1438217542.41867.YahooMailBasic@web141502.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1438217542.41867.YahooMailBasic@web141502.mail.bf1.yahoo.com> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Wed, 29 Jul 2015 21:46:03 -0700 (PDT) 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 04:46:05 -0000 Laurie Jennings wrote this message on Wed, Jul 29, 2015 at 17:52 -0700: > -------------------------------------------- > On Wed, 7/29/15, John-Mark Gurney wrote: > > Subject: Re: Locking Memory Question > To: "Laurie Jennings" > Cc: "John Baldwin" , freebsd-net@freebsd.org > Date: Wednesday, July 29, 2015, 7:25 PM > > Laurie Jennings via > freebsd-net wrote this message on Wed, Jul 29, 2015 at 15:26 > -0700: > > > > I have a problem and > I can't quite figure out where to look. This is what Im > doing: > > > > I have an > IOCTL to read a block of data, but the data is too large to > return via ioctl. So to get the data, > > I > allocate a block in a kernel module: > > > > > foo = > malloc(1024000,M_DEVBUF,M_WAITOK); > > > >  I pass up a pointer and in user space > map it using /dev/kmem: > > An easier solution would be for your ioctl to > pass in a userland > pointer and then use > copyout(9) to push the data to userland...  This > means the userland process doesn't have to > have /dev/kmem access... > > Is > there a reason you need to use kmem?  The only reason you > list above > is that it's too large via > ioctl, but a copyout is fine, and would > handle all page faults for you.. > > __________________________________ > I'm using kmem because the only options I could think of was to > > 1) use shared memory > 2) use kmem > 3) use a huge ioctl structure. > > 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... > Or > would I just have to pass down a pointer to a huge buffer large enough for the largest possible answer? This is probably the easiest... This is similar to what sysctl does... As part of sysctl, if the program didn't allocate enough space for the buffer, it will return the require space, so that the next call it will be correct (assuming size doesn't change regularly)... Good luck! -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."