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.