From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from newverein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 07FFD210DA16F for ; Mon, 6 Aug 2018 08:44:30 -0700 (PDT) Date: Mon, 6 Aug 2018 17:49:43 +0200 From: Christoph Hellwig Subject: Re: [PATCH v4 0/2] ext4: fix DAX dma vs truncate/hole-punch Message-ID: <20180806154943.GA17666@lst.de> References: <20180710191031.17919-1-ross.zwisler@linux.intel.com> <20180711081741.lmr44sp4cmt3f6um@quack2.suse.cz> <20180725222839.GA28304@linux.intel.com> <20180806035550.GE7395@dastard> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180806035550.GE7395@dastard> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dave Chinner Cc: Jan Kara , linux-nvdimm@lists.01.org, darrick.wong@oracle.com, linux-xfs , Ross Zwisler , linux-fsdevel , lczerner@redhat.com, linux-ext4 , Christoph Hellwig List-ID: > > > This allows the direct I/O path to do I/O and raise & lower page->_refcount > > > while we're executing a truncate/hole punch. This leads to us trying to free > > > a page with an elevated refcount. > > I don't see how this is possible in XFS - maybe I'm missing > something, but "direct IO submission during truncate" is not > something that should ever be happening in XFS, DAX or not. The pages involved in a direct I/O are not that of the file that the direct I/O read/write syscalls are called on, but those of the memory regions the direct I/O read/write syscalls operate on. Those pages could be file backed and undergo a truncate at the same time. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from verein.lst.de ([213.95.11.211]:56471 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729724AbeHFRyK (ORCPT ); Mon, 6 Aug 2018 13:54:10 -0400 Date: Mon, 6 Aug 2018 17:49:43 +0200 From: Christoph Hellwig To: Dave Chinner Cc: Ross Zwisler , Jan Kara , linux-nvdimm@lists.01.org, darrick.wong@oracle.com, lczerner@redhat.com, linux-ext4 , Christoph Hellwig , linux-fsdevel , linux-xfs Subject: Re: [PATCH v4 0/2] ext4: fix DAX dma vs truncate/hole-punch Message-ID: <20180806154943.GA17666@lst.de> References: <20180710191031.17919-1-ross.zwisler@linux.intel.com> <20180711081741.lmr44sp4cmt3f6um@quack2.suse.cz> <20180725222839.GA28304@linux.intel.com> <20180806035550.GE7395@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180806035550.GE7395@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > > > This allows the direct I/O path to do I/O and raise & lower page->_refcount > > > while we're executing a truncate/hole punch. This leads to us trying to free > > > a page with an elevated refcount. > > I don't see how this is possible in XFS - maybe I'm missing > something, but "direct IO submission during truncate" is not > something that should ever be happening in XFS, DAX or not. The pages involved in a direct I/O are not that of the file that the direct I/O read/write syscalls are called on, but those of the memory regions the direct I/O read/write syscalls operate on. Those pages could be file backed and undergo a truncate at the same time. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH v4 0/2] ext4: fix DAX dma vs truncate/hole-punch Date: Mon, 6 Aug 2018 17:49:43 +0200 Message-ID: <20180806154943.GA17666@lst.de> References: <20180710191031.17919-1-ross.zwisler@linux.intel.com> <20180711081741.lmr44sp4cmt3f6um@quack2.suse.cz> <20180725222839.GA28304@linux.intel.com> <20180806035550.GE7395@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Jan Kara , linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org, darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, linux-xfs , Ross Zwisler , linux-fsdevel , lczerner-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-ext4 , Christoph Hellwig To: Dave Chinner Return-path: Content-Disposition: inline In-Reply-To: <20180806035550.GE7395@dastard> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" List-Id: linux-ext4.vger.kernel.org > > > This allows the direct I/O path to do I/O and raise & lower page->_refcount > > > while we're executing a truncate/hole punch. This leads to us trying to free > > > a page with an elevated refcount. > > I don't see how this is possible in XFS - maybe I'm missing > something, but "direct IO submission during truncate" is not > something that should ever be happening in XFS, DAX or not. The pages involved in a direct I/O are not that of the file that the direct I/O read/write syscalls are called on, but those of the memory regions the direct I/O read/write syscalls operate on. Those pages could be file backed and undergo a truncate at the same time.