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>