Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1205450

Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock

From Dave Chinner <david@fromorbit.com>
Newsgroups linux.kernel
Subject Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock
Date 2015-08-11 23:50 +0200
Message-ID <pWpAL-No-31@gated-at.bofh.it> (permalink)
References (2 earlier) <pWcWS-7R8-9@gated-at.bofh.it> <pWeck-17Z-57@gated-at.bofh.it> <pWifT-6UA-3@gated-at.bofh.it> <pWiSC-7UI-23@gated-at.bofh.it> <pWl46-2zU-21@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue, Aug 11, 2015 at 04:51:22PM +0000, Wilcox, Matthew R wrote:
> The race that you're not seeing is page fault vs page fault.  Two
> threads each attempt to store a byte to different locations on the
> same page.  With a read-mutex to exclude truncates, each thread
> calls ->get_block.  One of the threads gets back a buffer marked
> as BH_New and calls memset() to clear the page.  The other thread
> gets back a buffer which isn't marked as BH_New and simply inserts
> the mapping, returning to userspace, which stores the byte ...
> just in time for the other thread's memset() to write a zero over
> the top of it.

So, this is not a truncate race that the XFS MMAPLOCK solves.

However, that doesn't mean that the DAX code needs to add locking to
solve it. The race here is caused by block initialisation being
unserialised after a ->get_block call allocates the block (which the
filesystem serialises via internal locking). Hence two simultaneous
->get_block calls to the same block is guaranteed to have the DAX
block initialisation race with the second ->get_block call that says
the block is already allocated.

IOWs, the way to handle this is to have the ->get_block call handle
the block zeroing for new blocks instead of doing it after the fact
in the generic DAX code where there is no fine-grained serialisation
object available. By calling dax_clear_blocks() in the ->get_block
callback, the filesystem can ensure that the second racing call will
only make progress once the block has been fully initialised by the
first call.

IMO the fix is - again - to move the functionality into the
filesystem where we already have the necessary exclusion in place to
avoid this race condition entirely.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2015-08-10 17:20 +0200
  Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock Jan Kara <jack@suse.cz> - 2015-08-11 10:20 +0200
    Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock Dave Chinner <david@fromorbit.com> - 2015-08-11 11:40 +0200
      Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock Boaz Harrosh <boaz@plexistor.com> - 2015-08-11 13:20 +0200
      Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-08-11 14:10 +0200
      Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock Jan Kara <jack@suse.cz> - 2015-08-11 16:00 +0200
        Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock Boaz Harrosh <boaz@plexistor.com> - 2015-08-11 16:40 +0200
          Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-08-11 17:30 +0200
            Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock Boaz Harrosh <boaz@plexistor.com> - 2015-08-11 18:20 +0200
              Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-08-11 22:30 +0200
                Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock Boaz Harrosh <boaz@plexistor.com> - 2015-08-12 10:00 +0200
          RE: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock "Wilcox, Matthew R" <matthew.r.wilcox@intel.com> - 2015-08-11 19:00 +0200
            Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock Boaz Harrosh <boaz@plexistor.com> - 2015-08-11 20:50 +0200
            Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock Dave Chinner <david@fromorbit.com> - 2015-08-11 23:50 +0200
              Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock Boaz Harrosh <boaz@plexistor.com> - 2015-08-12 11:00 +0200
              Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock Jan Kara <jack@suse.cz> - 2015-08-13 13:40 +0200

csiph-web