On Thu, Oct 27, 2016 at 12:07 PM, Jan Kara <jack@xxxxxxx> 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? Can you bisect it with CONFIG_BROKEN removed from older kernels? I remember tracking down something like this when initially doing the pmd support. It ended up being a missed pmd_devmap() check in the fault path, so it may not be the same issue. It would at least be interesting to see if 4.6 fails in a similar manner with this test and FS_DAX_PMD enabled. -- 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
