From owner-freebsd-bugs@FreeBSD.ORG Fri Feb 8 12:20: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 5933856B for ; Fri, 8 Feb 2013 12:20: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 487E5173 for ; Fri, 8 Feb 2013 12:20: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 r18CK1VA073510 for ; Fri, 8 Feb 2013 12:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r18CK11A073505; Fri, 8 Feb 2013 12:20:01 GMT (envelope-from gnats) Date: Fri, 8 Feb 2013 12:20:01 GMT Message-Id: <201302081220.r18CK11A073505@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= 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: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 12:20:01 -0000 The following reply was made to PR bin/174831; it has been noted by GNATS. From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= To: bug-followup@FreeBSD.org, fk@fabiankeil.de, zont@FreeBSD.org, avg@FreeBSD.org Cc: Subject: Re: bin/174831: [PATCH] geli(8) segfaults with the new locked memory limit default Date: Fri, 8 Feb 2013 13:16:37 +0100 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.