All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org, willy@linux.intel.com, xfs@oss.sgi.com
Subject: Re: [PATCH 1/6] dax: don't abuse get_block mapping for endio callbacks
Date: Thu, 5 Mar 2015 09:29:35 +1100	[thread overview]
Message-ID: <20150304222935.GY18360@dastard> (raw)
In-Reply-To: <20150304155408.GA2799@quack.suse.cz>

On Wed, Mar 04, 2015 at 04:54:08PM +0100, Jan Kara wrote:
> On Wed 04-03-15 10:30:22, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> > @@ -269,7 +269,8 @@ static int copy_user_bh(struct page *to, struct buffer_head *bh,
> >  }
> >  
> >  static int dax_insert_mapping(struct inode *inode, struct buffer_head *bh,
> > -			struct vm_area_struct *vma, struct vm_fault *vmf)
> > +			struct vm_area_struct *vma, struct vm_fault *vmf,
> > +			dax_iodone_t complete_unwritten)
> >  {
> >  	struct address_space *mapping = inode->i_mapping;
> >  	sector_t sector = bh->b_blocknr << (inode->i_blkbits - 9);
> > @@ -310,14 +311,14 @@ static int dax_insert_mapping(struct inode *inode, struct buffer_head *bh,
> >   out:
> >  	i_mmap_unlock_read(mapping);
> >  
> > -	if (bh->b_end_io)
> > -		bh->b_end_io(bh, 1);
> > +	if (buffer_unwritten(bh))
> > +		complete_unwritten(bh, 1);
> >  
> >  	return error;
> >  }
>   So frankly I don't see a big point in passing completion callback into
> dax_insert_mapping() only to call the function at the end of it. We could
> as well call the completion function from do_dax_fault() where it would
> seem more natural to me. But I don't feel too strongly about this.

On further review, I think the code is incorrect as is, even without
this change - we shouldn't be running unwritten extent conversion
if the block zeroing failed. So this needs fixing anyway. I'll pull
the completion back to do_dax_fault(), where it willonly be run if
there was no error inserting the mapping.

> Instead of the above I was also thinking about some way to pass information
> out of do_dax_fault() into filesystem so that it could just call completion
> handler itself but the completion callback is more standard interface I
> guess.

That seems unbalanced to me, as internal mapping state would need to
be leaked back out to the caller so they could run conversion. I
think it's cleaner to pass in the callback and leave all that
mapping state internal to do_dax_fault()....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Jan Kara <jack@suse.cz>
Cc: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, willy@linux.intel.com
Subject: Re: [PATCH 1/6] dax: don't abuse get_block mapping for endio callbacks
Date: Thu, 5 Mar 2015 09:29:35 +1100	[thread overview]
Message-ID: <20150304222935.GY18360@dastard> (raw)
In-Reply-To: <20150304155408.GA2799@quack.suse.cz>

On Wed, Mar 04, 2015 at 04:54:08PM +0100, Jan Kara wrote:
> On Wed 04-03-15 10:30:22, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> > @@ -269,7 +269,8 @@ static int copy_user_bh(struct page *to, struct buffer_head *bh,
> >  }
> >  
> >  static int dax_insert_mapping(struct inode *inode, struct buffer_head *bh,
> > -			struct vm_area_struct *vma, struct vm_fault *vmf)
> > +			struct vm_area_struct *vma, struct vm_fault *vmf,
> > +			dax_iodone_t complete_unwritten)
> >  {
> >  	struct address_space *mapping = inode->i_mapping;
> >  	sector_t sector = bh->b_blocknr << (inode->i_blkbits - 9);
> > @@ -310,14 +311,14 @@ static int dax_insert_mapping(struct inode *inode, struct buffer_head *bh,
> >   out:
> >  	i_mmap_unlock_read(mapping);
> >  
> > -	if (bh->b_end_io)
> > -		bh->b_end_io(bh, 1);
> > +	if (buffer_unwritten(bh))
> > +		complete_unwritten(bh, 1);
> >  
> >  	return error;
> >  }
>   So frankly I don't see a big point in passing completion callback into
> dax_insert_mapping() only to call the function at the end of it. We could
> as well call the completion function from do_dax_fault() where it would
> seem more natural to me. But I don't feel too strongly about this.

On further review, I think the code is incorrect as is, even without
this change - we shouldn't be running unwritten extent conversion
if the block zeroing failed. So this needs fixing anyway. I'll pull
the completion back to do_dax_fault(), where it willonly be run if
there was no error inserting the mapping.

> Instead of the above I was also thinking about some way to pass information
> out of do_dax_fault() into filesystem so that it could just call completion
> handler itself but the completion callback is more standard interface I
> guess.

That seems unbalanced to me, as internal mapping state would need to
be leaked back out to the caller so they could run conversion. I
think it's cleaner to pass in the callback and leave all that
mapping state internal to do_dax_fault()....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2015-03-04 22:29 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-03 23:30 [RFC PATCH 0/6] xfs: DAX support Dave Chinner
2015-03-03 23:30 ` Dave Chinner
2015-03-03 23:30 ` [PATCH 1/6] dax: don't abuse get_block mapping for endio callbacks Dave Chinner
2015-03-03 23:30   ` Dave Chinner
2015-03-04 15:54   ` Jan Kara
2015-03-04 15:54     ` Jan Kara
2015-03-04 22:29     ` Dave Chinner [this message]
2015-03-04 22:29       ` Dave Chinner
2015-03-03 23:30 ` [PATCH 2/6] xfs: add DAX block zeroing support Dave Chinner
2015-03-03 23:30   ` Dave Chinner
2015-03-03 23:30 ` [PATCH 3/6] xfs: add DAX file operations support Dave Chinner
2015-03-03 23:30   ` Dave Chinner
2015-03-04 10:09   ` Boaz Harrosh
2015-03-04 10:09     ` Boaz Harrosh
2015-03-04 13:01     ` Dave Chinner
2015-03-04 13:01       ` Dave Chinner
2015-03-04 14:54       ` Boaz Harrosh
2015-03-04 14:54         ` Boaz Harrosh
2015-03-04 22:03         ` Dave Chinner
2015-03-04 22:03           ` Dave Chinner
2015-03-24  4:27           ` Dave Chinner
2015-03-24  4:27             ` Dave Chinner
2015-03-24  7:01             ` Christoph Hellwig
2015-03-24  7:01               ` Christoph Hellwig
2015-03-24  8:13             ` Boaz Harrosh
2015-03-24  8:13               ` Boaz Harrosh
2015-03-04 16:18   ` Jan Kara
2015-03-04 16:18     ` Jan Kara
2015-03-04 22:00     ` Dave Chinner
2015-03-04 22:00       ` Dave Chinner
2015-03-05 11:05       ` Jan Kara
2015-03-05 11:05         ` Jan Kara
2015-03-22 23:02         ` Dave Chinner
2015-03-22 23:02           ` Dave Chinner
2015-03-03 23:30 ` [PATCH 4/6] xfs: add DAX truncate support Dave Chinner
2015-03-03 23:30   ` Dave Chinner
2015-03-03 23:30 ` [PATCH 5/6] xfs: add DAX IO path support Dave Chinner
2015-03-03 23:30   ` Dave Chinner
2015-03-03 23:30 ` [PATCH 6/6] xfs: add initial DAX support Dave Chinner
2015-03-03 23:30   ` Dave Chinner

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=20150304222935.GY18360@dastard \
    --to=david@fromorbit.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=willy@linux.intel.com \
    --cc=xfs@oss.sgi.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.