linux-kernel - 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20181031112244.71b62e67@canb.auug.org.au>
Date:   Wed, 31 Oct 2018 11:22:44 +1100
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>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: linux-next: manual merge of the xfs tree with Linus' tree

Hi all,

Today's linux-next merge of the xfs tree got a conflict in:

  Documentation/filesystems/porting

between commit:

  1a16dbaf798c ("Document d_splice_alias() calling conventions for ->lookup() users.")

from Linus' tree and commit:

  2e5dfc99f2e6 ("vfs: combine the clone and dedupe into a single remap_file_range")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/filesystems/porting
index 321d74b73937,e6d4466268dd..000000000000
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@@@ -623,13 -623,7 +623,18 @@@ in your dentry operations instead
  	On success you get a new struct file sharing the mount/dentry with the
  	original, on failure - ERR_PTR().
  --
 +[recommended]
 +	->lookup() instances doing an equivalent of
 +		if (IS_ERR(inode))
 +			return ERR_CAST(inode);
 +		return d_splice_alias(inode, dentry);
 +	don't need to bother with the check - d_splice_alias() will do the
 +	right thing when given ERR_PTR(...) as inode.  Moreover, passing NULL
 +	inode to d_splice_alias() will also do the right thing (equivalent of
 +	d_add(dentry, NULL); return NULL;), so that kind of special cases
 +	also doesn't need a separate treatment.
++--
+ [mandatory]
+ 	->clone_file_range() and ->dedupe_file_range have been replaced with
+ 	->remap_file_range().  See Documentation/filesystems/vfs.txt for more
+ 	information.

Content of type "application/pgp-signature" skipped