Date: Tue, 30 Sep 2003 11:59:13 +0300 From: Peter Pentchev <roam@ringlet.net> To: Brian O'Shea <b_oshea@yahoo.com> Cc: freebsd-hackers@freebsd.org Subject: Re: user malloc from kernel Message-ID: <20030930085913.GJ551@straylight.oblivion.bg> In-Reply-To: <20030930000405.12154.qmail@web10509.mail.yahoo.com> References: <20030929155613.GB551@straylight.oblivion.bg> <20030930000405.12154.qmail@web10509.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <roam@ringlet.net> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030930085913.GJ551>