On Mon, Mar 21, 2016 at 02:22:45PM +0100, Jan Kara wrote: > [Sorry for repost but I accidentally sent initial email without patches] > > Hello, > > this is my second attempt at DAX page fault locking rewrite. Things now > work reasonably well, it has survived full xfstests run on ext4. I guess > I need to do more mmap targetted tests to unveil issues. Guys what do you > used for DAX testing? I typically use xfstests for regression testing. If we can come up with new generally useful regression tests, especially ones concerning mmap races, that would be awesome. I guess it's just a choice between adding them somewhere in xfstests or somewhere else like with the unit tests in ndctl. > Changes since v1: > - handle wakeups of exclusive waiters properly > - fix cow fault races > - other minor stuff > > General description > > The basic idea is that we use a bit in an exceptional radix tree entry as > a lock bit and use it similarly to how page lock is used for normal faults. > That way we fix races between hole instantiation and read faults of the > same index. For now I have disabled PMD faults since there the issues with > page fault locking are even worse. Now that Matthew's multi-order radix tree > has landed, I can have a look into using that for proper locking of PMD faults > but first I want normal pages sorted out. > > In the end I have decided to implement the bit locking directly in the DAX > code. Originally I was thinking we could provide something generic directly > in the radix tree code but the functions DAX needs are rather specific. > Maybe someone else will have a good idea how to distill some generally useful > functions out of what I've implemented for DAX but for now I didn't bother > with that. > > Honza -- 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
