On Tue, Feb 26, 2019 at 04:08:21AM -0800, Matthew Wilcox wrote: > On Mon, Feb 25, 2019 at 09:03:00PM -0800, Dan Williams wrote: > > On Sat, Feb 16, 2019 at 1:11 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > > > On Sat, Feb 16, 2019 at 09:29:48AM -0800, Matthew Wilcox wrote: > > > > On Sat, Feb 16, 2019 at 07:35:11AM -0800, Matthew Wilcox wrote: > > > > > Another way to fix this would be to mask the address in dax_entry_mkclean(), > > > > > but I think this is cleaner. > > > > > > > > That's clearly rubbish, dax_entry_mkclean() can't possibly mask the > > > > address. It might be mis-aligned in another process. But ... if it's > > > > misaligned in another process, dax_entry_mkclean() will only clean the first > > > > PTE associated with the PMD; it won't clean the whole thing. I think we need > > > > something like this: > > > > > > Nope, this isn't enough. It's _necessary_ to find the processes that > > > have part of this PMD page mapped, but not the start of it. But it's > > > not _sufficient_ because it'll still only mkclean the first PTE. So we > > > need a loop. I'm feeling a bit over my head here. I may have a go at > > > a fuller fix, but if someone else wants to have a go at it, be my guest! > > > > Nothing comes to mind outside of pseudo-reverting this conversion by > > introducing a way to get back to the old semantics. If you don't see a > > path forward, us mere Xarray-mortals stand no chance. > > This is a pre-existing bug. Fixing the regression is easy. To be clear; I sent the regression fix a week ago in 20190216153511.GM12668@xxxxxxxxxxxxxxxxxxxxxx I haven't tested it; I don't have a suitable setup right now. The pre-existing bug is that if you have two tasks with the same address range mapped, but one has it mapped with a PMD and the other has it mapped with PTEs (maybe due to mapping only a subset of the addresses), dax_entry_mkclean() won't clean the PTEs because vma_interval_tree_foreach() won't find the VMA.
