linux-next: manual merge of the vfs tree with the vfs-brauner tree

[Stephen Rothwell <sfr@canb.auug.org.au>]

[-- Attachment #1: Type: text/plain, Size: 3996 bytes --]

Hi all,

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

  Documentation/filesystems/porting.rst

between commit:

  01bc8e9ae23a ("porting: document block device freeze and thaw changes")

from the vfs-brauner tree and commits:

  22e111ed6c83 ("rename(): fix the locking of subdirectories")
  a8b0026847b8 ("rename(): avoid a deadlock in the case of parents having no common ancestor")
  da549bdd15c2 ("dentry: switch the lists of children to hlist")
  2f42f1eb9093 ("Call retain_dentry() with refcount 0")
  1c18edd1b7a0 ("__dentry_kill(): new locking scheme")

from the vfs 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.rst
index ced3a6761329,270cef3d84d4..000000000000
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@@ -1064,12 -1064,61 +1064,73 @@@ generic_encode_ino32_fh() explicitly
  
  ---
  
 +**recommended**
 +
 +Block device freezing and thawing have been moved to holder operations.
 +
 +Before this change, get_active_super() would only be able to find the
 +superblock of the main block device, i.e., the one stored in sb->s_bdev. Block
 +device freezing now works for any block device owned by a given superblock, not
 +just the main block device. The get_active_super() helper and bd_fsfreeze_sb
 +pointer are gone.
++
++---
++
+ **mandatory**
+ 
+ If ->rename() update of .. on cross-directory move needs an exclusion with
+ directory modifications, do *not* lock the subdirectory in question in your
+ ->rename() - it's done by the caller now [that item should've been added in
+ 28eceeda130f "fs: Lock moved directories"].
+ 
+ ---
+ 
+ **mandatory**
+ 
+ On same-directory ->rename() the (tautological) update of .. is not protected
+ by any locks; just don't do it if the old parent is the same as the new one.
+ We really can't lock two subdirectories in same-directory rename - not without
+ deadlocks.
+ 
+ ---
+ 
+ **mandatory**
+ 
+ lock_rename() and lock_rename_child() may fail in cross-directory case, if
+ their arguments do not have a common ancestor.  In that case ERR_PTR(-EXDEV)
+ is returned, with no locks taken.  In-tree users updated; out-of-tree ones
+ would need to do so.
+ 
+ ---
+ 
+ **mandatory**
+ 
+ The list of children anchored in parent dentry got turned into hlist now.
+ Field names got changed (->d_children/->d_sib instead of ->d_subdirs/->d_child
+ for anchor/entries resp.), so any affected places will be immediately caught
+ by compiler.
+ 
+ ---
+ 
+ **mandatory**
+ 
+ ->d_delete() instances are now called for dentries with ->d_lock held
+ and refcount equal to 0.  They are not permitted to drop/regain ->d_lock.
+ None of in-tree instances did anything of that sort.  Make sure yours do not...
+ 
+ --
+ 
+ **mandatory**
+ 
+ ->d_prune() instances are now called without ->d_lock held on the parent.
+ ->d_lock on dentry itself is still held; if you need per-parent exclusions (none
+ of the in-tree instances did), use your own spinlock.
+ 
+ ->d_iput() and ->d_release() are called with victim dentry still in the
+ list of parent's children.  It is still unhashed, marked killed, etc., just not
+ removed from parent's ->d_children yet.
+ 
+ Anyone iterating through the list of children needs to be aware of the
+ half-killed dentries that might be seen there; taking ->d_lock on those will
+ see them negative, unhashed and with negative refcount, which means that most
+ of the in-kernel users would've done the right thing anyway without any adjustment.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]