From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 55F9E222EDCE0 for ; Wed, 3 Jan 2018 12:32:48 -0800 (PST) From: Jeff Moyer Subject: Re: [PATCH v4 08/18] tools/testing/nvdimm: add 'bio_delay' mechanism References: <151407695916.38751.2866053440557472361.stgit@dwillia2-desk3.amr.corp.intel.com> <151407700353.38751.17609507477918854876.stgit@dwillia2-desk3.amr.corp.intel.com> <20180102214450.GU5858@dastard> <20180103154613.GL4911@quack2.suse.cz> Date: Wed, 03 Jan 2018 15:37:50 -0500 In-Reply-To: <20180103154613.GL4911@quack2.suse.cz> (Jan Kara's message of "Wed, 3 Jan 2018 16:46:13 +0100") Message-ID: MIME-Version: 1.0 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: Jan Kara Cc: linux-nvdimm@lists.01.org, Dave Chinner , Christoph Hellwig , linux-xfs , linux-fsdevel , Andrew Morton List-ID: Jan Kara writes: > 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. Or consider extending the dm-delay target (which delays the queuing of bios) to support delaying the completions. I'm not sure I'm a fan of sticking all sorts of debug code into the generic I/O submission path. Cheers, Jeff _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm