On Fri, Oct 28, 2016 at 10:02:36AM +0200, Jan Kara wrote:
> On Thu 27-10-16 13:54:49, Ross Zwisler wrote:
> > On Thu, Oct 27, 2016 at 09:07:50PM +0200, Jan Kara wrote:
> > > 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.
>
> For me it happened with ext4 which returned VM_FAULT_FALLBACK from its
> pmd_fault handler on write fault (likely we were not able to allocate
> sufficiently large contiguous hunk). So I'm not sure you will be able to
> easily reproduce just with your series. However tweaking XFS to return
> VM_FAULT_FALLBACK when FAULT_FLAG_WRITE is set should do the trick.
I was able to reproduce it with XFS, with just my series.
The fallback check that's failing for me is this one:
if (pfn_t_to_pfn(dax.pfn) & PG_PMD_COLOUR)
in dax_pmd_insert_mapping().
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
