Date: Mon, 3 Jan 2005 19:58:01 +0000 (GMT) From: Robert Watson <rwatson@freebsd.org> To: David Shaw <dshaw@jabberwocky.com> Cc: Atom 'Smasher' <atom@suspicious.org> Subject: Re: GnuPG + FreeBSD 5.3 = intermitent memory warning Message-ID: <Pine.NEB.3.96L.1050103195441.45311O-100000@fledge.watson.org> In-Reply-To: <20041215040534.GC32762@jabberwocky.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 14 Dec 2004, David Shaw wrote: > It took me a while to track this down, and thanks to Atom for helping me > run some FreeBSD tests. It turns out that this isn't a GnuPG specific > problem. The same problem can be duplicated by running any program that > calls mlock() on FreeBSD. > > FreeBSD has a "1/3 of memory" hard limit for mlock(). What seems to > have happened is that for whatever reason, Atom's system was very close > to the 1/3 magic number, and so when GnuPG tried to get its lock, it was > sometimes refused. This also explains why a busy system seemed to > aggravate the problem. > > In terms of what to do about this in GnuPG, I'm not sure if there should > be anything done. I think the the current GnuPG behavior is pretty > good: try to get locked memory, and if it can't, warn the user. I wonder if it would make sense for gnupg to print additional error information when printing the insecure memory warning? Specifically, to help identify what errno value was returned by a failing call to mlock(). This would make it easier to determine the cause of a reported failure ("EPERM - not running setuid", "EAGAIN - system/process resource limits reached"). Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050103195441.45311O-100000>