Received-SPF: pass (google.com: domain of linux-kernel+bounces-6106-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Wed, 20 Dec 2023 10:41:10 +1100
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Al Viro <viro@ZenIV.linux.org.uk>, Christian Brauner
 <brauner@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Next
 Mailing List <linux-next@vger.kernel.org>
Subject: linux-next: manual merge of the vfs tree with the vfs-brauner tree
Message-ID: <20231220104110.56ae9b36@canb.auug.org.au>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/b4PHeWdP57aqouLzyNAjazv";
 protocol="application/pgp-signature"; micalg=pgp-sha256

--Sig_/b4PHeWdP57aqouLzyNAjazv
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

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 n=
o 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.

--=20
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
 =20
  ---
 =20
 +**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 superbloc=
k, not
 +just the main block device. The get_active_super() helper and bd_fsfreeze=
_sb
 +pointer are gone.
++
++---
++
+ **mandatory**
+=20
+ If ->rename() update of .. on cross-directory move needs an exclusion with
+ directory modifications, do *not* lock the subdirectory in question in yo=
ur
+ ->rename() - it's done by the caller now [that item should've been added =
in
+ 28eceeda130f "fs: Lock moved directories"].
+=20
+ ---
+=20
+ **mandatory**
+=20
+ On same-directory ->rename() the (tautological) update of .. is not prote=
cted
+ by any locks; just don't do it if the old parent is the same as the new o=
ne.
+ We really can't lock two subdirectories in same-directory rename - not wi=
thout
+ deadlocks.
+=20
+ ---
+=20
+ **mandatory**
+=20
+ 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(-EXD=
EV)
+ is returned, with no locks taken.  In-tree users updated; out-of-tree ones
+ would need to do so.
+=20
+ ---
+=20
+ **mandatory**
+=20
+ 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 cau=
ght
+ by compiler.
+=20
+ ---
+=20
+ **mandatory**
+=20
+ ->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...
+=20
+ --
+=20
+ **mandatory**
+=20
+ ->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 exclusion=
s (none
+ of the in-tree instances did), use your own spinlock.
+=20
+ ->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., ju=
st not
+ removed from parent's ->d_children yet.
+=20
+ 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 w=
ill
+ 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 a=
djustment.

--Sig_/b4PHeWdP57aqouLzyNAjazv
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEENIC96giZ81tWdLgKAVBC80lX0GwFAmWCKhYACgkQAVBC80lX
0GxRTAf/dF1XvjDZ9/eCz1XJYd4veLq/9HB6hS8eGGlc1Lb6/74NvOMf/vri/7q7
Y2SCtC+6HbOdXY+xCSTZvdTc2K/wF5ZA7OoLwIk5fsmx2irWBsnkuwCXivIxaHZu
r6/F/m90jG3OiYfAgD7ohYHxQv0nClosdz6gHI7/JJ4hAhTZjk2nRIh1UpQGyTlP
F+Bnbqf1WYeZD0gE76mYLAVF53U9fo7IAcBX7WBlHs6JMC9Si1ryhGufbWpVG5UF
5H1p8eoSJ6wbpOO+OeSkRka2eROb2hoB7vHutY1r8fQdpiuQUBue/khW1XnemESg
t8YGwmJhkei8eQLywC7haL6HvpZ6Aw==
=esc+
-----END PGP SIGNATURE-----

--Sig_/b4PHeWdP57aqouLzyNAjazv--