lkml.org 
[lkml]   [2015]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] dax: fix deadlock in __dax_fault
    On Fri, Sep 25, 2015 at 12:23:34PM -0600, Ross Zwisler wrote:
    > On Fri, Sep 25, 2015 at 12:53:57PM +1000, Dave Chinner wrote:
    > <>
    > > We've already got block allocation serialisation at the filesystem
    > > level, and the issue is the unserialised block zeroing being done by
    > > the dax code. That can be fixed by moving the zeroing into the
    > > filesystem code when it runs "complete_unwritten" and checks whether
    > > the mapping has already been marked as written or not...
    > >
    > > I've recently pointed out in a different thread that this is the
    > > solution to whatever that problem was (can't recall which
    > > thread/problem is was now :/ ) and it the same solution here. We
    > > already have the serialisation we need, we just need to move the
    > > block zeroing operation into the appropriate places to make it work
    > > correctly.
    >
    > I think perhaps this is the thread that you're remembering:
    > https://lkml.org/lkml/2015/8/11/731

    Ah, yes, the read vs write fault race condition, whereas this change
    was to address write vs write fault races. And neither of which
    address the fault vs truncate problem properly, either, which is
    what the XFS_MMAP_LOCKING addresses.

    So, yeah, pushing the block zeroing down to the filesystem gets rid
    of multiple problems that concurrent page faults have with
    initialisation without adding any more serialisation or overhead.

    Cheers,

    Dave.
    --
    Dave Chinner
    david@fromorbit.com


    \
     
     \ /
      Last update: 2015-09-26 01:41    [W:3.063 / U:0.408 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site