From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754443AbcEQDQn (ORCPT ); Mon, 16 May 2016 23:16:43 -0400 Received: from imap.thunk.org ([74.207.234.97]:60856 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750792AbcEQDQl (ORCPT ); Mon, 16 May 2016 23:16:41 -0400 Date: Mon, 16 May 2016 23:16:31 -0400 From: "Theodore Ts'o" To: Stephen Rothwell Cc: Al Viro , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Christoph Hellwig , Jan Kara Subject: Re: linux-next: manual merge of the vfs tree with the ext4 tree Message-ID: <20160517031631.GT7799@thunk.org> Mail-Followup-To: Theodore Ts'o , Stephen Rothwell , Al Viro , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Christoph Hellwig , Jan Kara References: <20160517102355.4be4af45@canb.auug.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160517102355.4be4af45@canb.auug.org.au> User-Agent: Mutt/1.6.0 (2016-04-01) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 17, 2016 at 10:23:55AM +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the vfs tree got conflicts in: > > fs/ext4/ext4.h > fs/ext4/indirect.c > fs/ext4/inode.c > > between commit: > > 914f82a32d02 ("ext4: refactor direct IO code") > > from the ext4 tree and commit: > > c8b8e32d700f ("direct-io: eliminate the offset argument to ->direct_IO") > > from the vfs tree. > > I fixed it up (hopefully - see below) and can carry the fix as > necessary. This is now fixed as far as linux-next is concerned, but any > non trivial conflicts should be mentioned to your upstream maintainer > when your tree is submitted for merging. Thanks for the heads up. My merge resolution was backwards from yours (because I merged the ext4 tree into vfs tree while you apparently did the reverse), and this resolution was complex enough that I'm waiting for you to publish next-20160517 to make sure you came up with the same final result of fs/ext4/inode.c (minus the f2fs's ext4 crypto merge, which I think Jaeguk is going to be dropping from his tree, but I don't know if that will have happened by next-20160517). I'm kicking off a set of tests to make sure there aren't problems with the resulting merge going beyond the purely syntactic merge resolution. Cheers, - Ted