From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754748AbbL3VID (ORCPT ); Wed, 30 Dec 2015 16:08:03 -0500 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:11390 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753899AbbL3VH7 (ORCPT ); Wed, 30 Dec 2015 16:07:59 -0500 Date: Wed, 30 Dec 2015 16:07:36 -0500 From: Chris Mason To: Nicholas Krause CC: , , , Subject: Re: [PATCH RESEND] btrfs:Fix incorrect return statement if failure occurs in the function btrfs_mark_extent_written Message-ID: <20151230210736.24bgnuxycchlsusd@ret.masoncoding.com> Mail-Followup-To: Chris Mason , Nicholas Krause , jbacik@fb.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org References: <1451438447-23679-1-git-send-email-xerofoify@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1451438447-23679-1-git-send-email-xerofoify@gmail.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) X-Originating-IP: [192.168.52.123] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-12-30_13:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 29, 2015 at 08:20:47PM -0500, Nicholas Krause wrote: > This fixes the incorrect return statement if failure occurs by > returning 0 rather then the variable ret which may hold a error > code to signal when a failure has occurred in the function > btrfs_mark_extent_written to its callers rather then always > making this function appear to run successfully to its callers > by always returning zero. > > Signed-off-by: Nicholas Krause > --- > fs/btrfs/file.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c > index b823fac..7a9ab8e 100644 > --- a/fs/btrfs/file.c > +++ b/fs/btrfs/file.c > @@ -1276,7 +1276,7 @@ again: > } > out: > btrfs_free_path(path); > - return 0; > + return ret; > } We're checking ret higher up and aborting the transaction properly. There is at least one place ret will be non-zero above that isn't an error, but you're passing it to the caller here making them think it has gone wrong. -chris