All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Matthew Wilcox <willy@linux.intel.com>,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	linux-nvdimm@lists.01.org
Subject: Re: [PATCH] dax: fix deadlock in __dax_fault
Date: Sat, 26 Sep 2015 09:30:08 +1000	[thread overview]
Message-ID: <20150925233008.GV3902@dastard> (raw)
In-Reply-To: <20150925182334.GA26544@linux.intel.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Matthew Wilcox <willy@linux.intel.com>,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	linux-nvdimm@ml01.01.org
Subject: Re: [PATCH] dax: fix deadlock in __dax_fault
Date: Sat, 26 Sep 2015 09:30:08 +1000	[thread overview]
Message-ID: <20150925233008.GV3902@dastard> (raw)
In-Reply-To: <20150925182334.GA26544@linux.intel.com>

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

  reply	other threads:[~2015-09-25 23:30 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-23 20:40 [PATCH] dax: fix deadlock in __dax_fault Ross Zwisler
2015-09-23 20:40 ` Ross Zwisler
2015-09-24  2:52 ` Dave Chinner
2015-09-24  2:52   ` Dave Chinner
2015-09-24  9:03   ` Boaz Harrosh
2015-09-24  9:03     ` Boaz Harrosh
2015-09-24 15:50   ` Ross Zwisler
2015-09-24 15:50     ` Ross Zwisler
2015-09-25  2:53     ` Dave Chinner
2015-09-25  2:53       ` Dave Chinner
2015-09-25 18:23       ` Ross Zwisler
2015-09-25 18:23         ` Ross Zwisler
2015-09-25 23:30         ` Dave Chinner [this message]
2015-09-25 23:30           ` Dave Chinner
2015-09-26  3:17       ` Ross Zwisler
2015-09-26  3:17         ` Ross Zwisler
2015-09-28  0:59         ` Dave Chinner
2015-09-28  0:59           ` Dave Chinner
2015-09-28 10:12           ` Dave Chinner
2015-09-28 10:12             ` Dave Chinner
2015-09-28 10:23             ` kbuild test robot
2015-09-28 10:23               ` kbuild test robot
2015-09-28 10:23             ` kbuild test robot
2015-09-28 10:23               ` kbuild test robot
2015-09-28 12:13           ` Dan Williams
2015-09-28 12:13             ` Dan Williams
2015-09-28 21:35             ` Dave Chinner
2015-09-28 21:35               ` Dave Chinner
2015-09-28 22:57               ` Dan Williams
2015-09-28 22:57                 ` Dan Williams
2015-09-29  2:18                 ` Dave Chinner
2015-09-29  2:18                   ` Dave Chinner
2015-09-29  3:08                   ` Dan Williams
2015-09-29  3:08                     ` Dan Williams
2015-09-29  4:19                     ` Dave Chinner
2015-09-29  4:19                       ` Dave Chinner
2015-09-28 22:40           ` Ross Zwisler
2015-09-28 22:40             ` Ross Zwisler
2015-09-29  2:44             ` Dave Chinner
2015-09-29  2:44               ` Dave Chinner
2015-09-30  1:57               ` Dave Chinner
2015-09-30  1:57                 ` Dave Chinner
2015-09-30  2:04               ` Ross Zwisler
2015-09-30  2:04                 ` Ross Zwisler
2015-09-30  2:04                 ` Ross Zwisler
2015-09-30  3:22                 ` Dave Chinner
2015-09-30  3:22                   ` Dave Chinner
2015-10-02 12:55                 ` Jan Kara
2015-10-02 12:55                   ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150925233008.GV3902@dastard \
    --to=david@fromorbit.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=ross.zwisler@linux.intel.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.