From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [PATCH v8 1/9] dax: fix NULL pointer dereference in __dax_dbg() Date: Wed, 13 Jan 2016 10:07:34 +0100 Message-ID: <20160113090734.GC14630@quack.suse.cz> References: <1452230879-18117-1-git-send-email-ross.zwisler@linux.intel.com> <1452230879-18117-2-git-send-email-ross.zwisler@linux.intel.com> <20160112093458.GR6262@quack.suse.cz> <20160113070829.GA30496@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , linux-kernel@vger.kernel.org, "H. Peter Anvin" , "J. Bruce Fields" , Theodore Ts'o , Alexander Viro , Andreas Dilger , Andrew Morton , Dan Williams , Dave Chinner , Dave Hansen , Ingo Molnar , Jan Kara , Jeff Layton , Matthew Wilcox , Matthew Wilcox , Thomas Gleixner , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org, x86@kernel.org, xfs@oss.sgi.com To: Ross Zwisler Return-path: Content-Disposition: inline In-Reply-To: <20160113070829.GA30496@linux.intel.com> Sender: owner-linux-mm@kvack.org List-Id: linux-ext4.vger.kernel.org On Wed 13-01-16 00:08:29, Ross Zwisler wrote: > On Tue, Jan 12, 2016 at 10:34:58AM +0100, Jan Kara wrote: > > On Thu 07-01-16 22:27:51, Ross Zwisler wrote: > > > In __dax_pmd_fault() we currently assume that get_block() will always set > > > bh.b_bdev and we unconditionally dereference it in __dax_dbg(). This > > > assumption isn't always true - when called for reads of holes > > > ext4_dax_mmap_get_block() returns a buffer head where bh->b_bdev is never > > > set. I hit this BUG while testing the DAX PMD fault path. > > > > > > Instead, initialize bh.b_bdev before passing bh into get_block(). It is > > > possible that the filesystem's get_block() will update bh.b_bdev, and this > > > is fine - we just want to initialize bh.b_bdev to something reasonable so > > > that the calls to __dax_dbg() work and print something useful. > > > > > > Signed-off-by: Ross Zwisler > > > Cc: Dan Williams > > > > Looks good. But don't you need to do the same for __dax_fault(), > > dax_zero_page_range() and similar places passing bh to dax functions? > > > > Honza > > I don't think we need it anywhere else. The only reason that we need to > initialize the bh.b_bdev manually in the __dax_pmd_fault() path is that if the > get_block() call ends up finding a hole (so doesn't fill out b_bdev) we still > go through the dax_pmd_dbg() path to print an error message, which uses > b_bdev. I believe that in the other paths where we hit a hole, such as > __dax_fault(), we don't use b_bdev because we don't have the same error path > prints, and the regular code for handling holes doesn't use b_bdev. > > That being said, if you feel like it's cleaner to initialize it > everywhere so everything is consistent and we don't have to worry about > it, I'm fine to make the change. Well, it seems more futureproof to me. In case someone decides to add some debug message later on... Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 8B6E57F37 for ; Wed, 13 Jan 2016 03:07:42 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id E322E8F8040 for ; Wed, 13 Jan 2016 01:07:38 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by cuda.sgi.com with ESMTP id kltlrckFuF8HNBgE (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Jan 2016 01:07:34 -0800 (PST) Date: Wed, 13 Jan 2016 10:07:34 +0100 From: Jan Kara Subject: Re: [PATCH v8 1/9] dax: fix NULL pointer dereference in __dax_dbg() Message-ID: <20160113090734.GC14630@quack.suse.cz> References: <1452230879-18117-1-git-send-email-ross.zwisler@linux.intel.com> <1452230879-18117-2-git-send-email-ross.zwisler@linux.intel.com> <20160112093458.GR6262@quack.suse.cz> <20160113070829.GA30496@linux.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160113070829.GA30496@linux.intel.com> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Ross Zwisler Cc: Jan Kara , Dave Hansen , "J. Bruce Fields" , linux-mm@kvack.org, Andreas Dilger , "H. Peter Anvin" , Jeff Layton , Dan Williams , linux-nvdimm@lists.01.org, x86@kernel.org, Ingo Molnar , Matthew Wilcox , linux-ext4@vger.kernel.org, xfs@oss.sgi.com, Alexander Viro , Thomas Gleixner , Theodore Ts'o , linux-kernel@vger.kernel.org, Jan Kara , linux-fsdevel@vger.kernel.org, Andrew Morton , Matthew Wilcox On Wed 13-01-16 00:08:29, Ross Zwisler wrote: > On Tue, Jan 12, 2016 at 10:34:58AM +0100, Jan Kara wrote: > > On Thu 07-01-16 22:27:51, Ross Zwisler wrote: > > > In __dax_pmd_fault() we currently assume that get_block() will always set > > > bh.b_bdev and we unconditionally dereference it in __dax_dbg(). This > > > assumption isn't always true - when called for reads of holes > > > ext4_dax_mmap_get_block() returns a buffer head where bh->b_bdev is never > > > set. I hit this BUG while testing the DAX PMD fault path. > > > > > > Instead, initialize bh.b_bdev before passing bh into get_block(). It is > > > possible that the filesystem's get_block() will update bh.b_bdev, and this > > > is fine - we just want to initialize bh.b_bdev to something reasonable so > > > that the calls to __dax_dbg() work and print something useful. > > > > > > Signed-off-by: Ross Zwisler > > > Cc: Dan Williams > > > > Looks good. But don't you need to do the same for __dax_fault(), > > dax_zero_page_range() and similar places passing bh to dax functions? > > > > Honza > > I don't think we need it anywhere else. The only reason that we need to > initialize the bh.b_bdev manually in the __dax_pmd_fault() path is that if the > get_block() call ends up finding a hole (so doesn't fill out b_bdev) we still > go through the dax_pmd_dbg() path to print an error message, which uses > b_bdev. I believe that in the other paths where we hit a hole, such as > __dax_fault(), we don't use b_bdev because we don't have the same error path > prints, and the regular code for handling holes doesn't use b_bdev. > > That being said, if you feel like it's cleaner to initialize it > everywhere so everything is consistent and we don't have to worry about > it, I'm fine to make the change. Well, it seems more futureproof to me. In case someone decides to add some debug message later on... Honza -- Jan Kara SUSE Labs, CR _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932272AbcAMJHo (ORCPT ); Wed, 13 Jan 2016 04:07:44 -0500 Received: from mx2.suse.de ([195.135.220.15]:36464 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754474AbcAMJHg (ORCPT ); Wed, 13 Jan 2016 04:07:36 -0500 Date: Wed, 13 Jan 2016 10:07:34 +0100 From: Jan Kara To: Ross Zwisler Cc: Jan Kara , linux-kernel@vger.kernel.org, "H. Peter Anvin" , "J. Bruce Fields" , "Theodore Ts'o" , Alexander Viro , Andreas Dilger , Andrew Morton , Dan Williams , Dave Chinner , Dave Hansen , Ingo Molnar , Jan Kara , Jeff Layton , Matthew Wilcox , Matthew Wilcox , Thomas Gleixner , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@ml01.01.org, x86@kernel.org, xfs@oss.sgi.com Subject: Re: [PATCH v8 1/9] dax: fix NULL pointer dereference in __dax_dbg() Message-ID: <20160113090734.GC14630@quack.suse.cz> References: <1452230879-18117-1-git-send-email-ross.zwisler@linux.intel.com> <1452230879-18117-2-git-send-email-ross.zwisler@linux.intel.com> <20160112093458.GR6262@quack.suse.cz> <20160113070829.GA30496@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160113070829.GA30496@linux.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 13-01-16 00:08:29, Ross Zwisler wrote: > On Tue, Jan 12, 2016 at 10:34:58AM +0100, Jan Kara wrote: > > On Thu 07-01-16 22:27:51, Ross Zwisler wrote: > > > In __dax_pmd_fault() we currently assume that get_block() will always set > > > bh.b_bdev and we unconditionally dereference it in __dax_dbg(). This > > > assumption isn't always true - when called for reads of holes > > > ext4_dax_mmap_get_block() returns a buffer head where bh->b_bdev is never > > > set. I hit this BUG while testing the DAX PMD fault path. > > > > > > Instead, initialize bh.b_bdev before passing bh into get_block(). It is > > > possible that the filesystem's get_block() will update bh.b_bdev, and this > > > is fine - we just want to initialize bh.b_bdev to something reasonable so > > > that the calls to __dax_dbg() work and print something useful. > > > > > > Signed-off-by: Ross Zwisler > > > Cc: Dan Williams > > > > Looks good. But don't you need to do the same for __dax_fault(), > > dax_zero_page_range() and similar places passing bh to dax functions? > > > > Honza > > I don't think we need it anywhere else. The only reason that we need to > initialize the bh.b_bdev manually in the __dax_pmd_fault() path is that if the > get_block() call ends up finding a hole (so doesn't fill out b_bdev) we still > go through the dax_pmd_dbg() path to print an error message, which uses > b_bdev. I believe that in the other paths where we hit a hole, such as > __dax_fault(), we don't use b_bdev because we don't have the same error path > prints, and the regular code for handling holes doesn't use b_bdev. > > That being said, if you feel like it's cleaner to initialize it > everywhere so everything is consistent and we don't have to worry about > it, I'm fine to make the change. Well, it seems more futureproof to me. In case someone decides to add some debug message later on... Honza -- Jan Kara SUSE Labs, CR