From owner-freebsd-bugs@FreeBSD.ORG Mon Jan 3 20:01:49 2005 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE18516A4CE for ; Mon, 3 Jan 2005 20:01:49 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 361F143D2D for ; Mon, 3 Jan 2005 20:01:49 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id j03JwCTS055246; Mon, 3 Jan 2005 14:58:12 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)j03Jw1oN055243; Mon, 3 Jan 2005 19:58:01 GMT (envelope-from robert@fledge.watson.org) Date: Mon, 3 Jan 2005 19:58:01 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: David Shaw In-Reply-To: <20041215040534.GC32762@jabberwocky.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: gnupg-devel@gnupg.org cc: freebsd-bugs@freebsd.org cc: Atom 'Smasher' Subject: Re: GnuPG + FreeBSD 5.3 = intermitent memory warning X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2005 20:01:49 -0000 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