linux-kernel - Re: linux-next: manual merge of the xfs tree with Linus' tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 5 Jun 2018 10:38:23 +1000
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     "Darrick J. Wong" <darrick.wong@...cle.com>,
        David Chinner <david@...morbit.com>, linux-xfs@...r.kernel.org
Cc:     Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andreas Gruenbacher <agruenba@...hat.com>,
        Bob Peterson <rpeterso@...hat.com>,
        Christoph Hellwig <hch@....de>
Subject: Re: linux-next: manual merge of the xfs tree with Linus' tree

Hi all,

On Tue, 5 Jun 2018 10:34:03 +1000 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> Today's linux-next merge of the xfs tree got a conflict in:
> 
>   fs/gfs2/bmap.c
> 
> between commit:
> 
>   628e366df11c ("gfs2: Iomap cleanups and improvements")
> 
> from Linus' tree and commit:
> 
>   7ee66c03e40a ("iomap: move IOMAP_F_BOUNDARY to gfs2")
> 
> from the xfs tree.
> 
> I fixed it up (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.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Forgot the diff :-(
-- 
Cheers,
Stephen Rothwell

diff --cc fs/gfs2/bmap.c
index a7b586e02693,8efa6297e19c..000000000000
--- a/fs/gfs2/bmap.c
+++ b/fs/gfs2/bmap.c
@@@ -767,12 -680,13 +767,13 @@@ static void gfs2_stuffed_iomap(struct i
  		      sizeof(struct gfs2_dinode);
  	iomap->offset = 0;
  	iomap->length = i_size_read(inode);
- 	iomap->type = IOMAP_MAPPED;
- 	iomap->flags = IOMAP_F_DATA_INLINE;
+ 	iomap->type = IOMAP_INLINE;
  }
  
+ #define IOMAP_F_GFS2_BOUNDARY IOMAP_F_PRIVATE
+ 
  /**
 - * gfs2_iomap_begin - Map blocks from an inode to disk blocks
 + * gfs2_iomap_get - Map blocks from an inode to disk blocks
   * @inode: The inode
   * @pos: Starting position in bytes
   * @length: Length to map, in bytes
@@@ -838,20 -770,20 +839,20 @@@ static int gfs2_iomap_get(struct inode 
  	if (*ptr == 0)
  		goto do_alloc;
  
 -	iomap->type = IOMAP_MAPPED;
 -	iomap->addr = be64_to_cpu(*ptr) << inode->i_blkbits;
 +	bh = mp->mp_bh[ip->i_height - 1];
 +	len = gfs2_extent_length(bh->b_data, bh->b_size, ptr, len, &eob);
  
 -	bh = mp.mp_bh[ip->i_height - 1];
 -	len = gfs2_extent_length(bh->b_data, bh->b_size, ptr, lend - lblock, &eob);
 +	iomap->addr = be64_to_cpu(*ptr) << inode->i_blkbits;
 +	iomap->length = len << inode->i_blkbits;
 +	iomap->type = IOMAP_MAPPED;
 +	iomap->flags = IOMAP_F_MERGED;
  	if (eob)
- 		iomap->flags |= IOMAP_F_BOUNDARY;
+ 		iomap->flags |= IOMAP_F_GFS2_BOUNDARY;
 -	iomap->length = (u64)len << inode->i_blkbits;
  
 -out_release:
 -	release_metapath(&mp);
 -	bmap_unlock(ip, flags & IOMAP_WRITE);
  out:
 -	trace_gfs2_iomap_end(ip, iomap, ret);
 +	iomap->bdev = inode->i_sb->s_bdev;
 +unlock:
 +	up_read(&ip->i_rw_mutex);
  	return ret;
  
  do_alloc:

Content of type "application/pgp-signature" skipped