On Tue, Feb 09, 2016 at 06:24:16PM +0100, Jan Kara wrote:
I was thinking about current issues with DAX fault locking  (data
corruption due to racing faults allocating blocks) and also races which
currently don't allow us to clear dirty tags in the radix tree due to races
between faults and cache flushing . Both of these exist because we don't
have an equivalent of page lock available for DAX. While we have a
reasonable solution available for problem , so far I'm not aware of a
decent solution for . After briefly discussing the issue with Mel he had
a bright idea that we could used hashed locks to deal with  (and I think
we can solve  with them as well). So my proposal looks as follows:
DAX will have an array of mutexes (the array can be made per device but
initially a global one should be OK). We will use mutexes in the array as a
replacement for page lock - we will use hashfn(mapping, index) to get
particular mutex protecting our offset in the mapping. On fault / page
mkwrite, we'll grab the mutex similarly to page lock and release it once we
are done updating page tables. This deals with races in . When flushing
caches we grab the mutex before clearing writeable bit in page tables
and clearing dirty bit in the radix tree and drop it after we have flushed
caches for the pfn. This deals with races in .
Overall I think this sounds promising. I think a potential tie-in with the
radix tree would maybe take us in a good direction.
I had another idea of how to solve race #2 that involved sticking a seqlock
around the DAX radix tree + pte_mkwrite() sequence, and on the flushing side
if you noticed that you've raced against a page fault, just leaving the dirty
page tree entry intact.
I *think* this could work - I'd want to bang on it more - but if we have a
general way of handling DAX locking that we can use instead of solving these
issues one-by-one as they come up, that seems like a much better route.