From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 2 Oct 2015 17:28:42 -0600 From: Ross Zwisler Subject: Re: [PATCH 1/3] Revert "dax: fix NULL pointer in __dax_pmd_fault()" Message-ID: <20151002232842.GA19721@linux.intel.com> References: <1443819752-17091-1-git-send-email-ross.zwisler@linux.intel.com> <1443819752-17091-2-git-send-email-ross.zwisler@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org To: Dan Williams Cc: Ross Zwisler , "linux-kernel@vger.kernel.org" , Alexander Viro , Matthew Wilcox , linux-fsdevel , Andrew Morton , Dave Chinner , Jan Kara , "Kirill A. Shutemov" , "linux-nvdimm@lists.01.org" List-ID: On Fri, Oct 02, 2015 at 02:11:03PM -0700, Dan Williams wrote: > On Fri, Oct 2, 2015 at 2:02 PM, Ross Zwisler > wrote: > > This reverts commit 8346c416d17bf5b4ea1508662959bb62e73fd6a5. > > > > This commit did fix the issue it intended to fix, but it turns out that > > the locking changes introduced by these two commits: > > > > commit 843172978bb9 ("dax: fix race between simultaneous faults") > > commit 46c043ede471 ("mm: take i_mmap_lock in unmap_mapping_range() for DAX") > > > > had other issues as well, so they need to just be reverted. > > Wait, why introduce two points in the kernel history where we have a > known uninitialized variable? I'd say fix up the revert of "mm: take > i_mmap_lock in unmap_mapping_range() for DAX" to address the conflict > with the fix, one less patch and keeps the stability rolling forward. Essentially because I wasn't sure about the rules regarding reverts, if there are any. I assumed (perhaps incorrectly) that you'd want a 1:1 relationship between original commits and reverts. If it's better to not have intermediate breakage, sure, let's squash them. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751635AbbJBX2p (ORCPT ); Fri, 2 Oct 2015 19:28:45 -0400 Received: from mga02.intel.com ([134.134.136.20]:36617 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751251AbbJBX2o (ORCPT ); Fri, 2 Oct 2015 19:28:44 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,625,1437462000"; d="scan'208";a="573118165" Date: Fri, 2 Oct 2015 17:28:42 -0600 From: Ross Zwisler To: Dan Williams Cc: Ross Zwisler , "linux-kernel@vger.kernel.org" , Alexander Viro , Matthew Wilcox , linux-fsdevel , Andrew Morton , Dave Chinner , Jan Kara , "Kirill A. Shutemov" , "linux-nvdimm@lists.01.org" Subject: Re: [PATCH 1/3] Revert "dax: fix NULL pointer in __dax_pmd_fault()" Message-ID: <20151002232842.GA19721@linux.intel.com> Mail-Followup-To: Ross Zwisler , Dan Williams , "linux-kernel@vger.kernel.org" , Alexander Viro , Matthew Wilcox , linux-fsdevel , Andrew Morton , Dave Chinner , Jan Kara , "Kirill A. Shutemov" , "linux-nvdimm@lists.01.org" References: <1443819752-17091-1-git-send-email-ross.zwisler@linux.intel.com> <1443819752-17091-2-git-send-email-ross.zwisler@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Fri, Oct 02, 2015 at 02:11:03PM -0700, Dan Williams wrote: > On Fri, Oct 2, 2015 at 2:02 PM, Ross Zwisler > wrote: > > This reverts commit 8346c416d17bf5b4ea1508662959bb62e73fd6a5. > > > > This commit did fix the issue it intended to fix, but it turns out that > > the locking changes introduced by these two commits: > > > > commit 843172978bb9 ("dax: fix race between simultaneous faults") > > commit 46c043ede471 ("mm: take i_mmap_lock in unmap_mapping_range() for DAX") > > > > had other issues as well, so they need to just be reverted. > > Wait, why introduce two points in the kernel history where we have a > known uninitialized variable? I'd say fix up the revert of "mm: take > i_mmap_lock in unmap_mapping_range() for DAX" to address the conflict > with the fix, one less patch and keeps the stability rolling forward. Essentially because I wasn't sure about the rules regarding reverts, if there are any. I assumed (perhaps incorrectly) that you'd want a 1:1 relationship between original commits and reverts. If it's better to not have intermediate breakage, sure, let's squash them.