Date: Mon, 03 Nov 2014 19:35:56 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Bruce Evans <brde@optusnet.com.au> Cc: Hans Petter Selasky <hps@selasky.org>, Mateusz Guzik <mjguzik@gmail.com>, Mateusz Guzik <mjg@freebsd.org>, jmallett@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, src-committers@freebsd.org, Konstantin Belousov <kostikbel@gmail.com>, Julian Elischer <julian@freebsd.org> Subject: Re: svn commit: r274017 - head/sys/kern Message-ID: <79454.1415043356@critter.freebsd.dk> In-Reply-To: <20141104045159.E1605@besplex.bde.org> References: <201411030746.sA37kpPu037113@svn.freebsd.org> <54573AEE.9010602@freebsd.org> <54573B87.7000801@freebsd.org> <54573CD2.1000702@selasky.org> <20141103092132.GH29497@dft-labs.eu> <20141103100847.GK53947@kib.kiev.ua> <20141104045159.E1605@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- In message <20141104045159.E1605@besplex.bde.org>, Bruce Evans writes: >This optimization is probably minor, but reminds me of other syscalls >that would benefit using a single largish allocation up front: >- all vfs calls that start with namei(). They allocate PATH_MAX (1K) > bytes and more. An 8K stack has plently to spare after allocating > 1K. However, if malloc() is used then the PATH_MAX limit shouldn't > exist. Only a limit to prevent denial of service is needed. We should actually roll a new rev of all syscalls which take a path and have them pass strlen(path)+1 into the kernel. That would allow both precise allocation and faster copyin, followed by a check that the last byte is (still) a NUL. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?79454.1415043356>