From owner-freebsd-geom@FreeBSD.ORG Mon Mar 16 10:18:45 2015 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44EC1959; Mon, 16 Mar 2015 10:18:45 +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 19D263E0; Mon, 16 Mar 2015 10:18:44 +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 048C637B568; Mon, 16 Mar 2015 05:18:44 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l5D9v3xdhzcJ; Mon, 16 Mar 2015 05:18:43 -0500 (CDT) Date: Mon, 16 Mar 2015 05:18:43 -0500 From: "Matthew D. Fuller" To: Pawel Jakub Dawidek Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150316101843.GE52331@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> <20150316101323.GD52331@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150316101323.GD52331@over-yonder.net> 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:18:45 -0000 On Mon, Mar 16, 2015 at 05:13:23AM -0500 I heard the voice of Matthew D. Fuller, and lo! it spake thus: > > , 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. As a side note, this seems to turn from "darn" to "panic" because in g_eli_read_metadata(), it doesn't check the return from eli_metadata_decode(), so it doesn't notice the EINVAL and happily reports back success without ever having touched the md :( -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.