All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: torvalds@linux-foundation.org, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [GIT PULL] xfs: updates for 4.6-rc1
Date: Mon, 21 Mar 2016 14:34:14 -0400	[thread overview]
Message-ID: <20160321183414.GB3490@thunk.org> (raw)
In-Reply-To: <20160321091628.GE30819@quack.suse.cz>

Thanks Jan, for checking the merge.

I didn't realize the ext4 fixups were going in via the xfs tree.  I
didn't see any merge conflicts from the linux-next tree (or maybe I
missed it) so I had assumed it wasn't in Dave's xfs.git tree.  My plan
had been to deal with it after the prereq patch went in via the xfs
tree --- in fact I was thinking about checking to see if the xfs.git
tree had been merged so I could get the ext4 commit merged and sent to
Linus.

Sorry I lost track of things.  If I had known I would have indeed
manually merged in the branch, resolved the merge, and done a
regression test cycle before pushing to Linus.

						- Ted
						
On Mon, Mar 21, 2016 at 10:16:28AM +0100, Jan Kara wrote:
> On Mon 21-03-16 13:05:05, Dave Chinner wrote:
> The resolution of conflict in fs/ext4/inode.c is fine except for one minor
> issue:
> 
> > diff --cc fs/ext4/inode.c
> > index b2e9576,2b98171..e5ba3b0
> > --- a/fs/ext4/inode.c
> > +++ b/fs/ext4/inode.c
> > @@@ -3289,10 -3161,10 +3289,10 @@@ out
> >   }
> >   #endif
> >   
> > - static void ext4_end_io_dio(struct kiocb *iocb, loff_t offset,
> > + static int ext4_end_io_dio(struct kiocb *iocb, loff_t offset,
> >   			    ssize_t size, void *private)
> >   {
> >  -        ext4_io_end_t *io_end = iocb->private;
> >  +        ext4_io_end_t *io_end = private;
> >   
> >   	/* if not async direct IO just return */
> >   	if (!io_end)
> > @@@ -3300,8 -3172,18 +3300,17 @@@
> >   
> >   	ext_debug("ext4_end_io_dio(): io_end 0x%p "
> >   		  "for inode %lu, iocb 0x%p, offset %llu, size %zd\n",
> >  - 		  iocb->private, io_end->inode->i_ino, iocb, offset,
> >  -		  size);
> >  +		  io_end, io_end->inode->i_ino, iocb, offset, size);
> >   
> > + 	iocb->private = NULL;
> 
> The line above should not exist in the result. It does no harm but is
> unnecessary.
> 
> 								Honza
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR

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

WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Ts'o" <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: Dave Chinner <david@fromorbit.com>,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [GIT PULL] xfs: updates for 4.6-rc1
Date: Mon, 21 Mar 2016 14:34:14 -0400	[thread overview]
Message-ID: <20160321183414.GB3490@thunk.org> (raw)
In-Reply-To: <20160321091628.GE30819@quack.suse.cz>

Thanks Jan, for checking the merge.

I didn't realize the ext4 fixups were going in via the xfs tree.  I
didn't see any merge conflicts from the linux-next tree (or maybe I
missed it) so I had assumed it wasn't in Dave's xfs.git tree.  My plan
had been to deal with it after the prereq patch went in via the xfs
tree --- in fact I was thinking about checking to see if the xfs.git
tree had been merged so I could get the ext4 commit merged and sent to
Linus.

Sorry I lost track of things.  If I had known I would have indeed
manually merged in the branch, resolved the merge, and done a
regression test cycle before pushing to Linus.

						- Ted
						
On Mon, Mar 21, 2016 at 10:16:28AM +0100, Jan Kara wrote:
> On Mon 21-03-16 13:05:05, Dave Chinner wrote:
> The resolution of conflict in fs/ext4/inode.c is fine except for one minor
> issue:
> 
> > diff --cc fs/ext4/inode.c
> > index b2e9576,2b98171..e5ba3b0
> > --- a/fs/ext4/inode.c
> > +++ b/fs/ext4/inode.c
> > @@@ -3289,10 -3161,10 +3289,10 @@@ out
> >   }
> >   #endif
> >   
> > - static void ext4_end_io_dio(struct kiocb *iocb, loff_t offset,
> > + static int ext4_end_io_dio(struct kiocb *iocb, loff_t offset,
> >   			    ssize_t size, void *private)
> >   {
> >  -        ext4_io_end_t *io_end = iocb->private;
> >  +        ext4_io_end_t *io_end = private;
> >   
> >   	/* if not async direct IO just return */
> >   	if (!io_end)
> > @@@ -3300,8 -3172,18 +3300,17 @@@
> >   
> >   	ext_debug("ext4_end_io_dio(): io_end 0x%p "
> >   		  "for inode %lu, iocb 0x%p, offset %llu, size %zd\n",
> >  - 		  iocb->private, io_end->inode->i_ino, iocb, offset,
> >  -		  size);
> >  +		  io_end, io_end->inode->i_ino, iocb, offset, size);
> >   
> > + 	iocb->private = NULL;
> 
> The line above should not exist in the result. It does no harm but is
> unnecessary.
> 
> 								Honza
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR

  reply	other threads:[~2016-03-21 18:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-21  2:05 [GIT PULL] xfs: updates for 4.6-rc1 Dave Chinner
2016-03-21  2:05 ` Dave Chinner
2016-03-21  9:16 ` Jan Kara
2016-03-21  9:16   ` Jan Kara
2016-03-21 18:34   ` Theodore Ts'o [this message]
2016-03-21 18:34     ` Theodore Ts'o
2016-03-21 18:59 ` Linus Torvalds
2016-03-21 18:59   ` Linus Torvalds
2016-03-21 22:40   ` Dave Chinner
2016-03-21 22:40     ` 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=20160321183414.GB3490@thunk.org \
    --to=tytso@mit.edu \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --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.