From owner-freebsd-geom@FreeBSD.ORG Mon Mar 16 10:13:25 2015 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 428B16A2; Mon, 16 Mar 2015 10:13:25 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 17CF335A; Mon, 16 Mar 2015 10:13:24 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id AC24737B568; Mon, 16 Mar 2015 05:13:23 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l5D3l15CPzc6; Mon, 16 Mar 2015 05:13:23 -0500 (CDT) Date: Mon, 16 Mar 2015 05:13:23 -0500 From: "Matthew D. Fuller" To: Pawel Jakub Dawidek Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150316101323.GD52331@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> <20150314151453.GJ24274@over-yonder.net> <501bca86.508d8e26@fabiankeil.de> <20150315145324.GA52331@over-yonder.net> <20150315182444.GB52331@over-yonder.net> <20150316010845.GA1515@garage.freebsd.pl> <20150316092126.GC52331@over-yonder.net> <20150316100030.GB1515@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150316100030.GB1515@garage.freebsd.pl> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 10:13:25 -0000 On Mon, Mar 16, 2015 at 11:00:31AM +0100 I heard the voice of Pawel Jakub Dawidek, and lo! it spake thus: > > Still would be good to know the root cause of what you are seeing. I've about used up my investigation time for right now, but what I've found is that onetime providers wind up with no md_magic and no (0) md_version, so eli_metadata_decode() EINVAL's right up at the top before filling anything into the passed md. As a result, in g_eli_ctl_configure(), it gets (keeps) stack garbage in the var. So actually, it DOESN'T work without nop, things just happen to align so that stack garbage has a 0 for version (which is valid version) rather than 2-billion-something (which isn't). Now, regular providers get init'd in userland, so it's hard to compare. However, my current thinking is that onetime does much of what 'geli attach' does, but not all of what 'geli init' does; it doesn't ever write out the metadata to the provider since it doesn't need to persist. But when configure wants to load the metadata, it takes it from the provider, and so *boom*. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.