From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:35865 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751185AbeACPqP (ORCPT ); Wed, 3 Jan 2018 10:46:15 -0500 Date: Wed, 3 Jan 2018 16:46:13 +0100 From: Jan Kara Subject: Re: [PATCH v4 08/18] tools/testing/nvdimm: add 'bio_delay' mechanism Message-ID: <20180103154613.GL4911@quack2.suse.cz> References: <151407695916.38751.2866053440557472361.stgit@dwillia2-desk3.amr.corp.intel.com> <151407700353.38751.17609507477918854876.stgit@dwillia2-desk3.amr.corp.intel.com> <20180102214450.GU5858@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: Dan Williams Cc: Dave Chinner , Andrew Morton , Jan Kara , linux-nvdimm@lists.01.org, linux-xfs , linux-fsdevel , Ross Zwisler , Christoph Hellwig On Tue 02-01-18 13:51:49, Dan Williams wrote: > On Tue, Jan 2, 2018 at 1:44 PM, Dave Chinner wrote: > > On Sat, Dec 23, 2017 at 04:56:43PM -0800, Dan Williams wrote: > >> In support of testing truncate colliding with dma add a mechanism that > >> delays the completion of block I/O requests by a programmable number of > >> seconds. This allows a truncate operation to be issued while page > >> references are held for direct-I/O. > >> > >> Signed-off-by: Dan Williams > > > > Why not put this in the generic bio layer code and then write a > > generic fstest to exercise this truncate vs direct IO completion > > race condition on all types of storage and filesystems? > > > > i.e. if it sits in a nvdimm test suite, it's never going to be run > > by filesystem developers.... > > I do want to get it into xfstests eventually. I picked the nvdimm > infrastructure for expediency of getting the fix developed. Also, I > consider the collision in the non-dax case a solved problem since the > core mm will keep the page out of circulation indefinitely. Yes, but there are different races that could happen even for regular page cache pages. So I also think it would be worthwhile to have this inside the block layer possibly as part of the generic fault-injection framework which is already there for fail_make_request. That already supports various filtering, frequency, and other options that could be useful. Honza -- Jan Kara SUSE Labs, CR