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

Groups > linux.kernel > #1480203 > unrolled thread

Re: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Ross Zwisler <ross.zwisler@linux.intel.com> - 2016-09-09 18:50 +0200
    RE: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Matthew Wilcox <mawilcox@microsoft.com> - 2016-09-09 22:40 +0200
      Re: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Dan Williams <dan.j.williams@intel.com> - 2016-09-10 00:40 +0200
        Re: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Christoph Hellwig <hch@infradead.org> - 2016-09-10 09:40 +0200
          RE: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Matthew Wilcox <mawilcox@microsoft.com> - 2016-09-10 10:00 +0200
          Re: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Theodore Ts'o <tytso@mit.edu> - 2016-09-10 20:00 +0200
            RE: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Matthew Wilcox <mawilcox@microsoft.com> - 2016-09-11 02:50 +0200
        RE: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Matthew Wilcox <mawilcox@microsoft.com> - 2016-09-10 10:20 +0200
          Re: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Dan Williams <dan.j.williams@intel.com> - 2016-09-10 17:00 +0200
      Re: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Christoph Hellwig <hch@infradead.org> - 2016-09-10 09:40 +0200
        RE: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Matthew Wilcox <mawilcox@microsoft.com> - 2016-09-10 09:40 +0200
          Re: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Christoph Hellwig <hch@infradead.org> - 2016-09-10 09:50 +0200
            RE: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Matthew Wilcox <mawilcox@microsoft.com> - 2016-09-10 10:00 +0200
              Re: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Christoph Hellwig <hch@infradead.org> - 2016-09-11 14:50 +0200
                Re: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Ross Zwisler <ross.zwisler@linux.intel.com> - 2016-09-12 01:00 +0200
        RE: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes Matthew Wilcox <mawilcox@microsoft.com> - 2016-09-10 18:00 +0200

#1480203 — Re: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes

On Mon, Aug 29, 2016 at 08:57:41AM -0400, Theodore Ts'o wrote:
> On Mon, Aug 29, 2016 at 12:41:16AM -0700, Christoph Hellwig wrote:
> > 
> > We're going to move forward killing buffer_heads in XFS.  I think ext4
> > would dramatically benefit from this a well, as would ext2 (although I
> > think all that DAX work in ext2 is a horrible idea to start with).
> 
> It's been on my todo list.  The only reason why I haven't done it yet
> is because I knew you were working on a solution, and I didn't want to
> do things one way for buffered I/O, and a different way for Direct
> I/O, and disentangling the DIO code and the different assumptions of
> how different file systems interact with the DIO code is a *mess*.
> 
> It may have gotten better more recently, but a few years ago I took a
> look at it and backed slowly away.....

Ted, what do you think of the idea of moving to struct iomap in ext2?

If ext2 stays with the current struct buffer_head + get_block_t interface,
then it looks like DAX basically has three options:

1) Support two I/O paths and two versions of each of the fault paths (PTE,
PMD, etc).  One of each of these would be based on struct iomap and would be
used by xfs and potentially ext4, and the other would be based on struct
buffer_head + get_block_t and would be used by ext2.

2) Only have a single struct iomap based I/O path and fault path, and add
shim/support code so that ext2 can use it, leaving the rest of ext2 to be
struct buffer_head + get_block_t based.

3) Only have a single struct buffer_head + get_block_t based DAX I/O and fault
path, and have XFS and potentially ext4 do the translation from their native
struct iomap interface.

It seems ideal for ext2 to switch along with everyone else, if getting rid of
struct buffer_head is a global goal.  If not, I guess barring technical issues
#2 above seems cleanest - move DAX to the new structure, and provide backwards
compatibility to ext2.  Thoughts?

[toc] | [next] | [standalone]

#1480336

I feel like we're not only building on shifting sands, but we haven't decided whether we're building a Pyramid or a Sphinx.

I thought after Storage Summit, we had broad agreement that we were moving to a primary DAX API that was not BH (nor indeed iomap) based.  We would still have DAX helpers for block based filesystems (because duplicating all that code between filesystems is pointless), but I now know of three filesystems which are not block based that are interested in using DAX.  Jared Hulbert's AXFS is a nice public example.

I posted a prototype of this here:

https://groups.google.com/d/msg/linux.kernel/xFFHVCQM7Go/ZQeDVYTnFgAJ

It is, of course, woefully out of date, but some of the principles in it are still good (and I'm working to split it into digestible chunks).

The essence:

1. VFS or VM calls filesystem (eg ->fault()) 
2. Filesystem calls DAX (eg dax_fault()) 
3. DAX looks in radix tree, finds no information. 
4. DAX calls (NEW!) mapping->a_ops->populate_pfns 
5a. Filesystem (if not block based) does its own thing to find out the PFNs corresponding to the requested range, then inserts them into the radix tree (possible helper in DAX code)
5b. Filesystem (if block based) looks up its internal data structure (eg extent tree) and 
   calls dax_create_pfns() (see giant patch from yesterday, only instead of 
   passing a get_block_t, the filesystem has already filled in a bh which 
   describes the entire extent that this access happens to land in). 
6b. DAX takes care of calling bdev_direct_access() from dax_create_pfns().

Now, notice that there's no interaction with the rest of the filesystem here.  We can swap out BHs and iomaps relatively trivially; there's no call for making grand changes, like converting ext2 over to iomap.  The BH or iomap is only used for communicating the extent from the filesystem to DAX.

Do we have agreement that this is the right way to go?

-----Original Message-----
From: Ross Zwisler [mailto:ross.zwisler@linux.intel.com] 
Sent: Friday, September 9, 2016 12:48 PM
To: Theodore Ts'o <tytso@mit.edu>; Christoph Hellwig <hch@infradead.org>; Ross Zwisler <ross.zwisler@linux.intel.com>; linux-kernel@vger.kernel.org; Andrew Morton <akpm@linux-foundation.org>; linux-nvdimm@ml01.01.org; Matthew Wilcox <mawilcox@microsoft.com>; Dave Chinner <david@fromorbit.com>; linux-mm@kvack.org; Andreas Dilger <adilger.kernel@dilger.ca>; Alexander Viro <viro@zeniv.linux.org.uk>; Jan Kara <jack@suse.com>; linux-fsdevel@vger.kernel.org; linux-ext4@vger.kernel.org
Subject: Re: [PATCH v2 2/9] ext2: tell DAX the size of allocation holes

On Mon, Aug 29, 2016 at 08:57:41AM -0400, Theodore Ts'o wrote:
> On Mon, Aug 29, 2016 at 12:41:16AM -0700, Christoph Hellwig wrote:
> > 
> > We're going to move forward killing buffer_heads in XFS.  I think ext4
> > would dramatically benefit from this a well, as would ext2 (although I
> > think all that DAX work in ext2 is a horrible idea to start with).
> 
> It's been on my todo list.  The only reason why I haven't done it yet
> is because I knew you were working on a solution, and I didn't want to
> do things one way for buffered I/O, and a different way for Direct
> I/O, and disentangling the DIO code and the different assumptions of
> how different file systems interact with the DIO code is a *mess*.
> 
> It may have gotten better more recently, but a few years ago I took a
> look at it and backed slowly away.....

Ted, what do you think of the idea of moving to struct iomap in ext2?

If ext2 stays with the current struct buffer_head + get_block_t interface,
then it looks like DAX basically has three options:

1) Support two I/O paths and two versions of each of the fault paths (PTE,
PMD, etc).  One of each of these would be based on struct iomap and would be
used by xfs and potentially ext4, and the other would be based on struct
buffer_head + get_block_t and would be used by ext2.

2) Only have a single struct iomap based I/O path and fault path, and add
shim/support code so that ext2 can use it, leaving the rest of ext2 to be
struct buffer_head + get_block_t based.

3) Only have a single struct buffer_head + get_block_t based DAX I/O and fault
path, and have XFS and potentially ext4 do the translation from their native
struct iomap interface.

It seems ideal for ext2 to switch along with everyone else, if getting rid of
struct buffer_head is a global goal.  If not, I guess barring technical issues
#2 above seems cleanest - move DAX to the new structure, and provide backwards
compatibility to ext2.  Thoughts?

[toc] | [prev] | [next] | [standalone]

#1480418

/me grumbles about top-posting...

On Fri, Sep 9, 2016 at 1:35 PM, Matthew Wilcox <mawilcox@microsoft.com> wrote:
> I feel like we're not only building on shifting sands, but we haven't decided whether we're building a Pyramid or a Sphinx.
>
> I thought after Storage Summit, we had broad agreement that we were moving to a primary DAX API that was not BH (nor indeed iomap) based.  We would still have DAX helpers for block based filesystems (because duplicating all that code between filesystems is pointless), but I now know of three filesystems which are not block based that are interested in using DAX.  Jared Hulbert's AXFS is a nice public example.
>
> I posted a prototype of this here:
>
> https://groups.google.com/d/msg/linux.kernel/xFFHVCQM7Go/ZQeDVYTnFgAJ
>
> It is, of course, woefully out of date, but some of the principles in it are still good (and I'm working to split it into digestible chunks).
>
> The essence:
>
> 1. VFS or VM calls filesystem (eg ->fault())
> 2. Filesystem calls DAX (eg dax_fault())
> 3. DAX looks in radix tree, finds no information.
> 4. DAX calls (NEW!) mapping->a_ops->populate_pfns
> 5a. Filesystem (if not block based) does its own thing to find out the PFNs corresponding to the requested range, then inserts them into the radix tree (possible helper in DAX code)
> 5b. Filesystem (if block based) looks up its internal data structure (eg extent tree) and
>    calls dax_create_pfns() (see giant patch from yesterday, only instead of
>    passing a get_block_t, the filesystem has already filled in a bh which
>    describes the entire extent that this access happens to land in).
> 6b. DAX takes care of calling bdev_direct_access() from dax_create_pfns().
>
> Now, notice that there's no interaction with the rest of the filesystem here.  We can swap out BHs and iomaps relatively trivially; there's no call for making grand changes, like converting ext2 over to iomap.  The BH or iomap is only used for communicating the extent from the filesystem to DAX.
>
> Do we have agreement that this is the right way to go?

My $0.02...

So the current dax implementation is still struggling to get right
(pmd faulting, dirty entry cleaning, etc) and this seems like a
rewrite that sets us up for future features without addressing the
current bugs and todo items.  In comparison the iomap conversion work
seems incremental and conserving of current development momentum.

I agree with you that continuing to touch ext2 is not a good idea, but
I'm not yet convinced that now is the time to go do dax-2.0 when we
haven't finished shipping dax-1.0.

[toc] | [prev] | [next] | [standalone]

#1480525

On Fri, Sep 09, 2016 at 03:34:43PM -0700, Dan Williams wrote:
> I agree with you that continuing to touch ext2 is not a good idea, but
> I'm not yet convinced that now is the time to go do dax-2.0 when we
> haven't finished shipping dax-1.0.

I've mentioned this before, but I'd like to repeat it.  With all the
work reqwuired in the file system I would prefer to drop DAX support
in ext2 (and if people really cry for it reinstate the trivial old xip
support).

[toc] | [prev] | [next] | [standalone]

#1480530

From: Christoph Hellwig [mailto:hch@infradead.org]
> On Fri, Sep 09, 2016 at 03:34:43PM -0700, Dan Williams wrote:
> > I agree with you that continuing to touch ext2 is not a good idea, but
> > I'm not yet convinced that now is the time to go do dax-2.0 when we
> > haven't finished shipping dax-1.0.
> 
> I've mentioned this before, but I'd like to repeat it.  With all the work reqwuired
> in the file system I would prefer to drop DAX support in ext2 (and if people
> really cry for it reinstate the trivial old xip support).

That allegedly trivial old xip support was horrendously broken.  And, er, it used an aop
which you seem implacably opposed to in your earlier email.  And that was truly a
disgusting one from a layering point of view.  Let me remind you:

-       int (*get_xip_mem)(struct address_space *, pgoff_t, int,
-                                               void **, unsigned long *);

That void ** was an 'out' parameter to store a kernel address for the memory.  The
unsigned long * was also an 'out' parameter to store the PFN for the memory.  The
'int' was actually a Boolean for whether to create or not, but you'd actually have to
go look at the implementation to find that out; the documentation never said it.  A
real dog's breakfast of an API.

[toc] | [prev] | [next] | [standalone]

#1480690

On Sat, Sep 10, 2016 at 12:31:51AM -0700, Christoph Hellwig wrote:
> I've mentioned this before, but I'd like to repeat it.  With all the
> work reqwuired in the file system I would prefer to drop DAX support
> in ext2 (and if people really cry for it reinstate the trivial old xip
> support).

Why is so much work required to support the new DAX interfaces in
ext2?  Is that unique to ext2, or is adding DAX support just going to
be painful for all file systems?  Hopefully it's not the latter,
right?

						- Ted

[toc] | [prev] | [next] | [standalone]

#1480725

From: Theodore Ts'o [mailto:tytso@mit.edu]
> On Sat, Sep 10, 2016 at 12:31:51AM -0700, Christoph Hellwig wrote:
> > I've mentioned this before, but I'd like to repeat it.  With all the
> > work reqwuired in the file system I would prefer to drop DAX support
> > in ext2 (and if people really cry for it reinstate the trivial old xip
> > support).
> 
> Why is so much work required to support the new DAX interfaces in
> ext2?  Is that unique to ext2, or is adding DAX support just going to
> be painful for all file systems?  Hopefully it's not the latter,
> right?

It's always been my goal to make supporting DAX as easy as possible
for the filesystem.  Hence the sharing of the DIO locking, and the (it
turned out) premature reliance on helper functions.  It's more complex
than I wanted it to be right now, and I hope we get to simplify it again.

[toc] | [prev] | [next] | [standalone]

#1480533

From: Dan Williams [mailto:dan.j.williams@intel.com]
> /me grumbles about top-posting...

Let's see if this does any better .. there's lots of new features, but I don't see a 'wrap lines at 80 columns' option.  Unfortunately.

> On Fri, Sep 9, 2016 at 1:35 PM, Matthew Wilcox <mawilcox@microsoft.com>
> wrote:
> > I thought after Storage Summit, we had broad agreement that we were
> > moving to a primary DAX API that was not BH (nor indeed iomap) based.  We
> > would still have DAX helpers for block based filesystems (because duplicating
> > all that code between filesystems is pointless), but I now know of three
> > filesystems which are not block based that are interested in using DAX.  Jared
> > Hulbert's AXFS is a nice public example.
> >
> > I posted a prototype of this here:
> >
> >
> https://groups.google.com/d/msg/linux.kernel/xFFHVCQM7Go/ZQeDVYTnFgAJ
> >
> > It is, of course, woefully out of date, but some of the principles in it are still
> good (and I'm working to split it into digestible chunks).
> >
> > The essence:
> >
> > 1. VFS or VM calls filesystem (eg ->fault()) 2. Filesystem calls DAX
> > (eg dax_fault()) 3. DAX looks in radix tree, finds no information.
> > 4. DAX calls (NEW!) mapping->a_ops->populate_pfns 5a. Filesystem (if
> > not block based) does its own thing to find out the PFNs corresponding
> > to the requested range, then inserts them into the radix tree (possible helper
> in DAX code) 5b. Filesystem (if block based) looks up its internal data structure
> (eg extent tree) and
> >    calls dax_create_pfns() (see giant patch from yesterday, only instead of
> >    passing a get_block_t, the filesystem has already filled in a bh which
> >    describes the entire extent that this access happens to land in).
> > 6b. DAX takes care of calling bdev_direct_access() from dax_create_pfns().
> >
> > Now, notice that there's no interaction with the rest of the filesystem here.
> We can swap out BHs and iomaps relatively trivially; there's no call for making
> grand changes, like converting ext2 over to iomap.  The BH or iomap is only
> used for communicating the extent from the filesystem to DAX.
> >
> > Do we have agreement that this is the right way to go?
> 
> My $0.02...
> 
> So the current dax implementation is still struggling to get right (pmd faulting,
> dirty entry cleaning, etc) and this seems like a rewrite that sets us up for future
> features without addressing the current bugs and todo items.  In comparison
> the iomap conversion work seems incremental and conserving of current
> development momentum.

I believe your assessment is incorrect.  If converting the current DAX code to
use iomap forces converting ext2, then it's time to get rid of all the half-measures
currently in place.  You left off one todo item that this does get us a step closer to
fixing -- support for DMA to mmaped DAX files.  I think it also puts us in a better
position to fix the 2MB support, locking, and dirtiness tracking.  Oh, and it does
fix the multivolume support (because the sectors in the radix tree could be
interpreted as being from the wrong volume).

> I agree with you that continuing to touch ext2 is not a good idea, but I'm not
> yet convinced that now is the time to go do dax-2.0 when we haven't finished
> shipping dax-1.0.

dax-1.0 died long ago ... I think we're up to at least DAX version 4 by now.

[toc] | [prev] | [next] | [standalone]

#1480646

On Sat, Sep 10, 2016 at 1:15 AM, Matthew Wilcox <mawilcox@microsoft.com> wrote:
> From: Dan Williams [mailto:dan.j.williams@intel.com]
>> /me grumbles about top-posting...
>
> Let's see if this does any better .. there's lots of new features, but I don't see a 'wrap lines at 80 columns' option.  Unfortunately.

Much appreciated.

[..]
>> So the current dax implementation is still struggling to get right (pmd faulting,
>> dirty entry cleaning, etc) and this seems like a rewrite that sets us up for future
>> features without addressing the current bugs and todo items.  In comparison
>> the iomap conversion work seems incremental and conserving of current
>> development momentum.
>
> I believe your assessment is incorrect.  If converting the current DAX code to
> use iomap forces converting ext2, then it's time to get rid of all the half-measures
> currently in place.  You left off one todo item that this does get us a step closer to
> fixing -- support for DMA to mmaped DAX files.

I didn't leave that off, DMA is solved with devm_memremap_pages().
Now, DMA without the ~1.6% capacity tax for the memmap array is
interesting, but that's a new feature.

> I think it also puts us in a better
> position to fix the 2MB support, locking, and dirtiness tracking.  Oh, and it does
> fix the multivolume support (because the sectors in the radix tree could be
> interpreted as being from the wrong volume).
>
>> I agree with you that continuing to touch ext2 is not a good idea, but I'm not
>> yet convinced that now is the time to go do dax-2.0 when we haven't finished
>> shipping dax-1.0.
>
> dax-1.0 died long ago ... I think we're up to at least DAX version 4 by now.

My point is that I want to address the current slate of problems
before solving new questions like "how do we support non-block based
filesystems?".  We just happened to land DAX in the middle of the
in-progress buffer_head removal effort, so DAX should not stand in the
way of where filesystems were already going.  I'm arguing to complete
all the false starts and half measures that are presently in DAX and
then look to incrementally evolve the interfaces to something new
without regressing any of it.

[toc] | [prev] | [next] | [standalone]

#1480526

The mail is basically unparsable (hint: you can use a sane mailer even
with exchange servers :)).

Either way we need to get rid of buffer_heads, and another aop that
is entirely caller specific is unaceptable.  That being said your idea
doesn't sounds unreasonable, but will require a bit more work and has
no real short-term need.

So let's revisit the idea once you have patches to post and move forward
with the more urgent needs for now.

[toc] | [prev] | [next] | [standalone]

#1480527

From: Christoph Hellwig [mailto:hch@infradead.org]
> The mail is basically unparsable (hint: you can use a sane mailer even with
> exchange servers :)).

That rather depends on how the Exchange servers are configured ... this isn't the
appropriate place to discuss IT issues though.

> Either way we need to get rid of buffer_heads, and another aop that is entirely
> caller specific is unaceptable.  That being said your idea doesn't sounds
> unreasonable, but will require a bit more work and has no real short-term
> need.

So your proposal is to remove buffer_heads from ext2?

[toc] | [prev] | [next] | [standalone]

#1480529

On Sat, Sep 10, 2016 at 07:33:18AM +0000, Matthew Wilcox wrote:
> > caller specific is unaceptable.  That being said your idea doesn't sounds
> > unreasonable, but will require a bit more work and has no real short-term
> > need.
> 
> So your proposal is to remove buffer_heads from ext2?

No, the proposal is to remove buffer_heads from XFS first, then GFS2
and then maybe others like ext4.  I'd like to remove buffer_heads from
the DAX path for ext2 and ext4 entitrely for sure (and direct I/O next).

[toc] | [prev] | [next] | [standalone]

#1480531

From: Christoph Hellwig [mailto:hch@infradead.org]
> On Sat, Sep 10, 2016 at 07:33:18AM +0000, Matthew Wilcox wrote:
> > > caller specific is unaceptable.  That being said your idea doesn't
> > > sounds unreasonable, but will require a bit more work and has no
> > > real short-term need.
> >
> > So your proposal is to remove buffer_heads from ext2?
> 
> No, the proposal is to remove buffer_heads from XFS first, then GFS2 and then
> maybe others like ext4.  I'd like to remove buffer_heads from the DAX path for
> ext2 and ext4 entitrely for sure (and direct I/O next).

That's ... what I propose.  The only use of buffer_head in my proposal is to
communicate a single extent from the filesystem to the DAX core, and that
can equally well use an iomap.  Ross seems to think that converting the current
DAX code over to using iomap requires converting all of ext2 away from
buffer_head; are you saying he's wrong?

[toc] | [prev] | [next] | [standalone]

#1480780

On Sat, Sep 10, 2016 at 07:52:53AM +0000, Matthew Wilcox wrote:
> DAX code over to using iomap requires converting all of ext2 away from
> buffer_head; are you saying he's wrong?

Not sure if he's really saying that, but it's wrong for sure.  Just
to prove that I came up with a working ext2 iomap DAX implementation
in a few hours today.  I'll take a stab at ext4 and the block device
as well and will post the updated series early next week - I'll need
to take care of a few high priority todo list items first.

[toc] | [prev] | [next] | [standalone]

#1480868

On Sun, Sep 11, 2016 at 05:47:41AM -0700, Christoph Hellwig wrote:
> On Sat, Sep 10, 2016 at 07:52:53AM +0000, Matthew Wilcox wrote:
> > DAX code over to using iomap requires converting all of ext2 away from
> > buffer_head; are you saying he's wrong?
> 
> Not sure if he's really saying that, but it's wrong for sure.  Just
> to prove that I came up with a working ext2 iomap DAX implementation
> in a few hours today.  I'll take a stab at ext4 and the block device
> as well and will post the updated series early next week - I'll need
> to take care of a few high priority todo list items first.

Yay!  Sorry if I was unclear, I wasn't trying to say that we had to change all
of ext2 over to using struct iomap.  If we can (and apparently we can) just
switch over the DAX interfaces, that's good enough to me.  I understand that
this will mean that we may have overlapping DAX paths for a while (an iomap
version and a buffer_head version).  I just wanted to figure out whether this
overlap would need to be permanent - sounds like not, which is ideal.

[toc] | [prev] | [next] | [standalone]

#1480656

From: Christoph Hellwig [mailto:hch@infradead.org]
> Either way we need to get rid of buffer_heads, and another aop that is entirely
> caller specific is unaceptable.

I finally figured out what you actually meant by this.  You mean that instead of having an aop->populate_pfn, you want to define a populate_pfn_t callback and pass it in.

Something like this:

int ext2_populate_pfn(struct address_space *mapping, pgoff_t pgoff)
{
	struct iomap iomap;
	...
	return dax_populate_pfn(mapping, pgoff, &iomap);
}

int ext2_dax_fault(vma, vmf)
{
	...
	ret = dax_fault(vma, vmf, ext2_populate_pfn);
	...
}

I don't have a problem with that.  I'll work up something along those lines next week.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web