From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Kleikamp Subject: Re: [PATCH 12/12: eCryptfs] Crypto functions Date: Thu, 03 Nov 2005 16:30:09 -0600 Message-ID: <1131057009.9365.21.camel@kleikamp.austin.ibm.com> References: <20051103033220.GD2772@sshock.rn.byu.edu> <20051103035659.GL3005@sshock.rn.byu.edu> <1131055610.9365.17.camel@kleikamp.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Phillip Hellewell , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, mike@halcrow.us, mhalcrow@us.ibm.com, mcthomps@us.ibm.com, yoder1@us.ibm.com Return-path: To: Michael Thompson In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2005-11-03 at 16:25 -0600, Michael Thompson wrote: > On 11/3/05, Dave Kleikamp wrote: > > On Wed, 2005-11-02 at 20:56 -0700, Phillip Hellewell wrote: > > > + ecryptfs_fput(lower_file); > > > > Why the call to ecryptfs_fput() here? The caller does it's own fput on > > lower_file. > > Hmm, good catch. That slipped through us - and to be hoenst, I have no > explination other than, it's wrong. ecryptfs_write_headers should not > be responsible for put'ing that which it did not get. > > I'm wondering if I should be sending 1 patch per tiny fix like this, > or if I should be waiting for a few more changes, so as to not flood > the threads with minor patches? Well, I found it trying to look for the cause of bug 1228303, but I haven't actually run anything to verify it. It may be worth checking if it fixes that problem, and if it does, it would bump up its importance. > Thanks, > Mike > -- David Kleikamp IBM Linux Technology Center