From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Zwisler Subject: Re: [PATCH 2/2] ext2: Add locking for DAX faults Date: Tue, 13 Oct 2015 16:15:30 -0600 Message-ID: <20151013221530.GA17773@linux.intel.com> References: <1444428128-12200-1-git-send-email-ross.zwisler@linux.intel.com> <1444428128-12200-3-git-send-email-ross.zwisler@linux.intel.com> <20151011231443.GY27164@dastard> <20151012214135.GA24720@linux.intel.com> <20151012232427.GH27164@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Dave Chinner , Ross Zwisler , Kernel development list , Jan Kara , linux-ext4@vger.kernel.org, Dan Williams , linux-nvdimm@lists.01.org, Matthew Wilcox , Andreas Dilger To: Eric Curtin Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org On Tue, Oct 13, 2015 at 12:35:44AM +0100, Eric Curtin wrote: > Hi Ross, >=20 > For all those int ret declarations. Why not declare and initialize al= l > on the same line? >=20 > Regards, > Eric Because the return value 'ret' is set unconditionally later in the func= tion as part of a call into the DAX code. This call needs to be made after we'= ve done appropriate locking, though, which really is the point of the ext2 wrap= per for the DAX function. Setting it to some random value and then uncondition= ally overwriting it later in the function is a bad pattern because a) the in= itial value is meaningless and b) it can hide coding errors where you are no = longer setting the variable to something meaningful. The "warning: =E2=80=98r= et=E2=80=99 is used uninitialized in this function" warnings would otherwise warn you that = you've made a mistake. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753286AbbJMWPd (ORCPT ); Tue, 13 Oct 2015 18:15:33 -0400 Received: from mga03.intel.com ([134.134.136.65]:7018 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752053AbbJMWPc (ORCPT ); Tue, 13 Oct 2015 18:15:32 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,680,1437462000"; d="scan'208";a="810307645" Date: Tue, 13 Oct 2015 16:15:30 -0600 From: Ross Zwisler To: Eric Curtin Cc: Dave Chinner , Ross Zwisler , Kernel development list , Jan Kara , linux-ext4@vger.kernel.org, Dan Williams , linux-nvdimm@ml01.01.org, Matthew Wilcox , Andreas Dilger Subject: Re: [PATCH 2/2] ext2: Add locking for DAX faults Message-ID: <20151013221530.GA17773@linux.intel.com> References: <1444428128-12200-1-git-send-email-ross.zwisler@linux.intel.com> <1444428128-12200-3-git-send-email-ross.zwisler@linux.intel.com> <20151011231443.GY27164@dastard> <20151012214135.GA24720@linux.intel.com> <20151012232427.GH27164@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 13, 2015 at 12:35:44AM +0100, Eric Curtin wrote: > Hi Ross, > > For all those int ret declarations. Why not declare and initialize all > on the same line? > > Regards, > Eric Because the return value 'ret' is set unconditionally later in the function as part of a call into the DAX code. This call needs to be made after we've done appropriate locking, though, which really is the point of the ext2 wrapper for the DAX function. Setting it to some random value and then unconditionally overwriting it later in the function is a bad pattern because a) the initial value is meaningless and b) it can hide coding errors where you are no longer setting the variable to something meaningful. The "warning: ‘ret’ is used uninitialized in this function" warnings would otherwise warn you that you've made a mistake.