From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com ([192.55.52.115]:58814 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S938531AbcJ0Tyw (ORCPT ); Thu, 27 Oct 2016 15:54:52 -0400 Date: Thu, 27 Oct 2016 13:54:49 -0600 From: Ross Zwisler To: Jan Kara Cc: Ross Zwisler , linux-fsdevel@vger.kernel.org, linux-nvdimm@lists.01.org Subject: Re: Infinite loop with DAX PMD faults Message-ID: <20161027195449.GA29643@linux.intel.com> References: <20161027190750.GA28888@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161027190750.GA28888@quack2.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Oct 27, 2016 at 09:07:50PM +0200, Jan Kara wrote: > Hello, > > When testing my DAX patches rebased on top of Ross' DAX PMD series, I've > come across the following issue with generic/344 test from xfstests. The > test ends in an infinite fault loop when we fault index 0 over and over > again never finishing the fault. The problem is that we do a write fault > for index 0 when there is PMD for that index. So we enter wp_huge_pmd(). > For whatever reason that returns VM_FAULT_FALLBACK so we continue to > handle_pte_fault(). There we do > > if (pmd_trans_unstable(vmf->pmd) || pmd_devmap(*vmf->pmd)) > > check which is true - the PMD we have is pmd_trans_huge() - so we 'return > 0' and that results in retrying the fault and all happens from the > beginning again. > > It isn't quite obvious how to break that cycle to me. The comment before > pmd_none_or_trans_huge_or_clear_bad() goes to great lengths explaining > possible races when PMD is pmd_trans_huge() so it needs careful evaluation > what needs to be done for DAX. Ross, any idea? I'll try & reproduce this, and I'll get back to you.