From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 30 02:11:25 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9D0416A4D7 for ; Tue, 30 Sep 2003 02:11:25 -0700 (PDT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id C8AB24403B for ; Tue, 30 Sep 2003 02:11:22 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 943 invoked from network); 30 Sep 2003 09:11:21 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.140.130) by gandalf.online.bg with SMTP; 30 Sep 2003 09:11:21 -0000 Received: (qmail 26391 invoked by uid 1000); 30 Sep 2003 08:59:13 -0000 Date: Tue, 30 Sep 2003 11:59:13 +0300 From: Peter Pentchev To: Brian O'Shea Message-ID: <20030930085913.GJ551@straylight.oblivion.bg> Mail-Followup-To: Brian O'Shea , Pawel Jakub Dawidek , freebsd-hackers@freebsd.org, earthman References: <20030929155613.GB551@straylight.oblivion.bg> <20030930000405.12154.qmail@web10509.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3ecMC0kzqsE2ddMN" Content-Disposition: inline In-Reply-To: <20030930000405.12154.qmail@web10509.mail.yahoo.com> User-Agent: Mutt/1.5.4i cc: earthman cc: freebsd-hackers@freebsd.org Subject: Re: user malloc from kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 09:11:26 -0000 --3ecMC0kzqsE2ddMN Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 29, 2003 at 05:04:05PM -0700, Brian O'Shea wrote: > --- Peter Pentchev wrote: [actually, Pawel wrote this:] > > > Here you got sample kernel module which do this: > > >=20 > > > http://garage.freebsd.pl/usmalloc.tgz > > > http://garage.freebsd.pl/usmalloc.README [and then I replied] > >=20 > > Errrr... but won't this interfere *badly* with userland programs > > which attempt to allocate memory after making the syscall in question? >=20 > Couldn't the user library interface to this new system call just > malloc() the memory first in the process, and then pass the pointer > and size to the kernel via the system call interface? This would > ensure that malloc() doesn't touch the desired range of memory until > it is freed by the user. You'd just have to be careful not to free > it until the kernel is done with it. This would be my preferred solution, too, although it might mean that when you are not exactly sure of how much memory the kernel will need, you either overallocate and pass a max-size argument (see most of the socket calls like accept(2), getsockname(2), getpeername(2), etc), or you do two syscalls, one for determining the size needed, and another for actually copying the data (see sysctl(3)). The second approach is more robust, but it does have the overhead of an additional syscall and might also possibly be vulnerable to a race (if the data should change between the two invocations). This, of course, could be worked around by having another couple of syscalls for locking and unlocking the data - lock, query size, fetch, unlock - but that would open a whole new can of worms :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If wishes were fishes, the antecedent of this conditional would be true. --3ecMC0kzqsE2ddMN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/eUXh7Ri2jRYZRVMRAmnMAJ9+MA181BQI8/vi4SzOe5vDTYUYhgCgrOlb Lswoo3ZyAYABUX1UERrxifk= =NGxk -----END PGP SIGNATURE----- --3ecMC0kzqsE2ddMN--