From owner-freebsd-bugs@FreeBSD.ORG Fri Feb 8 12:50:01 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 34E03BF4 for ; Fri, 8 Feb 2013 12:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 2447B2E5 for ; Fri, 8 Feb 2013 12:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r18Co1le078263 for ; Fri, 8 Feb 2013 12:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r18Co1Kr078262; Fri, 8 Feb 2013 12:50:01 GMT (envelope-from gnats) Date: Fri, 8 Feb 2013 12:50:01 GMT Message-Id: <201302081250.r18Co1Kr078262@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Andriy Gapon Subject: Re: bin/174831: [PATCH] geli(8) segfaults with the new locked memory limit default X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Andriy Gapon List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 12:50:01 -0000 The following reply was made to PR bin/174831; it has been noted by GNATS. From: Andriy Gapon To: =?UTF-8?B?VWxyaWNoIFNww7ZybGVpbg==?= Cc: bug-followup@FreeBSD.org, fk@fabiankeil.de, zont@FreeBSD.org Subject: Re: bin/174831: [PATCH] geli(8) segfaults with the new locked memory limit default Date: Fri, 08 Feb 2013 14:43:19 +0200 on 08/02/2013 14:16 Ulrich Spörlein said the following: > While geli should definitely be fixed to provide a meaningful error > message instead of a crash, we also need to keep it working out of the > box. > > For me, 256K seems to be enough to make it work, but I guess this is a > function of the used crypto algorithms and key sizes. Can you maybe > adapt the check to figure out how much memory actually needs to be > mlocked? > > Once we come up with a better upper limit, the default in login.conf > should be bumped accordingly. > unlimited is a perfect limit. No program won't complain. -- Andriy Gapon